The Coherence Problem in AI-Native Software Development

1  Generation is solved; the cost of software moved downstream

AI coding agents now spin up subagents that produce pull requests in parallel, faster than any human team. One side project built largely by vibe coding reached roughly 1,600 commits, more than 600 pull requests, and about 140,000 lines of code¹ — orders of magnitude beyond a median full-time developer's annual output. Producing code is no longer the scarce activity.

The cost of software did not vanish; it moved. Three independent signals locate it downstream, in review, reconciliation, and keeping a growing mass coherent (Exhibit 1). The claim is deliberately narrow: code production — generating large volumes of plausible, usually-runnable code — is cheap. That is not the stronger and genuinely contested claim that agents are good engineers; that contest is taken up directly in Section 7.

2  Complexity is combinatorial, so AI amplifies divergence, not merely speed

Software complexity does not scale linearly with code volume. Interactions between functions scale roughly with the square of the function count; the reachable state space scales roughly exponentially in the number of interacting variables. The load-bearing consequence: doubling code volume more than doubles complexity.

If AI amplified only speed, teams would ship faster and need no new roles. AI instead amplifies volume and divergence — agents make locally sensible but globally inconsistent decisions: one module authenticates with pattern A, another with pattern B, a third introduces a conflicting dependency. Volume multiplied by combinatorial complexity multiplied by divergence yields super-linear growth in incoherence (Exhibit 2). An amplifier has no sign of its own: it multiplies whatever it is fed. Pointed at a generation process with no ordering discipline, it amplifies entropy; pointed at quality-engineering judgment, it amplifies coherence.⁵ The amplifier does not choose — the mechanism designer does.

The specific failure has a name: drift — the gradual divergence of an AI-amplified codebase from a coherent structure. It takes two forms: architectural drift, in which modules wander from their boundaries and competing implementations of one concern accumulate; and dependency drift, in which conflicting libraries, version sprawl, and dead code accrete. Drift is invisible to linting, which is syntactic, and to per-PR review, which is local. It is a global, accumulating property — and it is independently named as unsolved at scale by industry landscape analysis.

3  The prevailing team models optimize the problem that is already solved

The dominant team models of the moment were built around the now-cheap act of generation. The pirate/architect model pairs a fast "pirate" who ships by vibe coding with an "architect" who hardens the product surface after product-market fit, often part-time. The two-slice team places one person per product, with roughly 99% of code AI-written.⁷ Both capture something real — exploration and hardening are different work at different paces — but both amplify the generator, the now-cheap function, and treat structure as a late, thin, post-PMF concern.

These models resource the era that is ending. The tell is that the framing's own boosters now concede, in the May 2026 discourse, that complexity management matters — while the model itself assigns complexity no role and no owner.

4  Two mechanisms govern coherence: the keel and the drift-loop

A team that ships reliable product resources both prevention and correction. Together they convert a global combinatorial explosion into a sum of small, contained ones.

Prevention — the keel

The keel is a small structural foundation: loose coupling, single responsibility, a clean dependency graph, and a "super-core" of decisions costly to reverse even in the AI era — database schema and core dependency topology. Loose coupling makes the interaction matrix sparse; module boundaries partition one global state space into small local ones. The keel does not eliminate complexity — it bounds and localizes it. It is laid in a drydock, a short and deliberate phase of days to roughly two weeks before feature work, and it cannot be re-laid at sea. This is not Big Design Up Front: BDUF designs the discoverable; the keel designs only the knowable-in-advance and irreversible.

Correction — the drift-loop

The drift-loop is a continuous mechanism — periodic refactor passes, a persistent architectural-invariant monitor, a whole-repo tech-debt audit — that detects and reverses the drift prevention misses. In entropy terms, the generator is a source; the keel and the drift-loop are sinks. A team functions when sources and sinks balance (Exhibit 3). The pirate/architect model is almost all source.

Defense against drift has three layers (Exhibit 4). Most current discourse and tooling addresses only the first.

5  The human's role moves from writing code to designing mechanisms

AI can fill the operator seat — generation — and increasingly the mechanic seat: a tech-debt audit is a maintenance routine an agent executes. What AI cannot yet reliably do is design the keel and design the maintenance mechanism — decide module boundaries, choose the super-core, define what drift means for this codebase, specify what the audit checks and what it is permitted to change. The human's seat is the meta-layer: not coder, not maintainer-by-hand, but mechanism designer. Literacy shifts from reading code to designing architecture and loops, and the most experienced engineer's attention concentrates on the keel — the place where being wrong is most expensive.

The team's own evidence is a two-project natural experiment (Exhibit 5). With team, tooling era, and approach all held constant, the variable that moved was the ordering of foundation work — and the outcome moved with it. The evidence is suggestive, not conclusive, and is corroborated, not carried, by the external industry evidence in Exhibits 1 and 2.

6  The problem compounds as models improve

The task length AI can reliably handle has been doubling roughly every seven months.⁴ Better models mean more amplification — more volume and more divergence per unit time. The naive view, that better models will fix the mess, is backwards: better models make the coherence problem larger. The keel and the drift-loop therefore appreciate in value over time. They are not transitional scaffolding.

7  Risks and counterarguments

1. Big Design Up Front, repackaged. The keel is deliberately small — module boundaries, the dependency graph, schema, and the tooling layer, the structure that is knowable in advance regardless of what is built and costly to reverse. BDUF failed because it tried to design the discoverable; the keel designs only the knowable and irreversible, and the reversible middle stays loose and explored.
2. Thin direct evidence. The mirai/twin comparison is two projects, different domains, no recorded metrics. This is a real limitation, conceded plainly: the comparison is corroborated — not carried — by independent industry evidence, and the structural gap the team observed is largely orthogonal to which domain is intrinsically harder.
3. Better models will retrofit cheaply. This is backwards as a strategy: better models amplify the generator at least as fast as they improve retrofit capability, so volume and drift grow at least as fast. The asymmetry is also structural — a schema migration against live data carries data-migration, coordination, and downtime cost independent of who does the labor.
4. Generation is not solved — agents cannot program. The hard-skeptic position holds that agent output is fundamentally and undetectably broken.⁹ Much of the disagreement is terminological: the precise claim is that code production is cheap, not that agents are good engineers, and "the output is broken downstream" is itself the coherence thesis. Its own organizational argument — that variance rises, the best improve while the average falls — is an argument for encoding error-correction in mechanisms rather than assuming it in every operator.
5. Humans will stop reading code entirely. Granted for the strong part: humans can and will stop reading code line by line. The disputed inference is that structure therefore needs no human. A codebase, unlike a finished game, is maintained indefinitely; incomprehensible-but-strong output is fine for a one-shot artifact and fatal for a system extended for years. Mechanism-literacy replaces code-literacy; it does not vanish.¹⁰
6. "Architecture matters" is decades old. The claim is three newer things: a quantitative shift, since AI amplifies volume and divergence so the return on structure has risen super-linearly; a role shift, from author to mechanism designer; and a positive inversion, in which structure becomes the enabler of parallel agentic work rather than a hedge against decay.