Anthropic is in the unusual position of building AI tools while also being one of the more instrumented case studies of what happens when a software organization actually uses them. A recent Pragmatic Engineer look inside Anthropic's engineering practices describes a company where Claude models now handle a growing share of code review and testing, while the org chart itself hasn't changed much at all.
This article covers what specifically got automated at Anthropic, why the team structure stayed the same even as AI took on more of the routine work, and what that combination suggests about where human engineering judgment is actually load-bearing.
Dogfooding as a forcing function
Dogfooding — using your own product internally, the way your customers would — is common practice, but it means something different for a company whose product is a general-purpose AI model rather than a narrow tool. Anthropic's engineers use Claude for code review and testing automation as part of daily workflow, not as an experiment bolted onto existing process. That distinction matters: a company using its own frontier model in production engineering has a much stronger incentive to notice where the model actually helps versus where it just looks helpful in a demo.
This is the same dynamic that shows up whenever a vendor deeply dogfoods its own tooling — the failure modes get found and fixed faster because the people hitting them are also the people who can change the product. It's a different quality signal than a customer case study, because the customer and the vendor are the same organization.
The most convincing evidence that an AI coding tool works isn't a benchmark — it's a company betting its own engineering velocity on the tool it sells.
Two-pizza teams didn't disappear — they got busier per person
Anthropic has kept Amazon's well-known two-pizza team structure — teams small enough to be fed by two pizzas, historically justified as a way to preserve communication speed and ownership clarity as a company scales. What's notable is that this structure persisted even as AI tools took over a growing share of routine development tasks. If anything, small-team structure becomes more valuable once AI absorbs the mechanical parts of the job, because the remaining human judgment calls — architecture, tradeoffs, what to build at all — benefit from tight ownership and short communication paths, not from more people in the loop.
This runs counter to a common assumption that AI-augmented engineering should shrink team sizes or flatten hierarchies dramatically. What Anthropic's structure suggests instead is narrower: automation changes the mix of work a team does, not necessarily how many people the team needs to coordinate the work that's left.
Where human oversight stays central
The report is explicit that engineers still own complex architectural decisions — AI accelerates iteration speed on the mechanical layers (writing tests, reviewing routine diffs) without taking over the judgment calls that determine whether an architecture is sound in the first place. That split lines up with a broader pattern across AI-native engineering orgs: the tasks that get automated first are the ones with a clear, checkable correctness criterion (does this test pass, does this diff match the style guide), while the tasks that stay human are the ones where correctness is a judgment call informed by context the model doesn't have — business priorities, technical debt tradeoffs, organizational history.
| Automated at Anthropic | Still human-owned | |
|---|---|---|
| Code review (routine) | Claude-assisted | — |
| Testing automation | Claude-assisted | — |
| Architectural decisions | — | Engineers |
| Team structure / ownership | — | Two-pizza teams, unchanged |
What this means for builders
Teams evaluating how far to push AI into their own engineering workflow have a useful reference point here: automate the parts of the pipeline with a checkable pass/fail criterion first, and expect that to change what your engineers spend time on rather than how many engineers you need. Anthropic's structure is also a reminder that AI adoption inside an engineering org isn't primarily an org-chart decision — it's a workflow decision that happens to leave the org chart alone.
The more useful question for most teams isn't "how many engineers can AI replace" but "which of our existing review and testing gates already have a clear correctness signal we could hand to a model" — that's the category of work Anthropic's own experience suggests is ready first.
Conclusion
The most interesting thing about Anthropic's internal engineering practices isn't that AI accelerated their development cycle — every AI lab claims that. It's that the acceleration didn't require restructuring how the company organizes its people. Small, high-ownership teams paired with AI handling the mechanically checkable work looks less like a transitional phase and more like a stable equilibrium — one other engineering organizations dogfooding their own AI tools should expect to converge toward as well.