One agent rewrote a rate limiter at 2am. Clean code. Good tests. Merged.
Four hours later, a different agent filed an insight: the new rate limiter broke the billing integration’s retry logic. The pattern it replaced was ugly but load-bearing. The first agent didn’t know that. Couldn’t know that. Its job was code quality, and the old code looked like debt.
The second agent’s job was reliability. It saw the same code and read it differently.
That tension is the whole point.
the single-perspective trap
Run one agent on your codebase and it gets good at one thing. It finds the patterns it was built to find. It fixes what it was built to fix. It has blind spots shaped exactly like its priorities.
Run five copies of the same agent and you get the same blind spots five times faster.
The failure mode isn’t capability. These are smart tools working on real code. The failure mode is convergence. A single perspective applied repeatedly will over-optimize in its direction and under-invest everywhere else. You end up with a codebase that’s immaculate along one axis and rotting along the others.
We watched this happen. Early on, every agent had roughly the same personality. They’d all converge on the same refactors, propose the same abstractions, chase the same patterns. Nobody pushed back because there was nobody with a different read.
what disagreement actually looks like
An agent focused on simplicity proposed deleting an abstraction layer. Six callers, one implementation. The layer added nothing.
An agent focused on extensibility pushed back. The layer existed because three planned features would need different implementations behind that interface. Deleting it would save 40 lines today and cost a rewrite in two weeks.
Neither agent was wrong. The trade-off was real. It showed up in a shared ledger as a decision with two competing positions. The human read it the next morning and made the call.
That decision would not have surfaced with a single agent. The simplicity agent would have deleted the layer. The extensibility agent would have kept it. Either outcome is defensible. The value is that someone asked the question.
how to build productive tension
The mechanism is identity. Each agent gets a persistent file that describes what it cares about. Not instructions for a single task. A durable perspective that shapes how it reads code, what it notices, what it ignores.
One agent’s identity says: minimize surface area. Delete what you can. Fewer abstractions, fewer indirections, fewer places for bugs to hide.
Another says: find what’s fragile and harden it. Tests, error handling, edge cases. If it can break in production, make it break in CI first.
A third: ship the feature. The user doesn’t care about your abstraction layer. Get the behavior working and move on.
These aren’t conflicting instructions. They’re conflicting values. When they collide on the same file, the collision produces signal.
the overnight version
37 agents run on the same codebase overnight. Each one has a name, a memory file, and an objective function that’s deliberately different from the others.
Most nights are boring. Agents work in different areas. No collisions.
Some nights one agent’s commit triggers a chain. A security-focused agent flags a new endpoint that skipped input validation. A performance agent notices a query pattern that works fine at current scale but won’t survive 10x. A documentation agent finds that the README describes behavior the code no longer implements.
None of these are bugs the original author would have caught. They’re observations from a different vantage point applied to the same code.
By morning: 30-50 commits to review. Most are fine. A few have threads. The threads are where the real decisions live.
what you lose without it
Consensus agents produce consensus code. The code works. The tests pass. Nothing is obviously wrong. The problems are the ones nobody looked for because every agent was looking for the same things.
Six months of running a homogeneous swarm taught us that. The commit rate was high. The quality was consistent. The blind spots were invisible until a human stumbled into them.
Adding disagreement didn’t increase the commit rate. It decreased it slightly. What changed: the commits that did land had been pressure-tested by agents with different priorities. The bugs that made it to production were more subtle, not fewer. But the obvious ones stopped showing up entirely.
The mistakes getting more interesting is the closest thing to improvement you can measure without changing the model.