AI Can Create More Software and Still Cost Developers Their Jobs
More software doesn't automatically mean more developer jobs. The outcome depends on how much demand grows, how companies use productivity gains, and who can reach the work that appears. Research and employer statements need to be read at those different levels.
More software and fewer developer jobs can happen at the same time. Cheaper development can make more projects worth building while reducing the labor each requires. Even a growing industry doesn't guarantee a good outcome for everyone working in it.
1. More projects can still require less labor
Consider an entirely hypothetical software market. Initially, it produces ten comparable projects in a period, each requiring ten developer-months of work. Total labor is 100 developer-months.
Now suppose tools reduce the labor needed for the same project to six developer-months. Several outcomes are possible. Both work columns below are in developer-months:
| Case | Projects | Work each | Total work |
|---|---|---|---|
| Before | 10 | 10 | 100 |
| Same output | 10 | 6 | 60 |
| More output, less work | 15 | 6 | 90 |
| More output and work | 20 | 6 | 120 |
Every number here is invented to explain the relationship, not predict an AI productivity gain. Developer-months measure work, not a literal count of jobs.
The middle case is the uncomfortable one: software output grows by half while total developer labor falls. Demand expanded, just not enough to offset the reduction per project.
A small business might finally afford a custom tool, or a team might attempt a previously uneconomic internal improvement. There are plausible reasons for demand to grow.
But lower development costs don't automatically produce lower prices, larger budgets, or customers for every new product. Someone still has to decide that the software is useful and worth maintaining. The size of that demand response is an empirical question, not something the existence of cheaper implementation settles.
2. Productivity evidence isn't an employment forecast
Research can show that a tool helps with some work without showing how many people companies will eventually employ.
Cui and colleagues studied three randomized rollouts of an earlier GitHub Copilot at Microsoft, Accenture, and an anonymous company. Their combined analysis estimated increased completed pull requests, with noisy results across the individual experiments. The estimate concerns developers whose adoption changed because of the rollout; it isn't a universal gain for everyone offered a tool. Nor is a pull-request count a measure of employment or the value of finished products. See the authors' June 2025 paper.
A different kind of evidence comes from Humlum and Vestergaard's March 2026 discussion paper. They linked chatbot-adoption surveys in eleven Danish occupations to administrative records through December 2024. Their comparisons found no significant effects on earnings and recorded hours, despite reported benefits and changes in tasks.
That study uses comparisons between adopters and non-adopters over time, with assumptions about how those groups would otherwise have changed. It's evidence about early adoption in that setting, not proof that employment will remain unaffected by later tools everywhere. Changes shared by both groups are harder to identify through that comparison, a problem the authors examine with additional analyses. The paper is a working paper rather than a peer-reviewed final result.
3. A company explanation is evidence about its decision
Some companies explicitly make that connection when announcing job cuts. In its shareholder letter filed in February 2026, Block announced a reduction from more than 10,000 people to just under 6,000, including people leaving or entering consultation. Management explicitly connected the restructuring to its belief that intelligence tools let a smaller team do more. That is the company's stated rationale, covering its workforce broadly rather than developers alone. Block's shareholder letter
It doesn't independently establish how many roles the technology made unnecessary, whether every cut depended on AI, or whether the smaller organization will sustain the promised output. Management's expectations can drive a real staffing decision before its long-term results are known.
Other explanations deserve scrutiny too. In November 2022, Zuckerberg described Meta's layoffs in terms of increased investment based on expectations that pandemic-era online growth would persist, followed by weaker revenue than expected. His account also named competition, advertising-signal changes, and the wider economy. Meta's original employee message
That earlier case doesn't explain Block's decision or disprove later AI displacement. It shows why “a technology company laid people off” is insufficient to identify the cause.
For a particular company, the question is what changed: did automation replace tasks, were projects cancelled, were cuts made in anticipation of gains, or did earlier hiring need correcting? Several causes can contribute.
Calling every cut an AI replacement accepts too much. Calling every AI explanation an excuse dismisses too much.
4. Industry growth doesn't settle the individual loss
Suppose enough new projects appear to raise total developer employment. That still doesn't mean the people who lost their jobs will fill the new positions.
The openings could arrive later, in another country, at a lower salary, or require experience those workers don't yet have. A developer supporting a family cannot pay today's bills with the possibility that software demand will be larger in five years.
Even within a growing company, the gains can take different forms: more output from the same team, fewer hires, reassignment, or layoffs. Those choices affect people differently. A smaller recruitment budget won't appear as a dismissal, but it can still change opportunities for someone trying to enter the field.
The questions worth keeping separate are how much software gets made, how much human work it requires, and what happens to the people doing that work. A convincing answer about one of them doesn't answer the other two.