Your coding agent needs more than instructions A developer proposes Capability-Oriented Development (COD), an approach that makes architectural relationships explicit so coding agents can find the owner of a shared capability, its supported options and its extension rules instead of scattering ad-hoc CSS across views. The method pairs a capability catalog derived from contracts naming owners, consumers and extension rules with optional SCIP source indexes, and ties those obligations to checks like types, tests and dependency rules. The author argues agents are over-reliant on instructions such as "ALWAYS USE EXISTING COMPONENTS" and that making the wrong change harder is more effective than asking agents to do the right thing. Announcer voice You have a design system. You have components. You have instructions explaining when to extend them. You see a Button on a page. You tell the LLM, "Oh, this button should look like a link." You meant , "Change the variant value of the Button component to link ." But we're humans, and we don't always say it that clearly. A human developer brings millions of years of pattern-making brain evolution to this conversation. They recognize the component, look at its options, and probably change the prop. Maybe they miss the option and create a redundant LinkButton . Not ideal. The LLM does something much, much stupider. It adds CSS to just that page, even though the button lives in a Header . The header appears somewhere else too, so the LLM says, "Oh ok," and vomits styles into that view as well. For the vibe coder, nothing is noticed. It works. The tests pass. The responsible cough software engineer discovers that the LLM has smeared concerns across the codebase. You unleash expletives at the LLM, which then scolds you for abusive language and ends the conversation. You calm yourself down, have some tea, and come back. You add instructions. You add skills. You write “ALWAYS USE EXISTING COMPONENTS” in capital letters in AGENTS.md, because surely the problem was insufficient capitalization. Sometimes that helps. Too often, it doesn't. I'm not about to announce that I've solved AI alignment in a blog post. But I do think we're leaning too hard on asking agents to do the right thing, without making it hard to do the wrong thing. We already know how to do some of this. Types reject invalid calls. Tests reject broken behavior. Dependency rules reject forbidden imports. What's often missing is the relationship between those things: this component owns this behavior, and these consumers must keep using it . A page can look correct today while quietly acquiring its own copy of a shared rule. Humans infer those relationships. We recognize patterns, ask colleagues, and remember why an abstraction exists. Making every relationship explicit is extra work, so we leave quite a bit unsaid. An LLM can generate and maintain more of that machinery. That doesn't make maintenance free, or its judgment reliable. But perhaps we should spend some of its effort making the architecture explicit, instead of repeatedly explaining that no, we did not want another button implementation. What if we let LLMs code for LLMs? Capability-Oriented Development, or COD, or “cape coding” as the kids call it they do not; I've just made up these terms , is an approach built around those ongoing relationships. A capability is something the system can do: render a button, check a permission, calculate a price. COD makes its owner discoverable, describes how it can be used and extended, and connects those obligations to checks. Let's walk through the button request. The agent starts at the page, follows the header to the shared Button, and finds its supported variants: php < -- Before --