What problem does C-DAD solve?

Every team that's put a coding agent on a real codebase has hit the same wall. The agent writes something that compiles, passes the obvious tests, and looks exactly like what a competent engineer would have written. Then it breaks something in production that nobody thought to check, because the constraint that would have stopped it was never written down anywhere the agent could see.

That's not a model problem. Bigger context windows and smarter reasoning don't fix it, because the missing information was never in the codebase to begin with. It lived in a senior engineer's head, in a Slack thread from eighteen months ago, in the memory of why a retry policy has an odd exception baked into it. Reading every file in the repository doesn't recover that. You can't grep for a decision nobody recorded.

Contract-Driven AI Development treats this as a structural gap, not a tooling gap. The fix isn't a smarter agent or a longer prompt. It's making the system say, in a form both a person and a model can act on, what a capability does, why it does it that way, and what would break if you changed it. Once that exists, an agent stops guessing at intent and starts reading it directly.

C-DAD is the discipline built around producing that artifact: what a contract has to contain, how to decide which parts of a system need one first, and how contracts compose into something larger than any single file, a map of how a whole system actually works.