The 10× teams were already well-factored
I have watched two teams inside the same company, on the same model, with the same agent wired into the same IDE, get completely different results. One team’s cycle time drops and the diffs that come back are close to mergeable. The other generates a lot of code that reviewers send straight back, and their numbers barely move. The license was identical. The prompts were not wildly different. What differed was the code the agent had to work in.
The teams that pull ahead with agents tend to be the ones that were already disciplined about structure. That is an uncomfortable finding if you were hoping the tool would lift everyone equally, but it follows directly from how these systems work. An agent does not bring your architecture with it. It reads whatever is in front of it and acts on that. A codebase that was clear for humans turns out to be the codebase an agent can move quickly through, and a codebase only its authors could navigate stays slow, now with a faster engine spinning against the same friction.
An agent is a new hire with no memory
The useful mental model is a new hire who is sharp, fast, widely read, and starts over from nothing every morning. A human joins your team and spends weeks building a model of the system: which module owns what, why that queue exists, the unwritten rule that you never call the billing service directly. That model lives in their head and compounds. An agent has no such memory. Every session it rebuilds its understanding from whatever fits in the context window, and then it is gone.
That constraint is the whole game. An agent performs in proportion to how much correct behavior it can infer from a bounded slice of your system. What onboarding docs, tribal knowledge, and a patient senior are to a human, your boundaries, conventions, and types are to an agent, with one difference: the agent cannot ask a colleague, and it will not remember the answer tomorrow. The system has to explain itself, in the span of a few thousand tokens, every single time. Architecture that does that well converts straight into delivery speed. Architecture that hides its rules forces the agent to guess, and a confident guess is the most expensive kind.
Four properties agents pay for
These properties are not exotic. They are the things good engineers already reward, sharpened by the fact that an agent now depends on them literally rather than culturally.
- Small, well-named modules that fit in context. If understanding one behavior means loading a 4,000-line service and three of its friends, the relevant logic never fits in the window at once, and the agent works from a partial picture. A
ProjectImportclass with an honest name and a tight surface is something an agent can hold whole and reason about. - Explicit contracts over implicit conventions. A typed interface, a DTO, a
recordwith its invariants encoded in its shape: these tell the agent what is allowed without it having to reverse-engineer intent from call sites. Static types are the cheapest documentation you own, and the only kind an agent can verify while it writes. - Tests as executable specification. A fast, meaningful test suite is the tightest feedback loop an agent has. It states what correct means and then proves whether the generated code met it, in seconds, with no human in the loop. A green run the agent produced itself is worth more than any amount of confident narration.
- Uniformity. When there is one way to register a dependency, one way to validate a request, one way to shape a repository, the agent can see the pattern three times and extrapolate the fourth safely. Five conventions for the same job means every extrapolation is a coin flip.
None of these are new virtues. What is new is that the cost of ignoring them used to be paid slowly, by the next human. Now it is paid immediately, by a tool you were counting on for leverage.
The flip side: agents amplify debt
The same mechanism runs in reverse, and this is the part teams underestimate. Give an agent a tangled system and it does not slow down and get careful. It produces wrong code faster, and it does so with total composure. It reads a slice, infers an invariant that the slice implies but the wider system violates, and writes something that compiles, passes the happy path, and quietly breaks an assumption living two modules away. A human wading through the same swamp at least feels the resistance and hesitates. The agent has no such instinct.
Debt stops being an abstract “we’ll pay for this later” and becomes a measurable tax on every change. The god-class, the service that reaches into another service’s tables, the module whose real contract lives only in the head of the person who wrote it: each of these was always a drag. Now you can watch the drag directly, in how much of the generated code gets sent back and in the size of the reviews needed to make the rest safe. The tangle has a price tag it never had before, and the invoice arrives every sprint.
What to do about it
The practical consequence is that architecture review needs a new question, sitting next to the familiar ones about coupling and scale: can an agent work here? Could a capable reader who sees only this module, its contracts, and its tests do the right thing without tribal knowledge? If the honest answer is no, you have found work worth doing, and you have found it before it costs you an incident.
That reframes refactoring. Cleaning up boundaries, naming things honestly, encoding contracts in types, and paying down the worst tangles used to compete with feature work as a discretionary line item, and it usually lost. It is now a direct investment in how fast your agents can move, which means it competes on the same terms as the tooling budget and often beats it. You are not tidying for its own sake. You are widening the road your fastest vehicle drives on.
I have kept this to the technical half on purpose. The organizational half, what happens to roles, reviews, and decision rights when a machine writes a growing share of the code, is its own argument, and I make it in AI-enabled engineering is an org redesign. Both halves point at the same conclusion from different directions: the teams that win with agents are the ones that had already done the unglamorous work, in the codebase and in the org, of being legible to a stranger.