How Anthropic Builds AI-Native Engineering Teams
Insights from my conversation with Katelyn Lesse, Head of Platform Engineering, Anthropic.
Intro
With AI-assisted engineering being the standard way of building software these days, every company is trying to answer the same question:
What does an AI-native engineering team actually look like?
To help us with this, I recently had the pleasure of talking with Katelyn Lesse, Head of Platform Engineering at Anthropic.
We talked about a LOT of different topics regarding Anthropic’s engineering culture, how they work, and how they build their products. She shared a lot of interesting insights, some of which will be shared today, and some in future articles.
In today’s article, I’ll share, based on our conversation, how Anthropic builds AI-native engineering teams.
This is an article for paid subscribers, and here is the full index:
- What does AI-native actually mean at Anthropic?
- The structure of AI-native teams
- Similar structure with an important difference
- With many projects happening simultaneously in the team, there’s a bigger need for PMs
- They are even looking for more PMs in a cross-functional team?
- No dedicated QAs, automated testing + AI Evals are more important than ever
- All of their code is AI-generated
- Defining the desired outcome is key when working with AI
🔒 Additional use cases for using AI in their work
🔒 Responsibility + accountability should always be on engineers, never on AI
🔒 AI-native engineers are becoming tech-agnostic
🔒 How has the onboarding of new engineers changed from 1-2 years ago?
🔒 Working with AI agents should be the new normal for all companies
🔒 Last words
Additionally, earlier this year, I talked with Thibault Sottiaux, Head of Codex at OpenAI, on how OpenAI is building AI-native engineering teams. If you haven’t read the article, I highly recommend doing so here:
Let’s start!
What does AI-native actually mean at Anthropic?
As mentioned in the article AI-Native Engineering Leadership, there are many definitions of being “AI-native” across different companies. I’ve asked Katelyn about what it means at Anthropic. She mentioned the following.
Being truly AI-native means that AI is built into the workflow so that it doesn’t feel like an extra tool.
Whether you’re writing code with AI in collaboration or running autonomous AI systems in the background, AI should become a part of the process rather than something separate.
When it works seamlessly and feels natural, that’s when you are AI-native.
The structure of AI-native teams
Throughout our conversation with Katelyn, one point she mentioned many times is the following:
Many aspects of software development haven’t changed, and likely don’t need to change, even as AI becomes deeply integrated into engineering teams.
Therefore, that’s exactly the case in the Anthropics team structure. They still use the traditional 2-pizza cross-functional team structure, with 5-8 engineers in the team, an engineering manager leading the team, a PM, and a designer as part of the team.
The reasoning for it is the following:
Teams still need enough people to build, operate, and maintain systems over time. Ownership, reliability, and shared knowledge are crucial, regardless of how much AI is involved. The difference is just that AI gives everyone significantly more leverage.
Similar structure with an important difference
In a traditional team, you had 1 tech lead, who would lead the project from the tech perspective and coordinate with other teams, while other engineers on the team focused more on implementing features and completing tasks.
Today, almost every engineer is expected to take on a tech lead role if needed. The reason are AI tools, which can enable individuals to accomplish a lot more than before.
As a result, the team size is unchanged, but the work changes.
A team of 8 engineers that previously focused on 1 or 2 projects at a time can now potentially run 4 or 5 projects in parallel.
The team still owns and maintains the same systems, but AI enables everyone to execute far more work in parallel.
With many projects happening simultaneously in the team, there’s a bigger need for PMs
Interestingly, Katelyn mentioned that AI has not reduced the need for PMs, especially TPMs, product managers who really understand the underlying tech as well. She sees the role as even more important.
That’s pretty different from what some other companies are doing, where they actually have fewer PMs. Like OpenAI with a 30:1 engineers per PM ratio, and companies like Telnyx or Portkey, where they work with 0 or a few PMs.
This is her reasoning: With engineers being able to build and ship software much faster with AI, the bottleneck shifts from implementation to decision-making. And the challenge is no longer whether a team can build something, but whether it is building the right thing. So, that’s where PMs come in.
Additionally, Anthropic has a specific role inside their company called Prod Ops (product operations), with the role of making systems, processes, and tools more effective so PMs and teams can make better decisions more quickly and achieve better results.
She sees that in an AI-native environment, strong product management becomes even more valuable because it ensures that increased engineering capacity is focused on the highest-impact problems.
They are even looking for more PMs in a cross-functional team?
Traditional teams had 1 product manager supporting a team of engineers. They have the same setup → 1 PM per team, but she believes this will change soon in their teams.
There are simply more decisions to make, more customer needs to understand, and more projects to coordinate. Because of this, her team is finding that they need more PMs than before.
She believes every team needs someone who deeply understands what customers need, what the team is trying to achieve, and what should be built next.
No dedicated QAs, automated testing + AI Evals are more important than ever
They don’t have a dedicated QA engineer inside the team. Testing is a shared responsibility across the team.
They also rely heavily on automated testing. And because AI allows engineers to generate code much faster, they have to be careful about how tests are written.
They value the traditional quality pyramid:
Most unit tests
Lesser integration test
Even fewer e2e tests
And specifically, they focus on creating quality unit tests and a smaller number of slower end-to-end tests. This helps keep development moving quickly and prevents the CI pipeline from becoming a bottleneck (long time for tests to pass).
Another important part of testing is evaluating their AI models and products (AI Evals). They invest a lot of time in building and maintaining evaluation systems that help them measure quality and ensure new models, products, and platform updates perform as expected before reaching customers.
This work is not owned by a single team. Engineers spend a lot of time on testing and evals, and PMs are also heavily involved as well. Everyone contributes to making sure products meet a high standard before they are released.
She also mentioned that roles inside the team have become a lot more flexible and that there is no clear separation of responsibilities.
Like everyone these days, they are also learning as they go, they don’t believe they have found a perfect formula, they are adjusting based on what they see works for them and what doesn’t.
All of their code is AI-generated
I asked Katelyn if her teams have a similar sentiment to what Boris Cherny (Head of Claude Code) has mentioned, which is that all of his code is AI-generated these days.
And she mentioned that it’s what their teams do as well. However, the important thing that she added is that this doesn’t mean AI is building software on its own.
She mentioned that engineers play the most important role in designing systems and making architectural decisions. AI is an excellent collaborator during this process, but engineers are responsible for deciding how large and complex systems should be built.
Once the design is clear, the implementation is largely handled by AI agents. Rather than switching back and forth between AI agents generating code and manually writing code, it’s better to guide the agents until they produce the desired result.
This is also a very important thing she mentioned:
The effective use of AI is not about asking an LLM to generate code and accepting the first answer. You should continuously steer the agent, provide feedback, and let it test and improve its own work until it meets the required standard.
Because of this, she believes reviewing AI-generated work has become one of the most valuable engineering skills.
Defining the desired outcome is key when working with AI
Additionally, her top tip for working with agents is to define the desired outcome instead of simply assigning a task.
Rather than saying, “Build me a dashboard,” you should clearly describe what the finished dashboard should accomplish, what success looks like, and any important requirements or examples.
To support this workflow, her team built a feature called Outcomes in Claude Managed Agents.
You provide a simple description of the desired result, and a second AI agent evaluates whether the generated solution meets those expectations. If it doesn’t, the coding agent automatically iterates and tries again before presenting the final result.
The clearer you define the outcome, the better the AI performs.
Good prompts are less about telling the AI what to do step by step and more about clearly describing what success looks like.