From Cost Advantage to a Question of Control

The fact that software can be produced more cheaply and quickly with coding agents than by human manual work is the premise of this series (see the opening part) and a simple law of the market: a cheaper production process prevails, provided that quality and reliability are right. The real question is therefore not whether AI can generate code, but how one lets it generate the code without losing control over the result.

How Do You Hand Over Control of the Code?

When humans no longer write and read program code line by line, it must be ensured in some other way that the generated program does what it is supposed to do – reliably, verifiably, and traceably. But on what does one anchor correctness, if no longer on the source text one has read? What must be fulfilled so that one can trust the generated code without fully reconstructing it?

In classical development, the source code is the central artifact. It is written, read, discussed, improved, tested, and secured through reviews. Even if no one understands every line perfectly, the code remains the basis for actual control. Anyone who wants to know something looks in the code.

With agentic development, this model no longer functions. The agent generates code at a speed and in a quantity that can no longer be sensibly controlled by complete human reading. The attempt to continue treating every piece of generated code the way handwritten code is treated deprives the process of precisely the economic advantage that it is supposed to bring.

Anyone who wants to make use of the cost reduction must therefore be able to hand over control – but not in an uncontrolled way. How can an organization have code generated by an agent, without checking it manually in full, and nevertheless ensure that it fulfills the agreed function? That is the first survival question.

How Do You Keep Control of the Function?

Whoever hands over control of the code must not lose control of the function. Requirements, design, and decisions must be available in a form that an agent can reliably translate into code, and that at the same time remains the binding source for humans. It is not enough to describe a goal to the agent in natural language and hope that it generates the right system from this. There must be a place where intent, boundaries, and assurances are documented and reviewed.

Otherwise a new risk arises: the code is there quickly, but the intent is forgotten. A function works in the demo case, but no one knows precisely which assumptions the agent has made. A test checks the obvious, but not the domain-critical edge case. An architectural decision sits somewhere in the generated code, but not where it can be reviewed, discussed, and further developed. Software has then indeed come into being, but its development is not manageable.

That is the tension: handing over control of the code means letting go; keeping it over the function means holding on. A methodology for development with the help of AI has to deliver both at the same time.

The Answer: Review the Specification, Not the Code

The tension between the two questions cannot be resolved through more skillful instructions to the AI. Better prompts can improve individual results, but they do not replace a development organization, checkpoints, responsibilities, or a traceable chain from domain intent to generated code. If agentic development is to be used economically, it needs a methodology.

This methodology has to deliver three things. First, it must give the agent enough structure to build reliable software. Second, it must give humans a place where they can review requirements, design, and decisions. Third, it must establish a connection between what is wanted in domain terms and what emerges technically.

That is exactly the core of AIND, PROSTEP’s AI-native development methodology. AIND shifts the checkpoint from the generated code to the specification. Humans describe and review need, requirements, design, and assurances; the agent generates code and tests from these. In this way, the code is not trusted blindly; rather, the chain from which it emerges is made controllable.

At first this sounds like a displacement of the problem from hard-to-review code to a hard-to-review specification. But the difference is decisive. A good specification is significantly smaller than the code it generates. It is formulated at the level of domain intent, not in technical details. And it remains stable while the code changes.

The AIND Chain: Need, Requirement, Assurance, Code

AIND does this via a chain in which every link has its own purpose:

Need → Requirement → Assurance → Code.

The need is the domain intent: what should the system deliver, and for whom? The requirement turns this into a verifiable statement. The assurance is the technical commitment that the code must fulfill – precise enough that its fulfillment can be established. The code is what the agent generates from this. The assurance is thus the bridge between domain requirement and technical behavior.

Along this chain, the work is redistributed: humans specify what is to hold and design the structure, while the agent implements. In this way, humans leave the level of the code; they work at the level of intent and check whether the assurance is correct and fulfills the requirement.

What Tools Check and What Humans Check

The advantage of this approach lies in the fact that the transitions between these four phases are in each case checked by whoever is best able to judge them.

The first check applies between assurance and code. Tools read out the actual code: classes, methods, signatures, dependencies. They do not guess whether the code matches the assurance; they check factually what is present in the code. Structural deviations stand out unambiguously. Where an assurance describes behavior, AI checks precisely that spot against the commitment. The result is not a mathematical proof of correctness, but a repeatable deviation report.

The second check applies one level higher: do the assurances really cover what was required in domain terms? It follows the same principle as the comparison between assurance and code, only at the level between requirement and assurance.

This makes the division of labor clear:

• Humans check intent, requirements, and assurances – that is, the level at which judgment counts.
• Tools check structure and reveal deviations between assurance and code.
• AI checks in a targeted way those behavioral questions that cannot be decided on purely structural grounds.
• The agent generates the code.

The real value lies in the fact that this reconciliation is based on real code facts, is repeatable, and is cheap enough to run alongside continuously. Deviations show up here, not first at the customer.

Getting Faster Without Getting Uncontrollably Faster

Numbers of factor 5, 10, sometimes more are circulating about the speed advantage of AI-supported programming. The robust empirical evidence is more sober: controlled studies of general programming work show significantly lower benefit effects, and in certain mature code bases even negative effects: the developers felt faster but were not.¹ The context is decisive: in large, mature code bases the effect is initially small, whereas in greenfield new development, high factors are realistic. For many unspecific scenarios the lever tends to lie at two to three times what is economically relevant, but no blanket factor of 10.

What is decisive, however, is not the leverage factor itself, but how it comes about – and why the measured disadvantage in mature code bases is not a counterargument. The study measures a narrowly defined case: experienced developers who already knew their own, mature code precisely. Over the lifespan of a project, that is the exception, not the rule. Teams change, modules age, and hardly anyone knows unfamiliar code, or code that has not been touched for a long time, by heart. Exactly how the developers used the AI in detail is not fully recorded by the study. But it does name precisely the type of use as one of the causes of the slowdown: prompts that were too simple and low familiarity with the tool. That is exactly where one of AIND’s strengths lies.

Instead of simply prompting a task into a session, with AIND one first works out a map of the code – with components, assurances, stored descriptions – and thereby steers the context of each coding session precisely. The agent does not search the code base afresh each time with varying results but works its way in a targeted manner to the relevant section. This saves work on the wrong section and thus correction loops. Once the map is there, work on existing code also proceeds significantly faster as soon as it is worked on a second time. The real lever, however, lies in the fact that this state of knowledge is not held in the head of an individual person, but is persistently externalized and is thereby made available to the whole team: every further session benefits from it. AIND is therefore not faster because AI produces code faster, but because a controlled, reusable context ensures that it more rarely produces the wrong thing.

Control Shifts, But It Does Not Disappear

So, control does not disappear; in future it lies in formulating intent, requirement, and assurance cleanly, and in reconciling the generated code against these in a repeatable manner. You hand over control of the code by keeping control of the specification.

This answers the question of control, but the next question is obvious: how do you write a specification from which an agent reliably generates code, and which at the same time captures the why of a system? That is the subject of the next part in this chapter.

¹ Cf. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025). The study found, among experienced developers in mature, familiar code bases, a slowdown despite a perceived acceleration. However, the authors expressly delimit the finding: for small or newly emerging greenfield projects, they consider substantial accelerations compatible with their data. As causes of the slowdown, the authors also cite immature use of the tool – for example, prompts that were too simple – and low familiarity with the AI tool.