Restructuring Processes for AI-Native Teams: What Happens When Coding Is No Longer the Bottleneck

Introduction

When AI coding tools make code generation more efficient than ever before, where exactly does the team's bottleneck shift to? Fiona Fung, engineering and product lead for Anthropic's Claude Code and Co-work, shared her hands-on experience leading teams — from Meta and Microsoft to Anthropic. She discovered a core pattern: processes that once worked may be quietly becoming obsolete.

This isn't a theoretical discussion. It's a real-world process restructuring experienced firsthand by an engineering leader within an AI-native team. From planning approaches and code review to team architecture, every aspect is being redefined.

The Migration of Bottlenecks: Coding Is No Longer the Most Expensive Thing

From "Writing Code Is Expensive" to "Verification Is Expensive"

For years, engineering bandwidth has been the most expensive resource in software development. We built entire processes around this assumption: waterfall development, detailed design documents, rigorous scheduling — all because "writing code is expensive."

But now, within the Claude Code team, coding is rarely the slow part anymore. Not only has speed increased, but output throughput has undergone a qualitative transformation. Fiona recalls that when she first started vibe coding last year, AI would still make basic mistakes (like using constants everywhere), but model capabilities have improved dramatically since then.

This shift aligns closely with the Theory of Constraints in software engineering. Proposed by Eliyahu Goldratt in 1984, its core idea is that a system's overall throughput is determined by its weakest link. When AI tools boost coding speed by 5–10x, previously inconspicuous downstream stages — testing, review, deployment — immediately become the new system bottlenecks. This mirrors the experience of Lean Manufacturing: after automating one process, you must simultaneously optimize the entire value stream, or you're simply moving "inventory" from one place to another.

With coding no longer the bottleneck, new bottlenecks have emerged:

• Verification: Is this code correct?
• Code Review: Who reviews such massive volumes of code?
• Cross-functional Collaboration: Can security, legal, and other functions keep up?
• Maintenance Costs: How do you maintain all this generated code?

Historical Echoes

Fiona places this transformation in a broader historical context: in the 2000s, software was still distributed on CD-ROMs, and Visual Studio 2005 had to get its code to the manufacturing lab for disc burning before the deadline. When online distribution became possible, the entire software delivery model changed along with it. The transformation AI brings today is fundamentally the same kind of paradigm shift.

Rewriting Team Norms

Planning: From Six-Month Roadmaps to JIT Planning

The Claude Code team has drastically reduced upfront planning. When Fiona first joined, she tried to create a six-month roadmap, only to find it obsolete three months later. Now the team uses "JIT Planning" (Just-In-Time Planning) — because prototyping and code generation are no longer bottlenecks, excessive upfront planning is actually waste.

"JIT Planning" borrows from the core philosophy of the Toyota Production System: produce only what's needed, only when it's needed. In software engineering, this aligns with the Agile Manifesto's (2001) principle of "responding to change over following a plan," and reflects the Lean Software Development principle of "Defer Commitment." The reason traditional waterfall development emphasized detailed upfront planning was fundamentally because the cost of change was extremely high — a requirements change meant rewriting large amounts of code. When AI compresses code generation costs to near zero, the benefits of "deferring decisions" increase dramatically, while the risks of locking in solutions too early become more pronounced.

Specific changes:

• Fewer design documents: Discussions no longer revolve around documents but around PRs (Pull Requests) and prototypes
• Fewer product reviews: Go straight to prototyping, let internal users try it out, and collect feedback
• Technical debates settled with code: When Fiona and Boris have a technical disagreement, she no longer walks to the whiteboard — instead, she has Claude generate PRs for three different approaches, directly comparing implementation results and impact on callers

"When building is cheap, arguing is expensive."