Author: Lincoln Wang | Founder of MindsLeap | Global Partner at Founders Space | Founder of Founders AI Club
On May 8, 2026, Claude's official channel published a talk titled Running an AI-native engineering org. In the talk, Fiona Fung, engineering lead for Claude Code, made a point that matters well beyond developer tooling: when agentic coding moves from an individual productivity tool to a default team workflow, the hardest question is often no longer whether AI can write code. It is whether the organization's existing processes can absorb the new volume of code.
That is what makes the talk worth paying attention to. It does not stop at whether AI coding tools are useful. It moves the question up a level: when AI makes coding faster, where does the bottleneck go?
Fung's answer is direct. In the past, engineering bandwidth and coding throughput were expensive, so many software development processes were designed around the assumption that writing code was slow. Teams spent large amounts of time on upfront planning, technical debate, ownership boundaries, and scheduling because implementation itself carried a high cost.
Once AI makes prototyping, refactoring, and code generation cheaper, the bottleneck moves.
In her talk, Fung described new pressure points around validation, code review, cross-functional collaboration, security, maintenance, and product judgment. In other words, AI does not remove the need for engineering process. It exposes process problems faster.
One especially important idea is that many processes can fail quietly. A process is usually introduced to solve a specific problem, but processes rarely remove themselves. Teams keep adding new rules, more SLAs, and more checkpoints until they eventually discover that workflows designed for an old bottleneck no longer fit the new way work happens.
For companies adopting AI coding tools, this is a practical warning. An AI-native engineering organization is not created by giving every engineer a coding agent account. The real questions are harder: when code output rises, who reviews it? Who maintains it? Can CI and build systems keep up? Are security and permission boundaries clear? Who still owns product taste, legal risk, and trust decisions?
Inside the Claude Code team, Fung described several changes in working style.
Technical debate changes. In the past, architecture discussions could remain stuck on the whiteboard. Now, when implementation cost drops, a team can generate multiple pull requests and compare real code, real tradeoffs, and real downstream impact. The core idea is simple: when building gets cheaper, arguing gets more expensive.
Code review is also being decomposed. Claude can take on a large amount of style review, linting, PR feedback, test generation, and issue discovery or repair. But Fung still emphasized human expert judgment in areas such as legal risk, risk tolerance, trust boundaries, security-sensitive code, and product taste. The point is not full automation. It is to let machines handle the checks they are good at while reserving real judgment for people.
Role boundaries are becoming less rigid as well. Fung noted that PMs and other traditionally non-coding roles can now do more engineering-adjacent work, while engineers can use AI to handle more content, design, and cross-functional communication tasks. That means AI-native organizations need to rethink not only engineering productivity, but also team composition, hiring standards, and collaboration models.
The organizational design is also revealing. Fung said that within the Claude Code team, she prefers keeping the organization as flat as possible and wants managers to enter first as ICs: using the product, understanding the code, and learning the workflow before taking on management responsibility. Behind that is a strong dogfooding logic. AI coding tools are not an external productivity plugin. They are the underlying working mode of the team itself.
So how can a company know whether this transition is actually working?
Fung mentioned three observable metrics.
First, onboarding time. How long does it take for a new engineer, designer, or product manager to begin making meaningful contributions?
Second, PR cycle time. This metric does not only show whether AI tools are being used well. It also reveals other bottlenecks in the engineering system, including build infrastructure, CI, and product platform readiness under higher commit volume.
Third, the share of Claude-assisted commits. According to Fung, in the Claude Code team, every commit is Claude-assisted by default. She even said she had not seen a non-Claude-assisted commit in roughly four months.
The value of these metrics is that they turn AI engineering transformation from a vague feeling of higher productivity into observable organizational signals.
For Chinese companies, the lesson is not to copy the Claude Code team mechanically. The useful takeaway is a different way to look at AI adoption.
Many organizations are still at the tool procurement stage: buying a coding agent, connecting an internal knowledge base, and testing a few demos. But if AI truly enters the core engineering workflow, the organization must answer deeper questions:
- Is the existing review mechanism still enough?
- Can engineering infrastructure handle more frequent commits?
- Are responsibility boundaries still clear?
- Which processes should be automated, and which should be removed?
- Where must human judgment remain in charge?
This is where the term "AI-native organization" is often misunderstood. It does not mean an organization with many AI tools. It means the organization's processes, roles, review systems, metrics, and governance models begin to be redesigned around the new production speed created by AI.
Seen from this angle, the central question for an AI-native engineering organization is not whether the model is powerful enough. It is whether the organization can keep up with the speed the model introduces.
In the past, software engineering management was largely about prioritizing work under scarce engineering bandwidth. As AI coding tools become mainstream, the new management focus will become how to validate more code, reduce friction from old processes, and preserve quality, judgment, and accountability at a faster pace.
That may be the most important news point from the talk: AI coding tools are pushing software engineering from a coding efficiency question into an organizational design question.
Source Note
This article is Lincoln's interpretation of the Claude official channel video Running an AI-native engineering org, published on May 8, 2026 and presented by Fiona Fung.
About MindsLeap
MindsLeap is the China partner of Founders Space, a leading Silicon Valley incubator. We connect global frontier innovation with the real transformation needs of Chinese entrepreneurs and enterprises. Through AI strategy, founder communities, innovation study tours, and executive training, MindsLeap helps organizations build stronger cognition, methods, and execution capabilities for the AI era.
This article was translated and adapted from the Chinese original with AI assistance.