AI could reduce the number of developers needed inside large organizations while, at the same time, creating new demand for technical skills in companies that until now have never been able to afford a real software department.
When we talk about the impact of artificial intelligence on developers’ jobs, the discussion almost always tends to move in the same direction. If a programmer, thanks to tools such as Codex, Claude Code, or GitHub Copilot, can produce in a few hours what would previously have taken days, the conclusion seems fairly obvious: we will need fewer developers in the future.
That will probably be true, at least to some extent.
A software company that employs one hundred people today may discover that it can maintain the same level of output with a much smaller team, especially because a growing portion of the work that previously required junior developers can now be performed, or at least accelerated, by AI systems. More experienced developers, in turn, can handle a much larger volume of work by coordinating agents, generating code, reviewing implementations, and working across different parts of a project at the same time.
If we look only at this side of the equation, it is easy to conclude that AI will inevitably lead to a reduction in the number of software jobs.
But, I think there is another part of the story that we are paying much less attention to, and to understand it properly we first need to consider how much of the software market is organized today.
Most companies do not build their own software. They buy it, or increasingly, they rent it.
A restaurant uses a reservation system, a logistics company buys management software, a professional firm uses a CRM, a small business adopts an accounting system, while another pays for a series of SaaS subscriptions to manage sales, employees, documents, communication, and internal processes.
This model exists for a very simple reason: building software has always been expensive.
Even a relatively ordinary application required analysts, developers, database administrators, infrastructure specialists, testers, security expertise, and eventually people responsible for maintaining it. For a large organization, absorbing those costs could make sense. For a small or medium-sized company, in most cases, it did not.
The result has been a strong concentration of software expertise: on one side, we have companies whose product is software and that employ hundreds or thousands of people to build it. On the other, we have millions of businesses that use that software and that, with very few exceptions, would never have had the financial or organizational resources to build something equivalent internally.
This structure has also created a compromise that we know very well.
When a company buys commercial software, that software has rarely been designed exactly around the way that particular company works. It has been designed to serve a market large enough to justify the cost of developing it.
As a consequence, it contains dozens, sometimes hundreds, of features that each individual customer only uses in part. Some fit the company’s processes well, while others require configuration, workarounds, or simply force the company to change the way it works.
For years, we have accepted this compromise because the alternative made little economic sense.
Building completely customized software for a small business, simply to reproduce the twenty or thirty percent of features it actually uses, would have cost far more than buying a SaaS subscription.
Artificial intelligence could change that equation.
Not because the owner of a small business will suddenly become a software developer and start building an ERP system over the weekend. That, in my opinion, is one of the more naive interpretations of the current enthusiasm around so-called vibe coding.
Building software that is actually meant to be used by a business remains an engineering activity. You still need to understand how to model data, manage authentication and authorization, design the architecture, integrate external services, protect sensitive information, test the system, and, above all, maintain it when something inevitably changes.
The fact that a model can quickly generate ten thousand lines of code does not make any of these problems disappear, but it can radically change the amount of work required to solve them.
And this is where I think a transformation could begin that is far more interesting than the simple debate over how many programmers will lose their jobs. A small company that until yesterday could never have afforded a team of five or ten developers may discover that one technically capable person, supported by sufficiently advanced AI systems, can build and maintain a significant portion of the software that the company actually needs.
The company, incidentally, already possesses one of the hardest things to acquire: knowledge of its own business.
The owner of a logistics company understands the problems of logistics far better than a newly hired developer does. The people who work inside the company every day know the exceptions, the manual steps, the Excel spreadsheets that nobody dares to touch, the information that gets copied from one system to another, and all those small inefficiencies that are often completely invisible from the outside.
What is usually missing is not domain knowledge. What is missing is the ability to transform that knowledge into a reliable software system.
And this is precisely where a new category of professionals could emerge: they would not necessarily need to know the industry before joining the company, because that knowledge can be transferred by the company itself. What they would need is the ability to take a real business process, understand it together with the people who use it every day, and translate it into requirements, architecture, data models, integrations, and eventually working software, using artificial intelligence as a multiplier of their own productive capacity.
This also changes the way we should think about the possible loss of jobs inside large technology organizations.
If a software company can do with fifty developers what previously required one hundred, then fifty positions may indeed disappear from that particular company but, that does not necessarily mean that the overall demand for software expertise will fall by the same amount.
If, at the same time, thousands of companies that previously bought only standard software begin developing small internal applications, automations, vertical systems, and customized integrations, part of that demand may simply move from companies that build software for everyone to companies that build software for themselves.
And this is why I think that talking only about the destruction of software jobs risks making us miss the more interesting transformation.
We may be at the beginning of a redistribution of work.
For decades, the ability to produce software remained concentrated inside a relatively small number of organizations because building it was expensive. If AI dramatically lowers that cost, the consequence is not necessarily only that fewer people will be needed to produce the same amount of software.
The opposite could also happen: we may begin producing far more software, in far more places, for problems that until yesterday were simply not economically worth solving with a customized solution and, if that happens, one of the most important changes will not simply concern how many developers we will need in the future. It will concern where they work, who they work for, and, above all, what kind of work they will be expected to do.
From Programmer to Solution Engineer
This possible redistribution, however, creates an important problem for people who work in software development today, particularly those whose roles involve relatively standardized activities and who are therefore more exposed to automation.
The most common answer is that these people should simply “learn AI.”
I do not think that is enough.
Knowing how to use a coding agent will soon become a baseline skill, in much the same way that today we do not consider it particularly distinctive for a developer to know how to use Git or an IDE.
The real professional transition consists in moving from being someone who receives a task and produces code to being someone capable of taking a poorly defined problem and turning it into a complete technical solution.
That means talking to the people who actually perform the work, understanding what they are trying to achieve, distinguishing a real requirement from a preference, identifying exceptions, modeling the data correctly, deciding which parts should be built and which should be bought, designing integrations, validating the behavior of the system, and making sure that what has been built still works six months later.
AI can write a huge amount of the code required to do all of this, but someone still needs to know what code should exist in the first place, and this is probably the direction in which some of today’s developers will need to evolve.
Not necessarily toward a more abstract or managerial role, but toward a more complete form of engineering in which the ability to program remains important while becoming only one component of a much broader job.
Paradoxically, then, AI could reduce the economic value of simply producing code while increasing the value of being able to turn real-world problems into functioning systems.
For a junior developer, this may sound like an uncomfortable prospect, because part of the work that traditionally represented the entry point into the profession is precisely the kind of work that AI tools are learning to automate most quickly.
But it may also be a fairly clear indication of where they should invest their time: not simply in becoming faster at producing code with AI, but in learning how to manage the entire process that takes a business need and turns it into a production-ready solution.
If software really does become easier and cheaper to build, that capability could become useful in far more places than it is today.
And this is where the story about AI and software jobs could take a very different direction from the one we usually imagine.
Perhaps we are not simply entering a world in which we will need fewer developers.
Perhaps we are entering a world in which many more companies will be able to afford to have one.