The Dream of Software Without Developers

The rapid advancement of artificial intelligence is transforming many areas of the working world. In software development in particular, there is intense debate about the future role of AI-powered development tools. Systems that are now capable of generating code, orchestrating development tools and producing functional prototypes have created a new expectation in many organisations: the dream of software that could be built largely without developers.

At first glance, this dream seems plausible. New tools deliver impressive results in a short time. Features can be generated, small applications emerge within minutes, and many technical tasks can be significantly accelerated. Anyone who sees these initial results can easily conclude that software development itself might become a largely automatable process.

This notion, however, is often based on a misunderstanding of what the actual work of software development consists of. The most visible part of that work is writing code. But the greater part lies elsewhere: in understanding problems, structuring requirements and designing stable technical systems.

The Translation Process

Software always emerges as a response to a domain problem. Organisations want to automate processes, structure information or develop new digital services. The implementation of these goals, however, takes place in technical structures. Between the description of a domain problem and its technical implementation lies a complex translation process. Requirements must be interpreted, abstracted and transformed into a viable system architecture.

It is precisely in this transition between domain knowledge and technology that a large part of the real development work takes place. Modern AI systems can generate code or extend existing programs. What they largely lack, however, is a deep understanding of the domain in which software is created and of the long-term consequences of architectural decisions. Questions of system structure, maintainability or the integration of different systems cannot be solved through code generation alone.

The Prototype That Fails in Production

A typical example of this dynamic can be observed in many organisations today. With the help of modern AI tools, impressive prototypes can be created in a short time. A small internal tool emerges within a few hours: a web interface, some automatically generated data models and a connection to an external API. For an initial demonstration, the system works surprisingly well. The application processes requests, handles data and looks at first glance like a finished product.

The difficulties, however, often begin at the very moment such a prototype is to be moved into a production environment. Questions of data consistency, scalability, fault tolerance or security requirements suddenly come to the fore. The architecture that suffices for a quick prototype often proves inadequate under real-world conditions.

Another phenomenon emerges when working with AI-powered development tools themselves. In many cases, the AI produces solutions that appear plausible at first glance but reveal structural problems on closer inspection. Data models do not match actual requirements, interfaces are used inconsistently or central architectural decisions appear contradictory. Such proposals are often an indication that the underlying problem was not properly understood in the model or in the context of the request.

It is precisely at this point that the importance of experience becomes clear. Evaluating such solutions requires an understanding of system architecture, data structures and the interactions between different components. Without this knowledge, it is difficult to recognise whether a generated approach is genuinely viable or merely a seemingly functional but structurally problematic solution.

No Silver Bullet

This observation is not new in the history of software development. As early as 1986, Fred Brooks argued in his essay No Silver Bullet that technological advances can reduce individual difficulties in software development but cannot eliminate the fundamental complexity of the problems themselves. Brooks distinguished between accidental complexity – difficulties arising from tools or technologies – and essential complexity. The latter arises from the problem itself and cannot simply be eliminated through better tools.

Many advances of recent decades – higher-level programming languages, frameworks, platforms and development tools – have primarily reduced accidental complexity. The actual core of software development, however, has remained: understanding complex systems and designing viable technical structures.

The use of artificial intelligence follows this pattern in many respects. While AI can produce code faster and take over many routine tasks, the fundamental difficulty of software development does not disappear. It simply shifts more strongly towards system understanding and architecture.

An Engineering Discipline

In parallel, software development has evolved over many decades into an independent engineering discipline. To make the growing complexity of large systems manageable, a wide range of methods and mental models have emerged: architecture and design patterns, integration and platform patterns, and development approaches such as Test Driven Development, Domain Driven Design and Behaviour Driven Development.

All of these approaches ultimately pursue a common goal: to structure complex technical systems so that they can be understood, evolved and operated over the long term. They are the result of decades of experience with the limits of technical systems and the risks of growing complexity.

This is precisely why these principles do not lose their importance in the context of artificial intelligence – quite the opposite. When tools become increasingly capable of generating code automatically, the need to place that code within stable structures and understand its impact on the overall system only grows.

Code as Artefact

The dream of software without developers is therefore based less on the actual nature of software development than on a misinterpretation of what becomes visible in the early stages of development. Artificial intelligence primarily accelerates a part of the work that was long regarded as the visible core of software development: writing code.

The more this part is automated, however, the more clearly another aspect of the work comes to the fore – understanding complex problems and translating them into stable technical systems.

Code is the most visible artefact of software development – but rarely its actual problem. The greater part of the work has always lain in understanding domains, designing viable architectures and managing growing system complexity.

Properly applied, artificial intelligence therefore does not lead to the abolition of software development. Rather, it makes more visible what software development actually consists of.