Your Agents Will Not Complain

A five hundred person engineering team and a five hundred agent engineering team are going to run into most of the same walls. Not just similar walls, but the same ones. The merge queue that can only land so many changes an hour doesn’t care whether the branches were typed by people. Neither does the test suite that takes forty minutes, or the module that six different workstreams all need to touch this week, or the service whose ownership was never really settled.

The difference I keep coming back to is that, on the first team, somebody will come and tell you about them.

Most of what we call “engineering scaling problems” were never really about the human headcount. They were about the number of concurrent changes in flight. Headcount was the thing that was primarily used to determine concurrency, based on an assumption of how many things a human could handle at once, so we got in the habit of talking about the two interchangeably.

2026, and the introduction of largely competent agents, changed this. Engineering teams beginning to run fleets of agents introduced the concurrency, but without the headcount. You now have a 10 person engineering team with the same concurrent PRs as your 200+ person engineering team used to have. The queue contention shows up. The flaky test that fails one run in twenty becomes a wall when you’re doing two thousand runs a day. The file that everything imports becomes the thing every workstream is waiting on. The undocumented deploy step that one person on the team “just knows” becomes a stall, over and over, with nobody to ask.

None of this is new. We built practices for all of it. The point I want to make is about which practices, and why they were never the bureaucratic overhead they sometimes get filed as.

Here’s the part I think is genuinely underrated: a big chunk of how engineering organizations stay honest is that people get annoyed, and annoyed people complain. Loudly.

An engineer who waits ninety minutes for CI to go green complains. An engineer who has to read four thousand lines of tangled code to make a two line change complains. An engineer who cannot find the owner of a service complains, usually loudly, and usually to their manager. An engineer who has to fix the same merge conflicts multiple times complains even louder. That complaint is a signal. It’s low-fidelity and it arrives wrapped in frustration, but it is a continuous, free, unsolicited stream of telemetry about where your engineering system is actually degrading. Most of the process improvements I’ve been part of started with somebody being irritated enough to say something.

An agent will not do this. Yes, you can add monitoring, and custom “feedback” tools, but that is not a true replacement. Even with a feedback tool, the agent’s feedback will never be prioritized the same as a human engineer’s would. An agent will burn forty minutes of wall clock waiting on the same CI run and report nothing. It will read the four thousand line file, spend an enormous amount of context doing it, produce a worse change than it would have against a clean module, and then tell you it’s done. It will not find the owner either, and it will make a reasonable-sounding guess instead. You get output that looks fine, arriving slightly slower and slightly worse, with no accompanying account of what it cost. The detection mechanism you were implicitly relying on quietly goes away, right as you turn up the volume on the thing it was detecting.

Your team is a monitoring system for your engineering org. Agents produce the same work and none of the alerts.

What Was Never Overhead#

Which brings me to the practical bit. If you’ve been running an engineering organization at any real size, you already built the things an agent fleet needs. A few of them translate almost directly:

• Code organization and simplicity. Small, well-bounded modules with clear seams were a human thing because humans have finite working memory. Agents may have a drastically larger context window than humans, but it is still finite context, and as we know: the more stuff you shove into context, the more unpredictable your outcome becomes. A module an engineer can hold in their head is a module that neatly fits in agent context. When your agent starts needing context across multiple modules and systems for an isolated task, you will end up with a proposed change that spreads across everything that was provided. Keeping modules/packages scoped and organized allows agentic PRs to be scoped and organized.
• CI-enforced merge requirements. Tests, linters, type checks, and required green builds existed because you can’t review your way to correctness at scale. That argument does not get weaker when the author is an agent; it gets considerably stronger, because the automated gate is now the only consistently applied judgment in the loop. If your merge requirements were advisory, they are about to stop being sufficient.
• Cognitive load management. Clear ownership, discoverable docs, one obvious way to do a common thing, a small number of blessed patterns. All of this was framed as being kind to your engineers. It is also, incidentally, the entire input surface for an agent trying to figure out what “correct” looks like in your codebase.

I don’t think any of this requires new invention so much as it requires believing that the old stuff was “load-bearing” (apologies for the Claude-word, but it’s actually applicable here). The skills, experience, and process that created effective engineering organizations with humans are still, or even more, applicable to agentic organizations.

On top of “let’s not throw away practices of successful organizations just because we have agents now”, I also suggest adding agent-specific metrics and observability insights. We can (and should) continue to monitor queue wait times, build durations, and flake rates, but we should also consider additional monitoring on the rate of merge conflicts, the merge conflict rate per file, and how frequently different areas of the codebase end up in agent context (with or without appearing in the final diff), as well as wall-clock and token spend per PR. We should be more aggressively tracking the time spent on code review, and the rate that agentic PRs are dismissed.

None of this is a reason to be pessimistic about agent-heavy engineering. If anything it’s the encouraging read: the work is mostly work you’ve done before, and the teams with genuinely good engineering hygiene are going to scale agents far more cleanly than the ones without it. But you should expect to find out about your bottlenecks on your own from here on.

The org that was already easy to work in is the org that agents will work well in.