When writing code stops being the bottleneck

There’s a pattern that shows up in teams bringing coding agents into their day-to-day work. The volume of proposed code climbs fast, within weeks. The volume that actually reaches production climbs much less. Pull requests pile up, reviews fall behind, and the team’s general sense is that there’s more work outstanding than before.

This isn’t a tooling problem. The bottleneck moved, and the structure of the team stayed where it was.

For twenty years we organized development teams around an assumption that rarely got discussed: the scarce thing was the capacity to write code. Everything else was arranged around it. The sprint exists to shield whoever is writing from interruptions. Estimation exists because writing takes an amount of time that’s hard to predict. Team size is set by how much there is to build. Even the billing models, by the hour or by person assigned, assume that human time spent writing is the unit of value.

That assumption is shifting. It hasn’t disappeared, but it’s no longer the only one that holds. And when the scarce input changes, a structure built around the previous one starts producing odd results.

That’s where pods come from. The word is generic and every company uses it for something slightly different, so it’s worth defining before arguing about it: a pod is a small delivery unit, two to four people, sized by how much it can review and decide rather than how much it can produce. Agents handle a good share of the production. The people define what gets built, review what’s proposed, and answer for what gets merged.

It’s a change in the unit of measurement, and like any change in the unit of measurement, it has consequences that aren’t obvious.

Why review sets the size

If a team can generate more code than it can review with attention, the surplus doesn’t vanish. It gets merged anyway, with less judgment behind it. Technical debt doesn’t come from writing badly. It comes from approving quickly.

This has an awkward implication for anyone looking to scale a team. Adding people to a team already saturated with review doesn’t increase delivery capacity, because every additional person also generates code that needs reviewing. Brooks’s old point about coordination cost still holds, and agents sharpen it: they raise the volume of artifacts to coordinate without reducing the cost of coordinating between humans at all.

A pod is sized the other way around. You ask how much a small group can review carefully in a week, and the committed scope follows from that. Not the reverse. The constraint is uncomfortable at first, because it looks like capping speed on purpose. What’s being capped is the speed of accumulating unreviewed work.

The metric worth tracking on a pod isn’t code produced, or tickets closed. It’s work merged, and rework afterwards. If throughput goes up and rework goes up in the same proportion, the pod isn’t delivering more. It’s delivering the same thing twice.

What changes in people’s work

When production gets cheap, the value concentrates in three moments that used to take up a fraction of the day.

The first is specification. An agent executes what it’s given with reasonable fidelity, including when what it’s given is wrong. Ambiguity in a requirement no longer runs into the friction of having to write the code; it gets implemented in full and surfaces only at review. Defining precisely went from good practice to being the job.

The second is review. Reading code you didn’t write, all day, is a different activity from programming. It takes more context, more reading, and more discipline not to approve out of fatigue. This is worth saying out loud because it gets discussed so little: sustained review is draining in a particular way, and a team organized around review needs rotation and breaks that a traditional team didn’t. Ignoring that doesn’t make the problem disappear. It moves it into the quality of the work.

The third is the decision to merge. When authorship blurs, accountability tends to blur along with it. It’s the most underestimated part of the model: a named person has to answer for everything that goes in. Not because they wrote the code, but because they decided it was sound. If that person isn’t defined, accountability spreads across everyone, which is another way of saying it rests with no one.

Hourly billing stops making sense

There’s an economic consequence worth spelling out, because it affects both sides of a contract.

If the human time spent producing goes down and the price is charged by the hour, whoever is building carries a structural incentive against their own efficiency. Every improvement to the process reduces the invoice. Nobody puts it that way, but the incentive exists and it acts.

Billing against deliverables or outcomes settles that misalignment, and introduces a different one. Fixing a price against a deliverable moves the estimation risk onto whoever is building, and taking on that risk means closing the scope. Closing it takes flexibility away from the client. It’s a real trade, not a net improvement: you gain predictable cost and lose the ability to change your mind halfway through.

Which is why the model doesn’t replace the others. They coexist, and choosing between them is the first decision of the project.

Where it works

The model pays off when these conditions broadly hold:

The scope is defined and verifiable. Written down isn’t enough. There has to be an acceptance criterion you can point at to say something is finished. With no way to verify, there’s no way to review at speed.

The codebase has tests and CI. Agents amplify whatever hygiene is already there, in both directions. On a project with solid test coverage, review leans on automated signals and the pod flies. On a project without tests, every change has to be checked by hand and the bottleneck closes completely.

The deadline is real. Pods earn their keep when there’s a hard time constraint: a launch, an integration with a third party, a regulatory obligation with a date attached. A small structure and billing against deliverables make sense when the calendar is the main problem.

The client can decide quickly. A pod blocks sooner than a large team, because it has fewer parallel workstreams to fall back on while it waits for an answer. If definitions take two weeks to come back, the speed advantage disappears entirely.

The work has edges. New modules, integrations, migrations, automation over a bounded domain. The sharper the boundary, the better it works.

Where it doesn’t

This matters more than the section above, and gets told less often.

Open-ended discovery. When the problem isn’t understood yet, going faster is counterproductive. A pod builds quickly in whatever direction it’s pointed, including the wrong one. The expensive part of a project is rarely building it. It’s having built it in the wrong direction. That stage calls for conversation, throwaway prototypes and time to think, not delivery capacity.

Support and ongoing operations. Support work is interruption, not delivery: priorities that change daily, incidents, availability. Committing to closed deliverables in that context forces a structure against the nature of the work. An integrated, available team fits better.

When the client needs to keep the knowledge in-house. A pod concentrates context in a few people and in the configuration of their tooling. That’s efficient, and it’s a transfer risk. If part of the goal is for the internal team to end up able to maintain the system, the model works against it and has to be compensated for deliberately.

Very small projects. Standing up a pod has a real setup cost: defining acceptance criteria, preparing the environment, tuning the review flow. Over three weeks of work, that cost never amortizes.

One more is missing, the one that comes up most often in practice and the only item on the list that work can reverse.

Legacy isn’t a blocker. It’s a prior stage.

In systems where the critical knowledge is tacit and lives in the heads of the people maintaining them, an agent has nothing to infer the unwritten rules from. And with no tests there’s no cheap way to verify what it proposes, so the whole verification load lands back on people, which is precisely the bottleneck the model set out to open.

The easy conclusion is that the model doesn’t apply to legacy. The accurate one is that there’s preparatory work, and that it’s considerably more contained than it looks. It has three parts.

Make the context explicit. An agent infers patterns from the code in front of it. If the project solves the same thing three different ways, it will pick any of the three, and it will be right all three times. What’s missing isn’t documentation in the classic sense. It’s the conventions in force per module, the architectural decisions along with the reasoning behind them, and three or four canonical paths through the real code that work as a reference for how things are done here. The areas better left untouched, too. That material gets versioned alongside the code, because it ages the same way the code does.

Move part of the verification into the pipeline. If human review is the scarce thing, anything a machine can check should be checked before it reaches a person: build, tests, static analysis, secret and dependency scanning, a cap on pull request size. Human review doesn’t disappear; it stops being spent on what doesn’t call for judgment. It’s worth starting with the checks in warning mode for a few weeks, to calibrate thresholds without slowing delivery down.

Measure coverage on the diff, not on the total. This is the point that unblocks the problem. Requiring coverage across an entire legacy system means a remediation project of several months before anything can start. Requiring it on new or modified code means whatever gets touched from now on comes with a test, and the old code doesn’t block. The debt stops growing on day one and shrinks through everyday work, particularly because scaffolding tests is one of the first places where assistance pays off well.

The approach has a limit worth stating: in modules that start with no coverage, the automated checks catch less, and human review remains the primary control there. It isn’t a complete solution. It’s what makes it possible to start before finishing.

On a project we’re working on now, that preparation was laid out as a four-week stage ahead of changing how the work gets delivered. Four weeks that produce no new functionality, and that’s the part to decide on with open eyes: what’s being bought isn’t speed, it’s the option to work differently afterwards. If the project won’t run long enough to amortize it, it isn’t worth doing.

The question underneath

None of this is specific to pods. The model is one possible answer to a shift already underway in any team that has brought agents into daily work: the volume of proposed code grew, and the capacity to decide what gets merged didn’t grow with it.

There are other answers. You can reinforce review inside the existing structure, change the approval criteria, or reach for tooling before reaching for organization. What doesn’t look sustainable is leaving the structure as it is and assuming the team absorbs the difference.

So the question that comes before choosing a model is a simpler one: if writing code is no longer the scarce thing on your team, what is, and who decides?