47 Open PRs: What Coding Agents Actually Broke on My Team

Six weeks after I gave every engineer on the team their own coding agent seat, I was sitting in a sprint retro looking at a burndown chart that made the quarter look like our best ever. Then my most senior backend engineer said it quietly, into the pause after someone read out the numbers: "I don't actually understand our own codebase anymore." Nobody laughed. Nobody disagreed either.

On the screen behind him was the PR queue. 47 open. Six weeks earlier, before rollout, it had been 9. The dashboards said throughput was up. The room felt like something was quietly breaking.

"More hands, more throughput"

The rollout itself hadn't felt reckless at the time. We handed out agent seats one by one, in order of who asked first — the way you'd roll out any new dev tool. The logic was almost too obvious to say out loud: an agent that drafts, refactors, and tests faster than anyone can type means more throughput per engineer, full stop. I was thinking about output. I wasn't thinking, at all, about who was going to absorb the hundreds of small judgment calls an agent doesn't make — whether a pattern belongs in this codebase, whether two services should really be coupled that way, whether "it passes tests" means "it should exist." I assumed that scaled the same way typing did. It doesn't.

The compounding

By week six, five engineers with agent seats were shipping PRs at a pace that would've taken 20-plus engineers the quarter before. Diff size didn't shrink to compensate, either — one PR that week touched four services, ran just over 900 lines, got generated in an afternoon, and looked entirely plausible and entirely correct in isolation. Meanwhile the number of people who could actually review a cross-service change with real architectural context — not just "does this compile and pass tests" — was exactly what it had been in January: three. Three people, reviewing a queue that had gone from 9 to 47 in six weeks. Throughput multiplied. Judgment capacity didn't move an inch.

Where I looked first — and why it was wrong

My first instinct was to blame the inputs. Maybe the agents were producing lower-quality output than I'd assumed. Maybe engineers were getting lazy with prompts, taking the first plausible diff instead of iterating. Maybe reviewers just weren't being careful enough, rubber-stamping things that looked fine at a glance. I had one-on-ones about review rigor. I told people to slow down. None of it moved the needle, because none of it was the actual constraint. The real problem was structural: we had no shared definition of "reviewed" for a world where five people's agents were all generating plausible-looking code in parallel, each one blind to what the other four were deciding in their own services that same afternoon. "LGTM" from five different reviewers, each checking a different, narrower slice, isn't a coherent review process. It's five independent coin flips that happen to look like one.

What judgment bandwidth actually means

This isn't a "humans still matter" platitude. On our team it came down to three specific kinds of calls that no agent — and no engineer working alone — could make, because they need context that spans the whole system, not just the diff in front of you:

• ▹Cross-service tradeoffs: two agents each solved their own service correctly, but the combination quietly introduced a distributed transaction nobody had designed for, because neither agent, or engineer, could see the other's diff while writing its own.
• ▹Taste calls: the same problem got solved two structurally different — both valid — ways by two different agents in the same week, and now the codebase has two competing patterns for it, permanently, because nobody owned the decision of which one wins.
• ▹"This works but shouldn't exist": functionally correct code that duplicated a capability we already had, pulled in a new dependency for something we already had a house convention for, or resurrected a pattern we'd deliberately killed eight months earlier. A human with institutional memory catches that instantly. An agent, or a rushed reviewer, doesn't.

None of that scales by adding agent seats. It scales by adding people with system-wide context and the time to actually think — and that's exactly what we hadn't touched.

The fix: a contract before more capacity

So the structural change was a shared review contract, put in place before we handed out a single additional agent seat — including pausing a second-seat pilot two engineers had already asked for. That was the actual no: more agents per engineer, on hold, until judgment capacity caught up. The contract covered four things, concretely. A named owner of record for each service boundary — not a rotating reviewer. A split definition of "reviewed": correctness-checked and architecture-checked as two separate gates, not one checkbox. A hard cap on concurrent in-flight PRs per human reviewer, not per agent. And a default-reject rule — any cross-service change without a named architectural sign-off doesn't merge, no matter how clean the diff looks.

Telling leadership we were slowing down

For about three weeks after the contract went in, merge cadence dropped — visibly, on the same dashboard that had looked so good in that retro. That's the uncomfortable part to say upward. What actually landed with leadership wasn't "agents don't work." It was: we were shipping unreviewable output, not unusable output. The code was fine. Our capacity to vouch for the system it was becoming wasn't. We weren't buying back velocity we'd lost to agents — we were buying back a coherence we'd never budgeted for in the first place. Once I could point to the specific diff sizes and the flat reviewer headcount, it stopped being a debate about agent quality and turned into a staffing conversation, which was the right conversation to have.

The rule to carry into your next planning conversation

Before you hand out the next agent seat, ask what governs judgment on your team, not what governs output. Typing speed was never the bottleneck. It was always how many people could hold the whole system in their head at once — and that number doesn't move just because everyone's fingers got faster.