A video presentation by the leader of the Claude Code team reveals important elements and methods behind a major organizational transformation: the rearrangement of functions, workflows, and responsibilities. This article is based on repeated viewing, interpretation, and reconstruction of the ideas conveyed in that presentation.
At first glance, the talk appears to be about how the Claude Code team uses AI tools for software development. But as we look deeper into their actual practices, it becomes clear that the topic is far more profound. When AI makes “writing code” increasingly easy, the truly scarce capability within software organizations is quietly shifting.
The Claude Code team is not merely discussing a future trend. They are describing changes they have already experienced. Their daily ways of working, making decisions, and collaborating have all been restructured by the involvement of AI. These changes ultimately point to one central conclusion: the key to software development is no longer writing code, but judging what code should exist.
From “Writing Code” to “Judging Code”: How the Bottleneck Has Shifted
Claude Code is an agentic coding tool launched by Anthropic. It can not only generate code, but also directly modify files in a codebase, run commands, create pull requests, analyze problems, add tests, and integrate deeply with development workflows such as GitHub.
In this tool environment, the team quickly discovered that many things once considered “expensive” suddenly became inexpensive.
Writing code is no longer difficult. Creating a PR is almost costless. Refactoring, adding tests, and writing documentation can also be completed in a very short time. Many tasks that once required engineers to spend significant time can now be completed quickly with clear instructions.
At the same time, however, new problems began to emerge, and they became increasingly prominent.
The team began to face questions such as: Should this code actually be accepted? Will these changes introduce hidden risks? Is a certain implementation reasonable from a long-term architectural perspective? Will a particular change affect user experience, or even touch security boundaries?
In her talk, Fiona Fun mentioned an important sentence: “What served you before may not serve you any longer.” The sentence sounds simple, but it describes a structural change. The bottleneck of engineering organizations has moved from “how to write code” to “how to judge code.”
Shifting Verification Left: How They Responded to This Change
In response to this change, the Claude Code team did not simply ask AI to write more code. Instead, they made a more critical adjustment: they began actively reducing upfront design processes while investing more energy into building a stronger verification system.
In their workflow, verification is no longer the final gate. It is moved earlier into the entire development process.
First, automated testing became the most fundamental layer of assurance. While generating code, AI also adds unit tests, covers edge cases, updates existing test cases, and explains test coverage in the PR. The team gradually became less dependent on human review to catch most issues. Instead, the test system filters out obvious problems first.
Next, at the PR level, Claude Code automatically analyzes changes. It summarizes what has been modified, identifies potential risks, analyzes the impact scope, and proposes improvements. As a result, the way code review works has also changed. Engineers no longer need to read every line of code manually. Instead, they make judgments based on the analysis provided by AI.
At the same time, the team strengthened continuous integration and regression detection. They invested more effort in CI automation, regression test coverage, change impact analysis, and fast rollback mechanisms. The operating logic of the entire system became clearer: code can be generated quickly, but it must also be verified, rejected, and fixed just as quickly.
Making Decisions with Code, Not Meetings: A More Direct Approach
In technical decision-making, the Claude Code team has gradually developed a new habit.
In the past, when teams disagreed on architecture or implementation approaches, they often relied on meetings, documents, and discussions to reach consensus. Now, they are more inclined to generate multiple options directly and let the code itself participate in the decision-making process.
More specifically, when a disagreement arises, the team uses Claude Code to quickly generate multiple implementation options, with each option becoming an independent PR. These options are then tested in the real codebase and compared across multiple dimensions, such as code complexity, impact scope, test results, performance, and maintainability.
The final decision no longer depends on whose argument sounds more persuasive. It is based on how those options perform in real execution.
This approach makes decision-making more direct and more efficient. Arguments are reduced, cycles are shortened, and many questions can be answered quickly simply by “running the code.”
Of course, the team is also very clear about the boundary of this method. AI can help generate options, but it cannot replace architectural judgment. The final decision still needs to be made by people who truly understand the system.
Roles Are Becoming Fluid, but Responsibilities Are Becoming Clearer
With the introduction of Claude Code, role boundaries inside the team have become more flexible.
Product managers can directly generate functional prototypes. Designers can modify front-end implementations. Engineers can generate product copy or documentation. Even some non-traditional developers can submit PRs. These changes are not occasional events. They are gradually becoming part of daily work.
Interestingly, while capabilities are spreading more widely, the team has become even more serious about the division of responsibility.
All production code must still go through engineering verification. Architectural consistency remains the responsibility of core engineers. Security and performance are reviewed by dedicated roles. The final judgment on product experience still belongs to design and product leaders.
In other words, the team allows more people to participate in building, but it does not blur accountability. Capabilities can flow across roles, but responsibilities must remain clear.
Fewer Processes, Stronger Governance
The Claude Code team is also continuously doing one important thing: reviewing existing processes and actively removing the parts that have lost their value.
They found that many legacy processes existed to compensate for information asymmetry or high execution costs. But when AI can automatically generate context, organize information, and execute repetitive tasks, many of those processes are no longer necessary.
As a result, they began using Routines and Agents to replace large amounts of manual work. For example, AI can automatically summarize customer feedback every day, organize and classify issues, generate development progress reports, and update documentation. Tasks that previously required human effort can now be executed continuously and reliably by AI.
At the same time, the team has reduced low-value meetings, lengthy documents, and repetitive reporting. In the new way of working, the PR itself becomes the most important information carrier, while code and tests become the most reliable source of facts.
However, reducing processes does not mean weakening governance. On the contrary, the team has invested more effort in automated test coverage, permission control, log auditing, and risk classification. Their principle is clear: reduce human procedures, increase system constraints.
The Team Capability Structure Is Changing
As these changes accumulate, the team has also developed a new understanding of what kinds of engineers matter more.
They are beginning to value two types of people more highly.
The first type is engineers with strong product sense, often described as creative builders. These people can quickly build prototypes, understand user needs, collaborate effectively with AI, and move things forward even when information is incomplete.
The second type is deep systems experts. They are responsible for architecture design, performance optimization, distributed systems, security, reliability, and other critical domains.
Meanwhile, many middle-layer tasks, such as boilerplate code, simple logic, and repetitive refactoring, are being significantly replaced or augmented by AI.
This change is not a theoretical prediction. It is a capability structure adjustment that naturally emerged after the team used Claude Code extensively over time.
How They Measure the Value of AI Coding
Against this backdrop, the Claude Code team does not focus on “how much code AI has written.” Instead, they care more about indicators that are closer to actual outcomes.
They observe how long it takes a newcomer to complete their first effective PR, whether the time from PR creation to merge has shortened, whether defect rates and rollback rates have decreased, whether test coverage has improved, and whether customer issues are fixed faster.
They also pay attention to whether cross-functional team members can build prototypes more quickly, and whether core systems remain stable.
These metrics may not look as flashy, but they more accurately reflect changes in organizational efficiency and product quality.
AI Coding Is, in Essence, an Organizational Restructuring
From the Claude Code team’s practice, we can see a clear trend: AI coding is not simply a tool upgrade. It is reshaping the entire software production system.
In the past, software output depended more on human labor, coding ability, and process management. Now, a new production logic is taking shape: problem definition, context quality, AI execution capability, verification systems, and organizational judgment together determine the final quality of software.
In this process, code is becoming easier and easier to obtain, while judgment is becoming increasingly important. Verification has become a core function, and the division of responsibility has become even more critical.
The value of Claude Code does not lie only in how much code it can write. Its deeper value lies in forcing teams to rethink what kind of code deserves to exist and what kind of decision is truly correct.
This may be the most important capability in the age of AI coding: not writing code, but making the right judgment.