Engineering team design in the agentic coding era
AI can make code cheaper to produce without making software delivery proportionally cheaper. This changes the trade-offs around team size, seniority, review, and ownership.
There is a version of the AI coding story where engineering teams get dramatically smaller. If one engineer can run several coding agents at once, the obvious conclusion is that a four-person team should eventually be able to produce what an eight- or ten-person team used to produce. Some teams may be able to do that, but I don’t want to design an org around the assumption that code generation translates directly into engineering productivity.
The studies measure different parts of the job, from how long a coding task takes to how reliably a team ships software. METR's 2025 randomized study had experienced open-source developers work on repositories they knew well and found that they took 19% longer when AI tools were available, even though the developers believed AI had made them faster. METR tried to repeat the experiment with newer tools and said in February 2026 that the newer data was too affected by selection effects to give a reliable estimate, although it did suggest that tools had improved. Google's 2025 DORA research is more positive, finding a relationship between AI adoption and higher delivery throughput and product performance, but it also still finds a negative relationship with delivery stability.
I use AI coding tools constantly and they obviously change what one engineer can attempt. Writing code is still only one part of getting a change into production. A model can generate a patch quickly, but someone still has to decide whether the patch solves the right problem, fits the architecture, introduces weird failure modes, can be operated in production, and should be merged at all. METR recently had maintainers review AI-generated patches that had already passed SWE-bench's automated grader and found that roughly half still would not have been merged. A 2026 longitudinal study of professional engineers also found a shift away from code creation and toward what the authors call supervisory engineering work: directing, evaluating, and correcting AI output.
If implementation gets cheaper but verification, architecture, product judgment, and coordination don’t get cheaper at the same rate, those parts of the job can limit how much a team ships. The team should be designed around the work that’s still scarce rather than around how many people can physically type code.
In the pre-AI model, it was normal to think about capacity in engineers. A squad with six engineers could take on more implementation than a squad with three, even if the relationship was never perfectly linear. With agents, the unit gets fuzzier because one engineer can have several changes in progress at once, but the team still needs enough time to review and ship them safely. Review queues can get longer, test failures can multiply, architectural inconsistency can creep in, and the number of things somebody has to keep in their head can increase faster than the useful output does.
Smaller teams make sense only when the surrounding system is strong enough to support them. A mature codebase with good tests, clear service boundaries, safe deployment, useful observability, and an internal platform that makes the right thing easy is a much better candidate for a small agent-heavy team than a tightly coupled system with slow feedback and a lot of tribal knowledge. DORA's 2025 work makes a similar point: high-quality internal platforms are strongly associated with organizations getting more value from AI.
It also changes what I look for in engineers. I want engineers who can own a problem end to end, decompose it well, give an agent enough context to do useful work, recognize when the output is subtly wrong, and make good tradeoffs when the requirements are ambiguous. Technical depth still matters, but the value of judgment goes up when producing another implementation is cheap. The person who can generate five patches is less useful than the person who knows which two should exist and can tell whether either is actually safe.
I’ve written before about the problems with senior-heavy teams, and AI can make the opportunity problem worse if all of the interesting judgment work gets concentrated in the most experienced people while everyone else becomes an agent operator. Junior and mid-level engineers still need real ownership, debugging experience, design work, and chances to build taste. If we automate away every piece of work that used to teach those skills, we eventually create a team full of people who are very good at supervising systems they never learned how to build.
The manager and technical lead roles change too. If an engineer can have three or four agents producing changes in parallel, review capacity and change coordination become things you have to manage deliberately. I prefer to keep fewer changes in flight so it stays clear who owns each one. The goal is to ship changes that fit together without leaving the team with a pile of verification debt.
This also changes how we can tell whether a smaller AI-native team is actually replacing the output of a larger pre-AI team. Lines of code, pull request count, and agent task completion are almost useless for this. I care more about how long it takes to get a meaningful change from decision to healthy production, how much review time it consumes, how often it gets rolled back, what happens to incident rates and support load, whether the system stays maintainable, and whether users actually get more value. If those things improve with fewer people, then the team really is more productive.
In the near term, good teams are more likely to hold headcount flatter while taking on more scope. A small team might also own something that previously required a larger one if the architecture and tooling are already good. In messy systems, AI may just let us produce mess faster.
Before setting a headcount target, it helps to ask what work remains scarce after code generation gets cheap. Right now that still looks a lot like judgment, context, review, architecture, product understanding, and operational responsibility. The smallest useful engineering team has enough people to carry all of that without quality collapsing.