A Turning Point, Not a Trend

Anyone who needs software needs people who can write code. That has been true for decades. It was the slowest and most expensive part of the process chain, and mostly short on human resources, which is why many projects reached their limits. Customizations were postponed, integrations simplified, and individual solutions avoided because the effort was out of proportion to the benefit. This limit is now shifting.

A language model controlled by an agent can produce program code faster than a human can write it, provided the agent is guided correctly. This is not a gradual increase in efficiency but a fundamental change in the situation: who builds the software, how quickly it comes into being, and who can afford it depends on other parameters. Projects that used to take months can now be completed in a matter of days. Software that was too expensive to tailor becomes economically viable.

What does this have to do with PLM? A great deal. PLM is basically engineering methodology cast in software. It reflects how companies structure products, track requirements, control changes, exchange data, and organize collaboration. When the process of building software shifts, so does the space of what’s possible in PLM.

Systems can be designed more strongly according to one’s own processes, rather than being adapted over the course of years. Integrations no longer have to be spelled out by hand at every point. Connections that today lie hidden in separate data stocks can be systematically opened up. And functions that were previously too specialized, too expensive, or too laborious suddenly move into the realm of the feasible.

The Questions That Now Count

As soon as humans no longer write the code, the actual problems shift. The central question is then no longer how do we write the software faster, but how do we keep control over what emerges? From this arise several questions that will shape software development in the coming years:

• How do you keep control over the result when you no longer read the code line by line?
• What must be described so precisely that an agent can reliably build software from it?
• Where should AI decide, and where does it do more harm than good?
• What becomes economically possible when custom software is no longer automatically expensive and slow to develop?
• What becomes of development teams, processes, and tools when a large part of the implementation shifts to AI?

This series addresses these questions one by one, with concepts, concrete examples, and open points. Much of this – specification instead of code, a deterministic backbone, targeted AI – is currently being widely discussed. The difference here is that at PROSTEP it is not a thesis but something built and in use: from these ideas, a methodology, a compiled process language including runtime, and running products have emerged, and we develop our own software with these every day.

A Series That Answers Three Questions

How is software built? Anyone who simply lets an AI start programming away quickly gets code and just as quickly loses certainty about whether this code does the right thing. The answer lies in a shift of the checkpoint: no longer is every line of code at the center, but rather the specification. The first chapter shows how to keep control without losing speed by building an end-to-end chain of need, requirements, assurances, and code. In this way, AI-supported custom development becomes not only fast but also methodically manageable.

How does AI become fit for industrial use? The widespread disillusionment with AI is justified. It is not due to AI itself, but to the fact that it is being systematically deployed in the wrong places. For many things, solid classical programming is superior to AI, because it works reliably and reproducibly. The second chapter shows how to deploy AI precisely where it delivers its real added value, namely embedded in controllable processes, with a deterministic backbone, and with agents that collaborate directly within the applications rather than producing results in a separate chat window.

Where does this lead? The third chapter shows the concrete consequences that follow from this – from the traceability of technical relationships through the analysis of contracts, documents, and requirements specifications to the question of how such capabilities feed into PLM products and customer solutions. This is not about demonstrators as an ends in themselves, but about a pattern that involves the same methodology, the same process logic, and the same agent architecture across different use cases.

A Methodology That Continues to Evolve

The methods described here are not an end point. They are an early, necessary step in a direction that is already emerging: the steering of software development is shifting upward.

Today, it is about no longer writing code oneself, but formulating specifications, requirements, and assurances so precisely that an agent can reliably build software from them. The next step is already visible: agents largely design custom software themselves, generate user interfaces for specific use cases, derive building blocks from existing patterns, and only adapt them where it is technically necessary.

This also changes the role of PLM systems. Companies will spend less time adapting standard software to their processes over the course of years. They will instead have more software generated in line with their processes, with standardized interfaces where interchangeability matters, and individual expression where their own development process makes the difference.

What one starts with today and where it all leads is the subject of this series. The next article begins with the first question:

How do you keep control when the AI writes the code?