The rapid rise of large language models has led many business leaders to assume that software development should now be dramatically cheaper. The reasoning appears straightforward. If artificial intelligence can generate code, then a large portion of the work traditionally performed by developers should disappear.
In practice this expectation has not materialised. LLMs have improved certain parts of the development process, but the overall cost of building custom software has not significantly declined. The reason is that writing code has never been the primary cost of building software systems.
Understanding this requires looking more closely at what software development actually involves.
What Software Development Really Consists Of
When people outside engineering think about development, they often imagine programmers writing code for long hours. From this perspective, if code can be generated automatically, most of the work should vanish.
Real software projects follow a very different path.
Development typically begins with an unclear business problem. The initial task is to understand what the organisation is trying to achieve and translate that objective into a system that can operate reliably in the real world.
Engineers must analyse the problem, clarify requirements, and design a structure that can support the product over time. They determine how the system will be divided into components, how those components interact, how data moves through the system, and how the system will handle future changes.
They also evaluate constraints such as infrastructure limitations, integration with existing systems, performance requirements, and security considerations.
Only after these decisions have been made does the code itself appear. In this sense, code is not the primary work of development. It is the written form of a decision that has already been taken.
What LLMs Actually Accelerate
Large language models are extremely effective at generating code when the problem has already been clearly defined. If the behaviour of a function is known and the constraints are understood, a model can generate working code within seconds.
This makes LLMs powerful accelerators of implementation.
However implementation is usually the shortest phase in the entire development lifecycle. The majority of engineering effort lies in deciding how the system should behave and how its parts will interact over time.
LLMs do not perform this work.
They do not determine the architecture of a system. They do not understand the unique context of a particular business. They do not evaluate long-term consequences of design decisions or the operational implications of integrating multiple services.
An LLM can suggest code, but it cannot take responsibility for the system that code becomes part of.
The Developer’s Role Has Shifted
The emergence of LLM tools has not eliminated the developer’s role, but it has changed its focus.
Developers increasingly spend less time typing code manually and more time directing the process of generating solutions. Their work now involves framing problems for the model, providing relevant system context, defining constraints and evaluating the outputs that the model produces.
Every response generated by an LLM depends heavily on the quality of the prompt and the context provided. In other words, LLMs answer questions, but the quality of the system depends on the quality of the questions.
When experienced engineers guide the model, it becomes a highly effective productivity tool. When the problem is poorly framed or critical context is missing, the model may produce code that looks correct but introduces architectural weaknesses.
In such situations increased speed can become a risk rather than an advantage. Mistakes propagate through the system faster than before.
Changes in the Developer Workforce
Another factor shaping the impact of LLMs is the changing composition of the developer workforce.
Over the past decade the software industry has expanded rapidly. Many new developers have entered the profession through bootcamps, short courses and accelerated training programmes. As a result, the average level of experience across the industry has declined.
LLMs partially compensate for this shift.
They help less experienced developers produce code faster and avoid simple mistakes. Models can suggest common implementation patterns, generate boilerplate structures and assist with routine tasks that previously required more experience.
This assistance allows teams with mixed levels of expertise to maintain reasonable productivity and acceptable code quality.
However this effect should not be mistaken for a productivity revolution. It is better understood as a stabilising force. Declining average experience in the workforce is partially offset by additional support from LLM tools.
The result is modest improvements in speed and consistency rather than a dramatic reduction in development costs.
Experience Still Matters
There remains a fundamental difference between an experienced engineer using LLM tools and someone who simply operates those tools.
Experienced engineers understand system architecture and anticipate how technical decisions affect the long-term evolution of a system. They recognise hidden dependencies, integration risks and the maintenance implications of design choices.
When such engineers use LLMs, the models accelerate execution.
A person without engineering experience can also generate large volumes of code using LLMs, but cannot design systems that remain stable and maintainable as they evolve.
LLMs amplify expertise. They do not create it.
Why the Economics of Development Remain the Same
For these reasons the economic structure of software development has changed far less than many expected.
LLMs reduce the cost of producing code, but the cost of building software is determined primarily by the cost of making correct engineering decisions.
Modern software systems continue to grow in complexity. They integrate with numerous external services, operate in distributed environments and must meet demanding requirements for reliability, security and scalability.
The difficult part of building such systems is not writing individual functions. The difficult part is designing systems that behave predictably when many components interact under real-world conditions.
This is what organisations pay for when they commission custom software.
They are not paying for lines of code. They are paying for the capability of an engineering team to transform a complex business problem into a reliable and maintainable system.
LLMs accelerate implementation. The responsibility for decisions remains human.
