For forty years, software architecture has optimized for one scarce resource: the capacity of a human head. Small modules, careful naming, design patterns, bounded contexts, the rule that a class should fit on a screen — every one of these exists because a person has to read the code, hold it in working memory, and reason about what it does. Cognitive load has been the invisible axis along which we judged every design. "Clean" has always meant cheap for a human to understand.
That axis is losing its grip on the problem. When a coding agent writes most of the code, reading cost collapses along with writing cost. The agent doesn't get tired at module seventeen. It doesn't need the metaphor to be consistent. It holds more of the system in context than any of us ever did.
What it cannot give you — what nothing gives you for free — is confidence that the output is right. In an agent-built system, the scarce resource is no longer comprehension. It is verification. And architecture should be reorganized around the new scarcity.
The bottleneck moved
Here is the arithmetic that changed. When code was expensive to write, we economized on writing: frameworks, reuse, DRY, clever abstractions that saved keystrokes at the price of coupling. When code became expensive to read — because teams grew and systems outlived their authors — we economized on reading: readability, conventions, documentation.
Agents drive both costs toward zero. A component that would have taken a sprint takes an afternoon, and rewriting it takes another afternoon. What does not go to zero is the cost of answering one question: is this correct? Every hour your senior engineers spend reviewing agent output is the new critical path. A system that produces code faster than you can trust it hasn't gotten faster. It has moved the queue.
So the design question changes. Not "can a developer understand this module in isolation?" but "can a machine — a test, a check, a grader — tell me this module is right, in isolation, without a human reading every line?"
What verifiable architecture looks like
Take a concrete case: a service that computes fees for client accounts under versioned fee policies.
The design the old axis favors: a well-factored calculation engine, policy logic elegantly shared across account types, one abstraction handling versioning for everything. Beautiful to read. But verifying a change means understanding the shared abstraction, because a change for one account type can move results for another. A human review has to walk the coupling.
The design the new axis favors is almost embarrassing to write down: one calculation path per account type, each with its own contract — a table of input cases and expected outputs, dated, versioned with the policy. Some logic is duplicated. Under the old axis, that's a smell. Under the new one, it's the point: each path can be regenerated from its contract by an agent and verified against it mechanically, with no human in the loop until the contract itself changes. Duplication became cheap the day agents started writing the copies. Coupling stayed expensive, because coupling is what makes verification non-local.
Three properties keep showing up in systems that survive this test:
Verifiable seams. Components are cut where a contract can sit — explicit inputs, expected outputs, a check that runs. Domain-driven design earns a second life here: a bounded context isn't just a comprehension boundary anymore, it's a verification boundary. Inside it, an agent can rebuild freely; at its edge, the contract holds.
Verification as machinery, not meetings. Gold sets, deterministic checks, evals wired into the pipeline — the definition of "done" is something that executes. If correctness lives in a reviewer's judgment, you have a queue. If it lives in a grader, you have a system.
Regenerability. The most verifiable component is one you can throw away and rebuild from its spec. That inverts a deep habit: we preserved code because it was expensive. When the spec and the contract are the durable artifacts, the code becomes the build output.
The question for your next design review
None of this means cognitive load stops mattering — humans still design the seams, write the contracts, and own the judgment calls. It means cognitive load is no longer the ranking criterion when two designs compete.
So add one question to your design reviews, and weight it heavily: when an agent changes this component, how will we know — mechanically, not socially — that it is still correct? Designs that have a crisp answer will get cheaper every quarter, because everything on the generation side keeps improving. Designs that answer "senior review" have pinned their throughput to the calendar of their most expensive people.
The industry spent decades learning to write code humans can read. The next discipline is shaping systems machines can verify. That is the axis I now design along.