So far, agents have above all changed the collaboration around the methodology, as the previous part in this chapter has shown. But that is only the current stage: agents are still tools at the edge of the methodology. In the next step, the methodology itself becomes agentic.
The Methodology Itself Becomes Agentic
Today, AIND accelerates development via a coding agent such as Claude Code, which runs as a command-line tool. That works well, but the agent remains a powerful tool that cannot be fully integrated into the methodology. The next stage is genuine agent integration into the AIND tools. Only through this does it become possible to seamlessly integrate AI functions into the AIND user interface and to scale AI support – from the simple review of a specification snippet by a prompt, through the verification of a module by an integrated agent, all the way to the complete implementation of a feature by an external agent such as Claude Code or GitHub Copilot. The technology of the PROSTEP AI Workbench, which, as described in chapter 2 of this series, executes AI processes in products. It becomes the primary AI tool of the development methodology. Agent types are described in APL, the same language in which productive AI processes are also described and are executed directly by the runtime.
Specialized Agents Instead of a General-Purpose Agent
What do we gain if we replace the command-line agent with an integrated agent that is fully controllable by the methodology? The advantage lies not in simply having more activities carried out by AI, but in specialization and limitation. Instead of a general-purpose agent that can do everything a little, specialized and self-learning agent types emerge – for example a gap analyst, a code checker, a requirements analyst, or an implementation agent. Each agent gets exactly the tools, data, and contexts that fit its task.
Specialization arises not through different tools alone. Each agent type also gets its own internal work instruction: which role it takes on, what it should pay particular attention to, which terms and artifacts are relevant for it, when it must abort or ask back, and how its results should look. A checking agent works with different priorities than an implementation agent; a requirements agent evaluates different signals than a code checker.
These internal work instructions are not incidental, but part of the methodology. Together with dedicated tool sets, context selection, and model choice, they determine how specialized and efficient an agent works.
In other words: a specialized agent is not simply the same language model with a different tool list.
The sharper the role, the better context can be limited, behavior checked, and model choice adjusted. The benefit therefore lies not in greater autonomy, but in more sharply cut, limited agent roles.
The Right Model for the Right Task
With specialized agent types, model choice also becomes more differentiated: an analysis agent can use a different language model than a code checker, all the way to the choice between a local and a cloud model depending on the data protection and security situation, as the second chapter describes in detail. The choice of model thus becomes a conscious decision of the methodology.
The classical command-line tool does not immediately disappear in the process. It remains useful for particularly complex programming tasks or as a fallback option, but it is no longer the sole carrier of the methodology.
The Movement Continues Further Away from the Code
AIND, too, has a limited half-life. Today’s approach still works close to the code: humans specify, the agent builds, humans check specification and deviations. This closeness is necessary today, but will not be so forever. In future, agents will autonomously generate larger parts of custom software, and humans will steer more strongly at the level of need, intent, and domain-level decision.
In concrete terms, that means: today we check assurances against code. Tomorrow we may check more strongly whether a generated system fulfills the domain need, the process boundaries, and the organizational decisions. The principle of AIND remains the same; it simply takes effect one abstraction level higher.
Standard software does not disappear as a result, but its role shifts from the finished application system to a toolkit from which integrated agents derive process-close solutions. Value arises where stable platforms, standardized interfaces, and individually generated process support come together.
Anyone Who Gets On Board Today Is on the Right Path
PROSTEP is actively shaping this movement. We continue to develop our own methodology with the same means with which we build our software. Anyone who takes a methodology for AI-supported development seriously must, in our view, apply it themselves.
For us, this is not an aspiration but lived practice: the tools of AIND are themselves built with AIND. At the core, two developers – with occasional support from five others – built a complete working environment for AI-supported coding, with several tens of thousands of lines of code and around 500 commits, in a good four months. Two people, a production-ready working environment in four months: in our own development, the time gain is clearly noticeable. That is exactly the greenfield effect for which the aforementioned study also concedes high factors.
Anyone who gets on board with AI-based software development today cannot yet know where we will arrive in a few years. What is foreseeable is the direction, not the pace and not the end point. Precisely for this reason, AIND is not a finished target picture, but a transitional model: it brings control to working with coding agents today and grows along with them when the methodology itself becomes agentic. That is the answer to the question raised at the beginning of this part: yes, the approach will hold up in the future as well, precisely because it does not claim to be the end point.
