How Anthropic builds engineering teams

The interesting thing about how Anthropic builds engineering teams is not the part everyone quotes. The part everyone quotes is that 80% of the code Anthropic merges is now AI-generated, with more than half of it merged automatically and a human giving the final approval. That number does the rounds because it sounds like a target you can adopt. It is not a target. It is a result, and the machinery that produces it is the actual story.

Read the Engineering Leadership teardown of how Anthropic runs AI-native engineering and the surprising thing is how conventional the org chart looks. Two-pizza teams: five to eight engineers, one product manager, one designer, one engineering manager. No new roles with “AI” in the title. What changed is not the boxes on the chart. It is what the boxes are downstream of.

The numbers are a result, not a plan

The headline claims from that teardown are easy to list and easy to misread. Teams run four to five projects in parallel where a traditional setup runs one or two. A five-person team is described as producing output closer to fifteen or twenty engineers. And — against the direction most companies have been moving — Anthropic expects to add more product managers per team, not fewer.

Take those at face value and the conclusion looks like a recipe: give everyone Claude Code, tell them to run more projects, hire a few PMs, wait for the 3–4x. Every one of those numbers is a single-source claim from one company describing itself, so hold them loosely to begin with. But even if they are exactly right, they are the wrong end of the causal chain to grab. The multiplier is what you get after the substrate is in place. Without the substrate you get the code volume and none of the safety, which is a worse position than where you started.

So the useful question is not “how do we hit 80%.” It is “what has to be true before 80% is safe.”

What the number is standing on

Two things, mostly. Neither is glamorous and neither shows up on the org chart.

The first is who they hire. Anthropic’s model is design-then-execute: an engineer holds the system in their head, decides the architecture, and hands the implementation to the model. That only works if the person doing the deciding does not need a proof-of-concept to know the shape of the answer. It is a model built for senior engineers, and Anthropic staffs it accordingly — the median engineer there carries far more experience than the median engineer at a Series A company, and they add senior people roughly as fast as they can build the onboarding to absorb them. There is no junior tier quietly providing throughput. The architecture-stays-human model assumes everyone can hold the architecture.

The second is review. When a model writes most of your code and merges half of it on its own, the thing standing between you and a bad afternoon is not the writing, it is the reading. Anthropic paid for that: automated review agents, security guidance baked into the generation prompt through CLAUDE.md, per-domain slash commands, MCP servers scoping what the agents can touch. The 80% figure rides entirely on that scaffolding being real and working. Pull it out and the same number describes a liability, not an achievement.

This is the anti-hype reading, and it is not a knock on Anthropic. They built the substrate and earned the number. The mistake is downstream: teams reading the number as a practice they can adopt on Monday, when it is the output of eighteen months of unglamorous plumbing and a hiring bar most companies cannot clear.

The bottleneck actually moved

Here is the part that transfers, and it is worth the price of the whole teardown.

When code gets cheap to produce, the constraint stops being production. If a team can generate four projects’ worth of code in the time it used to write one, the thing in short supply is no longer engineering hours. It is the two scarce resources on either side of the code: deciding what to build, and checking what got built. Both are human, and neither got faster.

That is why the PM ratio goes up. It reads as a paradox — more automation, more product managers — until you see that the automation moved the bottleneck onto the decision. When implementation was the slow step, one PM could keep several engineers fed with well-specified work. When implementation is fast, the PM is the slow step, and you need more of them to keep the faster machine supplied with things worth doing. Anthropic even stood up a dedicated Product Operations function whose whole job is the systems and tooling behind making decisions faster. That is a tell. You do not build infrastructure for a thing that is not your constraint.

And on the other side of the code, review became the skill. The teardown’s own line is that reviewing AI-generated work is now one of the most valuable things an engineer does. This is a real reallocation of what “good engineer” means. The value is not in typing the implementation — the model does that. It is in reading a diff you did not write, holding the system context to know whether it belongs, and catching the plausible-looking wrong answer before it merges. That skill was always latent in senior engineers. AI just moved it from a background activity to the main event.

The other structural moves fall out of the same logic. Multiple tech leads per team instead of one, because more parallel work means more decisions that need an owner and one person cannot be in five places. No dedicated QA role, testing distributed across the engineers who write the specs — which only holds if your test automation and evals are strong enough to carry it. Every one of these is a response to the same shift: the scarce thing is now judgment, so spread the judgment around and give it tools.

Where the advice breaks for you

Most companies are not Anthropic, and the gap is not pride, it is prerequisites.

If your throughput today rests on junior and mid-level engineers doing the bulk of the implementation, the design-then-execute model does not slot in — it asks for a team of architects you have not hired. The honest move there is not to fake seniority with a tool. It is to be clear-eyed that the model assumes a bench you may need to build first.

If you do not yet have the review scaffolding — the automated checks, the scoped agents, the eval harness that lets you trust a merge you did not read line by line — then adopting the code volume before the review capacity is how you end up with more code and less confidence. The volume is the easy half to copy and the dangerous half to copy first. A team building the review infrastructure while the volume ramps should expect something closer to a 1.5–2x lift than 3–4x, and should say so out loud rather than quietly missing a number that was never theirs to hit.

And outcomes-based prompting — define the success criteria up front, let a separate grader check the output against the rubric — is genuinely good practice, but it wants a rubric. It fits well-scoped delivery and fits discovery badly. If the work is figuring out what the thing even is, there is no rubric to grade against yet, and pretending otherwise just produces confident output aimed at the wrong target.

What to do Monday morning

Do not start with the 80%. Start with the two things it stands on.

Look at review first, because it is the cheaper of the two to move and it is where the risk lives. Before you let a model write more of your code, ask whether you could safely read the increase — whether your CI, your automated checks, and your senior review bandwidth could absorb twice the diff volume without waving it through. If the answer is no, that is your first project, and it is worth doing whether or not you ever chase Anthropic’s ratio.

Then look at where your bottleneck actually is. If your engineers are already faster than your product decisions, the fix is not another coding tool — it is more decision capacity, which might mean a PM, might mean clearer ownership, might mean a Product-Ops-shaped investment in how choices get made. And treat code review as a first-class skill you hire and promote for, not a chore you rotate through. That is the durable lesson under all the numbers: AI did not remove the human from the loop. It moved the human to the two places automation cannot reach — deciding what is worth building, and judging whether what got built is right.

References

• How Anthropic secures its AI-native software development lifecycle — Anthropic (source of the 80%-of-merged-code figure and the review/security scaffolding).
• How Anthropic builds AI-native engineering — Engineering Leadership (team composition, parallel-project and multiplier claims, the PM-ratio direction, the “reviewing is the most valuable skill” framing).
• How Anthropic engineering teams use Claude Code every day — Codingscape (onboarding and codebase-navigation practices).