When AI Writes Code Faster, Where Does the Bottleneck Go?

A conversation about AI and software engineering opened with a demo. The code was generated by AI, and every test turned green. At first glance, the coding stage—the part that used to consume the most time—had been dramatically compressed. But the two guests in the conversation quickly brought the discussion back to reality. Green tests only mean that the code matches the tests. They do not prove that the tests are right, and they certainly do not prove that the result is what the customer actually needs.

Once writing code is no longer the main bottleneck, where does the center of gravity in engineering move? That was the real question behind the conversation.

Faster Code Does Not Remove the Bottleneck; It Moves It Upstream and Downstream

Yagami's experience was direct. His team had set up an AI-driven development environment and was already using AI to develop part of its production code. The time required for coding was indeed falling. But the time saved did not make delivery easier as a whole. Instead, it made the pressure on both sides of coding more visible.

Upstream is the question of what to build. What is the customer's real problem? Which requirements must be met, and which are only surface-level requests? How should exceptions be handled? If these judgments remain vague, AI will simply generate the wrong answer faster. Downstream is verification and operations. Does the generated behavior conform to business rules? Who makes the call when something goes wrong? How will the system be maintained once it is in production? The faster coding becomes, the more conspicuous the debt at both ends grows.

In the conversation, Yagami pointed to "articulation"—putting things into words—as the hardest part. Finance and other industries run large numbers of legacy systems that have been in service for a decade or even several decades. Many rules exist only in specific operating procedures and in people's experience; they were never fully written down. Even a company founded about eight years ago still has many processes that have never been clearly expressed. Articulation here does not mean making old documents look tidier. It means turning the judgments, exceptions, and responsibilities behind the phrase "this is how we've always done it, but nobody can explain why" into definitions that can be discussed, tested, and eventually handed over to a system.

AI cannot do this work for us. It can read documents and generate code, but it cannot automatically know about a business exception that has never been recorded. Someone has to ask questions, observe the work, and break vague descriptions into concrete conditions. Requirements definition has become central to engineering again—not because the tools have become less capable, but because they magnify the cost of not thinking things through.

The Engineer's New Position Sits Between the Customer, the Business, and the Code

The conversation included a very practical observation. In the past, engineers grew largely by watching their seniors. Newcomers stood beside experienced engineers and gradually learned judgment through daily work and the way projects were pushed forward. But engineers building AI agents today often have no fully matching role model. The tools, the way of working, and the thing being delivered are all changing, while the experience that should be passed down has not yet taken a stable form.

That does not mean technical foundations no longer matter. On the contrary, the conversation suggested that people with solid technical foundations find it easier to move into new territory. What is genuinely scarce is someone who understands system design, has done large-scale implementation and production rollout, and can also face customers directly. Writing code to a given specification is not enough, and talking only in concepts will not put a real system into production.

The new way of working looks more like a chain. First, talk continuously with customers or business teams to understand what they really want to change. Then structure the vague request and identify the missing information. Finally, use AI to build something verifiable quickly, filling in the gaps along the way. The conversation connected this role to the FDE, or Forward Deployed Engineer. Such a person is neither a pure programmer nor a consultant who only conducts interviews, but someone who can move back and forth between the business front line and engineering implementation.

That is also why developing these engineers is so difficult. This kind of capability is hard to teach in a single course. It grows through real projects: breaking a problem apart with the business side, building a solution, and then taking responsibility for the result. The conversation noted that keeping engineers close to the people who know the customer best, in continuous dialogue, matters more than practicing prompts in isolation.

Passing Tests Does Not Mean the Product Is Right

The easiest thing to overlook in the demo is the sense of safety that "green" creates. Passing tests are important, of course, but they prove only one thing: the code meets the expectations defined by the current tests. If the tests miss a critical scenario, or if the requirements were misunderstood from the start, then all green can create a false sense of completion.

What AI generates is not abstract code but behavior that will actually run. Whether that behavior is right ultimately depends on whether it solves a business problem, whether it remains controllable under abnormal conditions, and whether someone is accountable for the result. Tools such as Codex make generation cheap, and in doing so they make judgment expensive. The conversation described a phenomenon in which the same set of tools produces increasingly divergent quality depending on who uses them: some people keep narrowing the problem, while others keep generating plausible-looking output that drifts away from the goal.

Technical judgment has therefore not been replaced by automation. It has been pushed further forward: deciding what AI should do, what context to give it, how to verify the result, and when to stop and bring a human in. Coding speed sets the floor; judgment determines the ceiling.

Where AI Belongs: Start with the Points That Must Remain Human

The second theme was more specific. Which parts of an organization should AI enter, and which parts should it be explicitly kept out of?

Using financial operations as an example, Yagami described an approach based not on job titles but on the nature of the decision. Any process that has clear rules, can be checked mechanically, and does not require inference should be systematized as far as possible. The points where people must make value judgments, handle exceptions, and bear responsibility should be identified thoroughly and explicitly kept in human hands. In the past, business design often systematized a human process as a whole. Now the parts suited to inference and generation can be handed to AI, while human judgment remains at the critical points.

That boundary cannot be drawn with a single line on an architecture diagram. It has to be worked out in concrete operations: which instructions may be executed automatically, which require a second confirmation, which exceptions must be escalated, and who is responsible when something goes wrong. The banking examples mentioned in the conversation—instructions involving the movement of funds, account freezes, or forced debits—are sensitive precisely because they are not merely "information processing." They involve authority, accountability, and irreversible consequences. The more sensitive the step, the less acceptable it is to put it into a production workflow simply because AI can generate a plausible-looking operation.

Watanabe added another often-underestimated prerequisite: security and governance. When SoftBank promotes AI use inside its own company, it handles important data and personal information, and the telecommunications industry has very strict information-management requirements. Under these conditions, whether a tool can be used is not only a question of effectiveness. It also includes how data is processed, how permissions are controlled, and how problems are traced. Many companies do not lack awareness that AI is useful. They have not yet built the ability to make it both usable and governable at the same time.

The First Step Is Not Choosing a Model; It Is Preparing Responsibility and Conditions

At the end, the moderator asked: if you had to start tomorrow, what would be the first step?

Both guests pointed to the organization rather than the tool. Every company's situation is different, but several things cannot be avoided. The first is a clear stance from management. If AI transformation remains a spontaneous experiment inside one team, it will be hard to cross departmental boundaries. Someone needs to drive it at the company level, and someone needs to be accountable for the result. The second is preparation of data and technical conditions. If data is not organized and the boundaries of permissions and security are not clear, even a powerful tool will stop at the demo stage. The third is to have people on the front line start automating small, everyday problems close at hand rather than trying to rebuild the core system from day one.

This also speaks to the concern the moderator raised about young people entering the field. There is no need to wait until you are "ready" before starting. Automating one repetitive, tedious, clearly bounded process inside a company is a perfectly good start. Such a project lets a person understand the business, the data, and the system at the same time, and shows where AI helps and where it fails. The conversation also suggested that young people need not focus only on internet applications such as media and advertising; critical systems that support society and protect lives also need people willing to enter them. Capability is not acquired in full before stepping onto the field; it grows through a series of small results.

The conversation did not offer an answer that can be copied wholesale. It offered three questions that have to be answered continuously: where the engineering work has actually moved, who decides what to build, and where the boundary between AI and people should be drawn. Faster code does not automatically make an organization faster. What ultimately determines the outcome is whether the organization has thought through "what to do" and "who is responsible."

Speed Is Not the Destination

If there is one takeaway, it is this: AI has made coding faster, but it has pushed "defining the problem" and "judging the result" further forward. Passing tests and a smooth demo do not mean value has already been created. For engineers, the new competitive advantage is not only writing code. It is entering the business front line, putting into words what has never been said clearly, and protecting the parts that should not be handed to AI.

That is why, in an era when AI can generate so quickly, we need people who are accountable for "what to do, why, and to what extent." Tools will keep getting faster, but boundaries do not appear on their own. They have to be discussed, designed, and owned by specific people.