AI replacing programmers?

The answer might be yes and no. This won't be uniform.

May 02, 2025

Generative AI replacing (human) programmers

Almost 3 years ago, in 2022, reports of AI chat bots eerily comparable to a conversation with a human made the rounds. Later that year ChatGPT was launched. In 2025, Large Language Models (LLMs) are claimed to pass the Turing test, a long-standing test for intelligent behavior.

LLMs have demonstrated the ability to respond to directives in human language by producing human-like text, and across various languages. This includes writing in a programming language, thus opening the debate that human programmers, an expensive resource since the birth of programming on punch cards, may become less in demand as a result. NVIDIA’s CEO has claimed that programming skills are actually becoming obsolete.

AI and LLMs can be expected to make the creation of software more efficient, and therefore fewer humans with specialized programming knowledge would be required as a result. Whether this is the case is an important question to answer for the workforce (programmers), software companies, and for education.

The Jevons paradox

A counter-argument is that increased efficiency when using a resource, for example through scientific and technological progress, or other forms of improved cost-effectiveness may result in more demand for that resource. This is called the Jevons paradox. The historical example at its origin is the demand for coal increasing after the Watt steam engine, a significantly more efficient way to use it as a source of energy for machines, was developed. The reason was the increased efficiency made steam-powered machines more cost effective in more situations, and the demand for coal increased globally as a consequence. Another example is that people travel more or for longer distances when the price of fuel is low. The paradox is present when the demand for the resource is elastic: lowering costs for a resource results in a disproportionately higher increase in demand.

The Jevons paradox is not automatically present when there is increased efficiency however. Agriculture is an example where increased productivity resulted in a well documented decline in the number of farmers. Even though the world population increased and waste became the norm where it was unthinkable a century ago, the demand for food is not elastic.

Microsoft’s CEO sees the Jevons paradox apply to AI. If AI can write code, we must examine how the paradox can apply to programming and software development. The hypothesis is that LLMs are making the creation of software more efficient by increasing the productivity of programmers. There is arguably a lot of latent demand for more software in a world with increasing electronic information, interconnectedness, ubiquitous availability of sensors, and robotics. Lowering the cost of creating software would then just increase the global demand for programmers.

Conditions

Whether that increased demand for programmers can be expected, or programming might no longer be a valuable skill to possess, is an important question for career programmers or other professionals having programming knowledge as an asset, education institutions, and kids/parents thinking about what to study.

The Wikipedia page lists 3 conditions for the Jevons paradox to manifest itself. We can start with them.

1) Technological change which increases efficiency or productivity

A general gain in productivity seems like a reasonable expectation. The extent of that gain could vary a lot, and this variation explains the divergence of opinions about AI writing code. Estimates of increased efficiency from single digit to low double digits seem reasonable for very seasoned programmers, but for more entry-level coding positions the percentage may be much higher. Assuming that AI performs at the level of an average programmer, this would be about better or equivalent to half the programmers. It could just replace entry-level programming, and thereby have a larger impact on productivity by taking over those jobs.

The technological change is AI demonstrating the ability to write in a programming language. Measuring the productivity of programmers is a thorny problem though, and Goodhart’s Law applies in most of these attempts. We can start with whatever measure is available though, and reason our way from there. A measure is through Google reporting that over 25% of its new code is written by AI. A gain in productivity is quite plausible, even if it is hard to truly quantify.

To first look at efficiency or productivity, we have to consider that programmers activities are not restricted to solely writing in a programming language. Those activities almost always involve iterations, and this leads to split activities into an inner loop and an outer loop. Activities in the “inner loop” are: write code, build, and test. McKinsey emphasizes time spent in the inner loop as an objective to increase productivity, with a target of 70% of the time. This is debated in software engineering circles however, similar to counting the number of lines of code. The time spent on the inner loop likely varies between 15% and 85% depending on the programmer’s assignment. For this exercise we simplify to 50% of a programmer’s time. AI writing code is going to improve productivity in the inner loop. If we generously extrapolate from 25% of new code that AI does to 25% of the inner loop, we end with a simplistic back-of-envelope calculation of AI taking over 12.5% of the programmer’s time.

How much the “25% of new code at Google” generalizes to the global population of programmers also remains to be determined, since Google’s hiring process is notoriously selective. Programming is more complex than the mere writing of code, or even the coding-related activities in the inner loop. A programmer needs to spend time on activities requiring the understanding of the broader context, involving human interaction, and requiring abstract thinking. The famed “10X programmers” are not so because of the number of lines of code they write compared to their peers, but because they are force multipliers (for example, multiply the productivity of 10 teammates by 2), seek to deeply understand the context to converge to the right need and shape for solutions, and communicate clearly. An important aspect of programming is organizing the code to minimize duplication, and removing portions of the code that is no longer necessary. It seems reasonable to hypothesize that less expert programmers, or their management, will be tempted to trust AI with writing more than 25% of the code. However, it is unclear whether the time saved will be redirected to other valuable activities (such as those in the outer loop), or whether more code volume produces (the productivity gain goes toward more code being generated). If the latter occurs—merely more code being written—then the quality or relevance typically achieved through outer loop activities could suffer, ultimately diminishing overall productivity. There might be no net gain, or even a loss, if AI helps generate a large volume of code that does not fully address the needs, is brittle, or contains subtle errors discovered only later, necessitating significant rework. Conversely, if the primary requirement is minimizing the time to ship a first release of software that approximates the expected functionality, then productivity focused solely on that metric could see a significant increase.

A last question to ask about the 25% of new code at Google is how much this generalizes to all software that needs to be written (outside of Google). Google has a very large existing code base along with documentation, design docs, and the evolution of that code base and code review comments. This training set is arguably unmatched and the resulting model works best with that code base. The quality of the output outside of that distribution, for example software requiring specialized knowledge or subject matter expertise, could be expected to decrease until focused models, or omniscient models, are available.

2) The efficiency/productivity boost must result in a decreased consumer price for such goods or services

A decrease in consumer price resulting from the productivity boost will vary a lot in magnitude. Software products that are more generic and require more entry-level programming will have the biggest potential for decrease in price. For individual consumers, this may allow software to be “free”, a very significant symbolic decrease in price. For businesses, general software development outsourcing companies could see the largest opportunities for lowering prices.

The effect on the consumer price requires a bit of educated guessing. Numbers vary across sources, and how the numbers were obtained is not specified, but one can gather that marketing, and business development will account for between 15% to 60% of a software company’s expenses. General and Administrative expenses represent 15% to 30%. Since this is software, we can simplify by assuming that the cost of distribution is negligible, and that we have enough information about consumer prices. Assuming that a company is at its breakeven point, software development represents 10% to 70% of the consumer price. If the company is not a software company, but creates software to support its main product (firmware, companion app), the numbers will be much lower. Making the simplification that 25% of code is written by AI translates into a matching percentage in cost savings, and those are passed to the consumer, the price would decrease by 2.5% to 17%. Double the numbers if as much as 50% of the code is written by AI.

To look at this further, we distinguish between types of customers: individual consumers and businesses.

Individual consumers already pay a relatively low price for software. Increased productivity for programmers will represent low absolute changes in price. However it is worth noting that in many instances with Software a a Service (SaaS), individual consumers “pay” for software by letting their data be used. Going from $10/month to $7/month might have a much smaller impact on the price perceived by the consumer than going from $1/month to free.

Businesses and corporations typically pay much higher costs for software but on the other hand often include higher service and support levels that reduce the relative contribution of programming to the price. For very specialized software, customization or even completely bespoke software can increase that contribution to the price. Whenever context awareness and the management of complexity is needed, both being activities humans remain better at, the productivity boost will exist but will be smaller than with general software development outsourcing companies. With the latter companies, the opportunity for lowering prices by double-digit percentages while the prices are high and the competition is fierce will be very significant.

3) That reduced price must drastically increase quantity demanded (demand curve must be highly elastic)

The Jevons paradox is most likely to manifest itself if allowing consumer software to be "free". It can also happen if development cost reductions allow a Cambrian explosion of software diversity to be economically viable. This would allow short-lived prototypes a chance to exist and find interest (funding or demonstrate a product-market fit).

With software, quantity can mean several things and most of them do not mean the same as “quantity of coal demanded”, the historical example of the Jevons paradox. Here, quantity could have three meanings.

The first one is that the number of entities (individuals) with a copy of the software or an account if SaaS. For individual consumers, price reductions that allow software to be “free” can be expected to increase the demand. Otherwise, the increased demand is less certain. For example, a video game costing $40 instead of $50 will likely not drastically increase the quantity demanded. For businesses, this could mean “seats” when individual users are counted. Like for individual consumers, a decrease in cost by 20% will not drastically increase the demand.

The second one is the number of features, or the software ability to perform more complex tasks if this also means more software written. The price remains constant but a consumer gets “more” software. Defining precisely what “more” is when this is an abstract “under 30%”, but it seems reasonable to not expect a drastically increased demand as a result.

The third and last one is the number of different software available. Here the lower price would allow a long tail of software to be economically viable and with this increase the demand of consumers for software tailored for their needs will also increase. This is the scenario where the Jevons paradox might manifest itself: a lowered cost of writing software allows the software to exist in the first place, and with this find a chance to find its users. In particular, software prototypes for which trade-offs such as reliability, maintenance, and optimality can be made would be very good candidates. The AI impact on costs would be enormous here, particularly if the scope for such software is to exist before sales & marketing become necessary to sell it. However, this means that programmers using AI to write code will have to master skills that provide context for the code (e.g., product management) or impose context for the code (e.g., architecture & design). It could also mean that product managers could learn enough about programming, design, and architecture to create such prototypes. Such prototypes could also be required from the earliest stages of fund raising for startups.

Outcome on the demand for programmers

The impact on the demand for programmers, or programming, is likely not going to be uniform. While I think that demand and productivity gain will result in a similar overall demand to the current demand, profiles with entry-level coding skills and without product management flair and subject matter expertise are likely to be in significantly less demand. This view matches the apparent opposite reactions to AI writing code that can be found on the internet. Both sides are correct because the likelihood of AI writing code will depend on the scope and seniority of the programmer currently writing that code.

Implicit programming without programmers

AI is becoming able to write that code in response to layman user instructions, or through a “dialogue” with an LLM during which immediate needs to interact with an existing software or system are specified, and this without the assistance of a programmer. The Jevons paradox would apply since the demand for code would increase as a result of productivity gains. That code would be an different type of user interface and not need to be written upfront during software development. It would be written on-the-fly by AI, and without programmers.

As we think about AI writing code, and what this means for programmers, it is worth considering the purpose of programming. Programming is translating needs identified and formulated by humans into a programming language designed (by humans) to translate into instructions for computers.

Alternatives to programming have appeared along the way though. User interfaces (UI, sometimes referred to a UI/UX) are arguably just that: they allow a user to give instructions interactively to a computer without the need to write in a programming language, but at the cost of restricting what can be asked of the computer. For example, a smartphone’s alarm clock App allowing addition of alarms with a chosen time and selected weekdays results in instructions for the computer. In almost1 all cases, what can be achieved through such interfaces is limited.

In order to provide more flexibility, hybrid interfaces also exist where snippets of code can be entered (e.g., formulas in Spreadsheet software), although always with limitations. No-code solutions are also proposing to replace the translation into a programming language with a graphical language and a drawing tool for it (that itself needs to be developed by programmers).

LLMs are human-machine interfaces, and they can respond to users describing what they need. Here is an example of implicit programming using Google’s Gemini 2.5 Pro:

> Print multiples of 3 between -5 and 100.
Okay, here are the multiples of 3 between -5 and 100:

-3, 0, 3, 6, 9, 12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45, 48, 51, 54, 57, 60, 63, 66, 69, 72, 75, 78, 81, 84, 87, 90, 93, 96, 99.

When asked to write the code perform this, Gemini will write this:

> Write python code that prints multiples of 3 between -5 and 100.

# Iterate through numbers from -5 to 100 (inclusive)
for num in range(-5, 101):
  # Check if the number is a multiple of 3
  if num % 3 == 0:
    # Print the number if it's a multiple of 3
    print(num)

A human particularly mindful about the number of iterations might argue that there is a better way to write it (see below), but Gemini’s version is fine.

i = -5
while i <= 100:
    print(i)
    i += 3

By comparison, minimal Python code for a graphical user interface would already be much longer:

import ipywidgets as widgets

def compute(b):
    if multiple.value == 0:
        return
    i = low.value + low.value // multiple.value
    while i <= high.value:
        print(i, end=', ', flush=True)
        i += multiple.value

low = widgets.IntText(value=0, description='Low')
high = widgets.IntText(value=100, description='High')
multiple = widgets.IntText(value=3, description='Multiple')
button = widgets.Button(description='Compute')
button.on_click(compute)
ui = widgets.GridBox([low, high, multiple, button])
display(ui)

A way to think about it is that programming resources are invested upfront in order to confidently allow users to customize what they want within pre-specified boundaries. Most user interfaces use common components and simple patterns, and in consequence the development can be assigned to entry-level programmers. As the demand for software grows, more user interfaces will be needed and LLMs can contribute to software development productivity by leaving a lot of it up to a “conversation” between the user and AI. It is worth noting that when Gemini was asked to write code above, it evaluated, and showed the output. This means that code could be created when needed from layman (non-programmer) instructions and evaluated on the fly. The Jevons paradox would then apply to software creation but this additional consumption of code would be answered without the direct involvement of programmers during the implementation of the rest of the software.

Conclusion

While AI already demonstrates that it can write code, and will therefore undoubtedly automate aspects of code generation, its impact on the software development landscape will be complex and unevenly distributed. The breadth of activities programmers perform besides writing code, and the broader factors influencing the cost of software, suggest a nuanced impact rather than a simple replacement of human programmers. Key implications for software creation, the value of programming expertise, and the potential application of the Jevons paradox include:

Accelerated Prototyping & Enhanced Productivity for Experts: Experienced programmers with an understanding of domain & context could leverage AI to create functional prototypes far more rapidly. This ability to quickly translate concepts into working models ("vibe coding") could dramatically reduce the cost and time associated with prototyping, potentially increasing overall demand for it, thus aligning with the Jevons paradox principle where efficiency boosts consumption. Product managers or other subject matter experts with sufficient programming knowledge could also become prototype creators.
Continued Primacy of Humans in Quality Software Development: The creation of robust, well-integrated, and precisely tailored software will likely remain reliant on human programmers. Activities such as system design, complex problem-solving, ensuring security, and nuanced requirement interpretation can tightly be connected to coding but will likely remain less easily automated for a while. In addition to that, coding represents only a part of the total cost of software development, limiting the share of AI code generation if this risks compromising quality or relevance. AI is then likely to function more like an advanced developer assistant (akin to sophisticated IDEs) rather than a replacement, and talented developers will still be in high demand.
Significant Disruption for Entry-Level and Code-Centric Roles: Programmers whose roles primarily involve writing standard code segments may face significant disruption as AI tools become increasingly capable of performing these tasks. This could particularly affect the software development outsourcing industry and reshape career paths for junior developers, potentially decreasing demand for these specific roles.
Potential Transformation of UI/UX Development: User interface development could undergo substantial changes. Components might shift from being meticulously pre-designed and coded to being generated dynamically based on user needs or simpler instructions. If this leads to a vast increase in the volume of UI code generated, even without direct programmer involvement for each instance, it could exemplify the Jevons paradox – greater efficiency leading to increased overall code production, albeit through different means. This would also affect programming roles focused on UI/UX

In summary, AI's integration into software development points towards a future where demand decreases for human expertise in programming without higher-level design, oversight, and domain-specific application as AI handles more routine coding tasks. The overall demand for "software solutions" might increase due to AI-driven efficiencies (Jevons paradox), but the demand for specific types of programming roles will likely change significantly.

Building a CPU in Minecraft: https://www.pcworld.com/article/559794/8-bit-computer-processor-built-in-minecraft-can-run-its-own-games.html

Another Question

Discussion about this post