A Few Hundred Reasonable Changes

The speed is real. Teams roll out AI coding agents and ship more in a week than they used to ship in a month. I have watched it happen across a dozen engineering orgs, and the output is genuine.

So is a cost that shows up later, in a place no one is watching: architectural consistency erodes while everything still looks fine.

An agent generates a change. The code runs. The tests pass. A reviewer reads the diff, sees nothing wrong, and approves. Repeat that a few hundred times. Each change, on its own, is reasonable. Put together, they stop adding up to one coherent system, because nothing checked them against the decisions that were supposed to hold.

That is the part worth sitting with. The problem is not bad code. Every individual change would survive a code review, because at the diff level there is nothing to object to. The damage is cumulative and structural. A module that was kept separate on purpose grows a dependency. A pattern the team standardized on gets a second implementation that does the same job a different way. A boundary that mattered for security or ownership gets crossed by a change that had no idea the boundary was there.

None of this is the agent's fault. The agent did what it was asked, with the context it had. The trouble is the context it had did not include the decisions the team already made about domain boundaries, established patterns, prior architectural calls, and ownership. Those decisions live in a few people's heads, in old pull request comments, and in a wiki page last updated two years ago. The agent cannot follow rules nobody wrote down where it could read them. Neither, for that matter, can a new hire.

The standard answer is review. Catch it at the pull request. The problem is that review asks a human to reconstruct the entire architecture from memory, every time, fast enough to keep up with an agent generating at full speed. That does not scale. A reviewer rebuilding the system in their head will miss what the agent never slowed down to consider. Review was already the bottleneck before agents. Agents widened the gap between how fast code arrives and how fast a person can verify it belongs.

So what closes the gap?

Not a smarter generation model. A better model writes better individual changes, but it has the same blind spot: it does not know your decisions unless your decisions are somewhere it is held to them.

The missing piece is a shared engineering context that both developers and agents are held to, enforced at the moment code is generated rather than filed in a document nobody reopens. The decisions a team has already made get captured in the repo, turned into checks that run in the workflow, and enforced through hooks and CI at the point of generation. It is not a policy binder or a style guide everyone agrees to and no one rereads. Standards that are enforced, not just documented.

This is what we are building at Mneme HQ. An engineering governance layer for AI coding agents: the decisions your team already made, made legible to the machine, and checked while the code is being written instead of months later when the drift has already compounded.

The uncomfortable thing I keep landing on, talking to engineering leaders most weeks, is that the agents did not create this gap. The gap was always there. Architecture has always lived in too few heads. Standards have always decayed faster than anyone documents them. What changed is the speed. When humans wrote all the code, the drift was slow enough to ignore. Agents made it impossible to keep ignoring.

That is not a reason to slow the agents down. It is a reason to give them, and the people working alongside them, something firmer to be held to.