When coding becomes cheap, what suddenly becomes expensive? The answer, according to Fiona Fung, who leads engineering and product for Claude Code and Cowie at Anthropic, is nearly everything else. In a candid talk at Anthropic’s developer conference, Fung outlined how the explosion of AI-assisted coding has forced her team to fundamentally reshape planning rituals, code ownership norms, team structures, and verification processes. The shift, she argues, isn’t just about adopting new tools—it’s about recognizing that the bottlenecks that once choked software development have moved, and the old playbooks no longer apply.
“This is not the first time our industry has had to adapt,” Fung noted, recalling her early days on Visual Studio in the early 2000s when software shipped on CD-ROMs and hard deadlines meant physical manufacturing timelines. Each wave of change—from online distribution to agile methodologies—was triggered by a shift in what was expensive. Now, she says, engineering bandwidth is no longer the scarce resource. Code generation is fast. What matters now is what happens after the code is written.
The New Bottlenecks: Where Engineering Slows Down Now
For years, software teams built processes around the assumption that writing code was the expensive part. Planning cycles were lengthy because engineering time felt precious. Code reviews were sparse because every commit represented significant human effort. Refactoring was scheduled sparingly because it pulled engineers away from “real” product work.
That equation has flipped. On the Claude Code team, Fung says coding is rarely the slow part anymore—and more than that, the sheer volume of code being generated has changed dramatically. “The throughput is different,” she said. “There are new ways to break things.”
The bottlenecks have migrated to what happens after code exists:
- Verification and testing — Catching bugs before users find them
- Code review — Keeping up with the volume while maintaining quality
- Cross-functional coordination — Security review, legal sign-off, product sense
- Maintenance — The long-term cost of code that now gets written far more easily
Fung describes these as processes that “quietly stop working”—the gradual accumulation of rituals that made sense when code was scarce but now create friction when code is abundant.
Rewriting the Team Norms
When bottlenecks shift, the rules that governed work under the old regime need to be questioned. Fung walked through several specific norms the Claude Code team has rewritten.
Planning: From Six-Month Roadmaps to JIT Execution
The team has dramatically reduced upfront planning. When Fung first joined, she asked about a six-month roadmap. They wrote one. It was useful for about three months. By the new year, too much had changed. Now, she describes their approach as “JIT planning”—just enough, just in time. “Because prototyping and code generation is just not the bottleneck that it used to be,” she said, “how do you make sure you do just the right amount in the right time?”
Technical Debates: Code Wins
One of the most striking changes is how technical disagreements are resolved. In the old model, engineers would debate in meetings, debate on whiteboards, debate in documents. Now, Fung says, “when building is cheap, arguing expensive.” On her team, the preferred approach is to generate the options as code—multiple PRs demonstrating different approaches—and let the implementation and its impact speak for itself. She described doing exactly this with Boris when they had a technical debate about an API refactoring: she generated three versions, each with full context for how they would affect callers, and they debated the actual code rather than abstractions.
But she emphasized that this requires strong team culture around alignment. With code so easy to generate, the last person to push a PR shouldn’t win. “It makes it even more important to make sure you have good team culture that can have open, honest technical debates,” she said.
Design Docs: Reduced, but Not Abandoned
The team has largely replaced design documents with working prototypes and PRs. Instead of writing a spec and reviewing it, teams ship something usable, get internal feedback, and iterate. “We really want to get it out to all of you and then hear all the excellent feedback,” Fung said, referring to the conference attendees who use Claude Code. However, she acknowledged that certain scenarios—especially asynchronous discussions across time zones—still benefit from written design docs. The key is making the tradeoff consciously rather than defaulting to old habits.
What They’ve Doubled Down On
While reducing planning and design docs, the team has invested more heavily in verification. Fung calls this “shift left”—catching bugs earlier in the pipeline rather than relying on later-stage testing. The logic is straightforward: when throughput is higher, the surface area for problems is larger. More automation at the point of commit, more linting, more test generation. The goal isn’t just faster shipping; it’s shipping with confidence regardless of role. “I just really want to make sure everybody, regardless of roles, just has a lot higher confidence for the change that they’re putting in,” she said.
Team Makeup in the AI Era
Perhaps the most provocative part of Fung’s talk concerned hiring and team structure. Two profiles the Claude Code team heavily indexes on:
- Creative builders with product sense — People who see problems and want to ship products that solve them, with strong instincts for iteration and delightful experiences
- Deep systems expertise — Particularly important when building infrastructure like remote execution where distributed systems knowledge remains essential
What they index less on? Raw coding throughput. “Thanks to the models, we just saw a lot more efficient,” Fung said.
The blurring of roles is another significant shift. Non-engineers—designers, PMs—are now shipping code with AI assistance. Conversely, engineers are handling tasks traditionally handled by content designers, using AI to help with writing that needs to be concise and clear. “I found that Claude and AI has really augmented roles kind of all around,” Fung said.
On organizational structure, Fung advocated for keeping teams as flat as possible and requiring managers to start as ICs first. “I wanted every manager in Claude Code to start out as an IC first,” she said. “Earn some street cred with the team and really learn how to be an effective engineer.” She acknowledged this approach raised eyebrows with recruiting partners who found it unconventional, but she tied it to her broader philosophy: heavy dogfooding, staying close to the code, and maintaining agility.
Rolling It Out: Mandates vs. Autonomy
For each team norm, Fung described a balance between what must be followed and what can be adapted locally. The Claude Code team has several core principles that are non-negotiable:
- Every team member, including cross-functional partners, uses Claude Code
- “Claudify everything you can”—always ask whether AI can help automate a task
- Explicit permission to kill old processes
But within pods, there’s significant autonomy. How each team handles triage, planning rituals, stand-ups, and which workflows to automate first is left to the teams themselves. “We don’t usually mandate thou shalt automate this,” Fung said. “We have some suggestions and learnings, but always give room to your team.”
The key question to ask of any process, she suggested, is whether it’s still serving its original purpose. “Processes will kill themselves,” she noted. “But as your supporting teams, it’s really important to always get that fast feedback for your team of what are the things that, you know, like are we spending a lot of time on that could be going away.”
Does It Actually Work?
Fung offered three general metrics the team tracks to assess whether the approach is succeeding:
- Onboarding ramp-up time has dramatically reduced — How quickly new engineers, designers, or PMs can become effective on the team
- PR cycle time is shortening — Though she noted this requires careful examination: if PRs are moving fast but CI can’t keep up, that’s a pipeline problem, not an AI adoption success
- Cloud-assisted commits are now the default — On Claude Code, nearly every commit is AI-assisted; she said she hasn’t seen a non-cloud-assisted commit in roughly four months
But Fung cautioned against obsessing over commit counts. “Throughput is great,” she said, “but really think about how you measure what it is that you’re actually really trying to solve.” Quality and reliability matter just as much as velocity, especially when the volume of code being generated is so much higher.
Unresolved Questions
Fung ended by sharing several questions she’s still working through:
- Platform-specific org structures — With engineers now able to more easily flex across iOS and Android, does the traditional model of separate iOS and Android teams still make sense?
- Automation balance — How much should be fully automated versus verified by humans? She noted that as model capabilities improve, the right balance shifts—something that might have required heavy verification six months ago might be trustworthy now.
- Role blurring and equity — As roles blur, how do teams ensure everyone feels equally productive and valued?
What to Take Back
Fung’s advice to the audience was simple: pick your “noisiest” workflow—the one that’s most expensive, or that you or your team dread. Ask whether it’s still serving its purpose. She shared a story of being on a team with a weekly review involving 50 people in a large room, where most attendees were on laptops until it was their turn to give a status update. She asked why they were having it. Everyone agreed it wasn’t worth it. They canceled it.
The broader lesson is one of continuous questioning. “What served you prior may not serve you any longer,” Fung said. The shift in bottlenecks isn’t a one-time adjustment—it’s an ongoing muscle that engineering leaders need to develop. As AI capabilities continue to improve, what works today may need to change again tomorrow. The teams that thrive will be those that treat their processes as living artifacts, always subject to revision, always open to the question: is this still serving us?