ORIGINAL ESSAY / SYSTEMS AND PEOPLE
The Code Will Keep Coming. The Engineers Might Not..
A prediction that arrived early
In 1996, during a technical seminar at the high school where I was working as a substitute teacher, I presented a predictive graph about the evolution of IT and computer science over the following decades. The model was deliberately pessimistic. I had built it around the logic of Amdahl’s Law: no matter how many resources we add, the part of the work that cannot be parallelised eventually becomes the limit.
Somewhere around 2030, the curve bent upward with alarming speed. At the scale of the graph, it started to look almost exponential. Progress would no longer feel gradual; it would begin to feel discontinuous.
Apparently, I was not terribly wrong. I merely missed the date by about a decade. For a forecast made thirty years ago, I am tempted to call that precision. Modesty will recover eventually.
Strictly speaking, Amdahl’s Law does not generate an exponential curve, and the graph was not a direct plot of its equation. I used its pessimistic logic as a constraint inside a broader projection: resources would multiply, but serial work, coordination and accumulated complexity would cap how much of that capacity became useful progress.
What I underestimated was not a particular technology. It was software’s growing ability to manufacture more software.
Two laws, two different questions
Amdahl’s Law asks what happens when we add processors to a problem of fixed size. If part of the work remains serial, the maximum speedup is bounded regardless of how many processors we add. Ten people, one hundred cores or one thousand automated workers cannot make a fundamentally sequential dependency disappear. Eventually, adding capacity mostly improves the heating system.
Gustafson’s Law changes the assumption. Instead of keeping the problem fixed and asking how quickly we can finish it, it keeps the available time roughly fixed and asks how much larger a problem we can solve as resources increase. More capacity does not merely shorten the old job; it expands the job we consider possible.
The two laws are not actually contradictory. They describe different scaling regimes. Nor are they literally laws of software quality and quantity. That mapping is mine, and it should remain an analogy rather than be dressed up as mathematics. But it is a useful analogy because software development has spent decades moving along both axes at once.
The Gustafson axis describes quantity. Every time we make software production cheaper, we do not build the same application and then go home early. We enlarge the application, increase the number of applications, connect more systems, support more devices, retain more data and attempt products that were previously too expensive to contemplate.
The Amdahl axis describes the quality constraint. Some work becomes dramatically easier to automate. Other work remains stubbornly resistant: understanding the real problem, choosing system boundaries, reconciling incompatible requirements, validating assumptions, integrating with existing reality, handling failure and accepting responsibility for the result.
The central story is therefore not that one new tool suddenly changed software. The story is that our tools have been generating increasingly powerful tools for most of the history of computing.
Software learned to manufacture software
High-level languages allowed compilers to generate machine instructions that programmers no longer had to write directly. Linkers and reusable libraries turned previously solved problems into building blocks. Database engines hid storage machinery behind queries. Frameworks generated structure and supplied conventions. Package managers made enormous ecosystems available through a command. Virtual machines separated applications from physical hardware. Cloud platforms turned infrastructure into an API, while infrastructure-as-code turned that API back into software.
Then came increasingly capable build systems, continuous integration, automated testing, container orchestration, schema-generated clients, visual development environments, low-code platforms and entire application templates. A developer could produce more because previous developers had encoded their decisions into reusable machinery.
None of these tools merely made an old task faster. Each changed what counted as a reasonable task. A web shop that would once have required a specialised team could be assembled from a framework, a payment API, a hosted database, a cloud platform and several open-source packages. The effort saved at one layer became ambition at the next.
This is the compounding mechanism my 1996 model did not capture adequately. Software is not only a product. It is also a capital good used to produce new software. More importantly, it increasingly produces the tools used to produce that software. The output of one generation becomes the production system of the next.
Generative and agentic AI belong in this sequence. They are unusually fast, broad and visible, but they did not invent the direction of travel. They are the latest system for generating code, tests, documentation, interfaces and even additional tools. AI is an accelerator and a symptom of the curve, not the curve itself.
The quantity escaped
The scale of global software activity already shows the effect. GitHub reported more than 56 million developers on its platform in 2020. By 2025 it reported more than 180 million, with over 36 million joining during that year alone. Developers pushed nearly one billion commits in 2025, 25.1% more than in the previous year, and merged an average of 43.2 million pull requests every month. Around twelve developers joined from Europe every minute.
Those numbers do not mean that the world suddenly acquired 180 million professional software engineers, and they certainly do not measure quality. GitHub accounts, repositories, commits and pull requests measure participation and activity. That distinction is precisely the point: the machinery for creating software artefacts is scaling faster than our ability to decide whether those artefacts are necessary, maintainable or correct.
Europe shows the same expansion from a different angle. Eurostat reported that 47% of EU enterprises used sophisticated or intermediate cloud services in 2025, while 20% used at least one AI technology, up from 13.5% in 2024. AI is only one item in that picture. The broader story is that software platforms, hosted infrastructure and generated capabilities are spreading through companies that are not themselves software vendors. Software production is no longer confined to the software industry because almost every industry is gradually becoming dependent on software production.
The developer population is expanding with it, but not quickly or evenly enough. Eurostat counted 10.4 million ICT specialists in the EU in 2025, representing 5% of total employment. Romania stood at only 2.7%, among the lowest shares in the Union, despite the country’s very visible software sector. Cedefop’s 2026 forecast projects annual employment growth of 2.5% for ICT professionals and technicians across the EU-27 between 2023 and 2035, with Romania projected at 7.8% per year.
The United States presents a useful, although not directly comparable, distinction. Its Bureau of Labor Statistics projects employment in the narrower “computer programmer” category to decline by 6% between 2024 and 2034, while software developer employment is projected to grow by 16%. Different statistical systems define these occupations differently, so this is not a transatlantic league table. The directional split is nevertheless revealing: demand may fall for work defined primarily as translating a specified solution into code while rising for people expected to design systems, resolve ambiguity and carry the result into production.
We may need less manual coding while needing more software engineering. The industry still uses the words as synonyms, which is convenient right up until production explains the difference.
The human serial fraction
Every abstraction removes work, but it also creates distance. A package eliminates the need to implement an algorithm, while adding a dependency whose behaviour, maintenance and failure modes must be understood. A cloud service removes machines from the office while adding distributed systems, external contracts, security boundaries and operational dependencies. A framework supplies structure while making its assumptions part of the application. Code generation removes typing while producing code that someone still has to validate, integrate and own.
The complexity does not vanish. It moves between layers, and part of it becomes invisible until something fails.
That is the human serial fraction. Requirements can be gathered in parallel, implementations generated concurrently and tests executed across thousands of machines. Yet somebody must still decide what the system should do, whether the decomposition is sound, which risk is acceptable, whether a result is trustworthy and what happens when several individually correct components interact incorrectly.
Recent AI-assisted development makes this old pattern easier to see because it compresses generation so aggressively. DORA’s 2025 research found higher delivery throughput alongside higher delivery instability as AI adoption increased. Its follow-up analysis of 1,110 Google engineers described a verification tax: time saved in generation is often spent again on auditing, prompting and review, while the cognitive burden shifts from the person who produced the change to the person expected to understand it.
The global 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools, but 46% distrusted their accuracy and only 33% trusted it. Experienced developers were the most cautious. That is not proof that AI is uniquely dangerous. It is evidence that the newest production tool has amplified the oldest asymmetry in software: creating an artefact and establishing justified confidence in it are not the same task.
The cost of producing plausible code keeps falling. The cost of understanding the resulting system is not falling at the same rate.
The developers evolved too
As the tooling changed, so did the developer’s job. The profession moved progressively away from direct manipulation of the machine and towards the composition, integration and governance of layers built by other people. Knowing syntax remained useful, but knowing what not to build became more valuable. Debugging increasingly required crossing boundaries between application code, libraries, networks, databases, platforms and business processes.
Seniority therefore cannot be reduced to typing speed, years served or familiarity with a fashionable stack. It is accumulated judgment: recognising a failure pattern before it reaches production, identifying the hidden constraint, understanding which abstraction is leaking and making decisions under incomplete information. Much of that knowledge is tacit. It is transmitted through review, shared debugging, incidents, design arguments, failed approaches and responsibility that grows gradually with competence.
A junior does not become mid-level because three calendar years elapsed or because an HR system changed a label. They become mid-level by implementing bounded work, making mistakes whose consequences remain survivable, receiving review from people who understand the system and gradually owning larger portions of reality.
A mid-level developer is not simply a cheaper senior waiting for promotion. They are the transmission layer of the profession. They hold enough context to guide juniors without requiring a principal engineer to explain every function call, yet remain close enough to implementation to absorb the knowledge that architecture diagrams never contain. They turn principles into repeatable practice. They learn why the rule exists, where it bends and what happened the last time somebody “simplified” it.
That is the layer we are beginning to squeeze from both directions.
The missing middle
At one end, increasingly powerful tooling allows beginners, and sometimes people with almost no software background, to produce outputs that look surprisingly complete. That is useful when the tools provide scaffolding for genuine learning. It becomes dangerous when visible output is mistaken for competence. A polished pull request can hide the fact that its author cannot explain the concurrency model, predict the failure mode or debug the implementation without asking the same generator for another answer.
At the other end, organisations concentrate responsibility in senior, staff and principal engineers who can combine domain knowledge, architecture, judgment and leverage from the entire toolchain. A small number of experienced people can now supervise a much larger volume of visible output. In a quarterly spreadsheet, the layer between novice production and senior validation begins to look compressible.
The available evidence is not identical across regions, and pretending otherwise would be intellectually lazy.
In the United States, SignalFire’s proprietary 2026 analysis estimates that new-graduate and entry-level hiring had fallen by roughly 65% at major technology companies and 76% at early-stage startups compared with 2019. Stanford’s Digital Economy Lab, using US payroll data through June 2026, found no evidence of economy-wide AI displacement, but reported that employment among workers aged 22–25 in highly AI-exposed occupations stood 19% below where it would have been had it kept pace with less-exposed occupations. The authors correctly describe this as early, descriptive evidence rather than a causal estimate.
Europe supplies a different half of the warning. Eurofound’s 2026 report on the EU digital workforce found IT employment growing by 7–8% annually, far above overall employment growth, while shortages were most acute in senior and highly specialised roles. The report states explicitly that advanced ICT skills require years of education followed by further and on-the-job learning, and that this skills pipeline is constrained. It also concludes that education and vocational training systems in most Member States are not meeting current or projected demand.
Eurostat provides the operational symptom: among EU enterprises that recruited or attempted to recruit ICT specialists in 2023, 57.5% had difficulty filling the positions. Lack of applications was the most frequently reported obstacle, while lack of relevant qualifications and lack of experience were also major barriers. A 2026 European Commission analysis of AI and emerging digital technologies reaches a compatible conclusion from the employment side: overall employment effects may be positive, but gains are expected to favour highly skilled, prime-age workers, while young and lower-skilled workers remain more exposed without targeted support.
The US evidence says the entry gate is narrowing. The European evidence says demand is growing, senior shortages are already acute and the system that should create the required competence is not keeping pace. These are not identical findings, but they point towards the same delayed failure.
None of these datasets proves that the mid-level developer has already disappeared. They do not measure that claim directly. The disappearance of the middle is an inference about the pipeline, and it should be presented honestly as one. If fewer beginners receive real work, guided failure and human review, while organisations reserve meaningful ownership for people who are already senior, fewer engineers will develop independent subsystem knowledge in the years between.
Later, companies will announce a senior talent shortage with the baffled innocence of someone who ate the seed corn and is now disappointed by the harvest.
The warning in the curve
This is not an argument for preserving obsolete work. Nobody becomes a better engineer by manually repeating what a compiler, framework, build system or code generator can perform reliably. The point of a tool is to remove work that no longer deserves human attention.
But removing work and removing learning are not the same decision. A sustainable organisation has to preserve bounded ownership, review, debugging, production exposure and progressively harder decisions even as tools automate more implementation. Otherwise, it optimises today’s output by consuming tomorrow’s competence.
The economics of that choice are seductive. Software tools encode the knowledge of previous developers, allowing current teams to operate at much greater scale. Seniors equipped with modern platforms can supervise more systems. Juniors equipped with generation tools can complete more tasks with less direct assistance. The middle appears expensive because its value is not only in what it produces today, but in what it will be capable of understanding tomorrow.
Across a quarter, removing it looks like efficiency. Across a decade, it looks like liquidation.
The organisation consumes accumulated senior knowledge while reducing the number of people capable of inheriting it. Senior engineers become a non-renewable resource, not because expertise cannot be taught, but because the organisation removed the environment in which it used to be learned.
This brings Amdahl and Gustafson back together. Gustafson explains why the quantity and ambition of software keep expanding as each generation of tools enlarges what we can attempt. Amdahl explains why the fraction that still requires deep human understanding can dominate the quality, safety and ultimate speed of the whole system. The middle layer matters because it is how that serial human capability is reproduced.
The critical point in the curve may not arrive when one particular technology can generate all the code we request. It may arrive when the amount of software we can produce exceeds the amount of human understanding available to validate it, and when the profession discovers that it stopped training replacements for the people still capable of doing so.
We may not run out of code, tools or applications first.
We may run out of people who know when they are wrong.
Sources and methodological notes
Gene M. Amdahl, “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities,” AFIPS Spring Joint Computer Conference, 1967.
https://dl.acm.org/doi/10.1145/1465482.1465560
John L. Gustafson, “Reevaluating Amdahl’s Law,” Communications of the ACM, 1988.
https://dl.acm.org/doi/10.1145/42411.42415
GitHub, “How we built the GitHub globe,” 2020, and “Octoverse 2025,” updated February 2026. GitHub figures describe a global platform and are measures of accounts and activity, not employment or engineering competence.
https://github.blog/engineering/engineering-principles/how-we-built-the-github-globe/
Eurostat, “Towards Digital Decade targets for Europe,” 2026; “20% of EU enterprises use AI technologies,” 2025; and “ICT specialists — statistics on hard-to-fill vacancies in enterprises,” 2025.
https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20251211-2
Cedefop, “Skills Forecast: new data to guide Europe’s skills and labour market policy to 2035,” July 2026.
Eurofound, “IT sector in focus: Evolution of the EU’s digital workforce,” 2026.
https://www.eurofound.europa.eu/en/publications/all/it-sector-in-focus-evolution-digital-workforce
European Commission, Directorate-General for Employment, Social Affairs and Inclusion, “The future employment impact of artificial intelligence and emerging digital technologies in Europe,” January 2026.
US Bureau of Labor Statistics, 2024–2034 outlooks for Computer Programmers and Software Developers, Quality Assurance Analysts, and Testers. The US occupational categories are not directly comparable with Eurostat or Cedefop categories.
https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm
https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
SignalFire, “State of Tech Talent Report 2026.” SignalFire uses a proprietary dataset focused on technology firms and should not be treated as economy-wide US labour statistics.
https://www.signalfire.com/blog/signalfire-state-of-talent-report-2026
Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, “Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence,” Stanford Digital Economy Lab, revised August 2026. The authors characterise the results as descriptive indicators, not causal estimates.
DORA, “State of AI-assisted Software Development 2025” and “Balancing AI tensions,” March 2026.
https://dora.dev/research/2025/dora-report/
https://dora.dev/insights/balancing-ai-tensions/
Stack Overflow, “2025 Developer Survey: AI.”
Originally published on LinkedIn ↗. The full text is hosted here.