The Hollow Middle: Why the Industry's Rush to AI-First Engineering Is Quietly Engineering Its Own Collapse

On the morning of 20 October 2025, an internal DNS update in a single AWS region in Northern Virginia took down 113 services for more than fifteen hours and dragged Snapchat, Reddit, Roblox, Disney+, Venmo, Pinterest, Fortnite, and Canva offline with it. A few months earlier, a malformed configuration file from a cybersecurity vendor most non-technical people had never heard of, CrowdStrike, bricked 8.5 million Windows machines in a single morning, cancelled more than 3,300 flights, paralysed hospitals from Boston to Berlin, and forced 911 dispatchers in Phoenix to take down emergency calls with a pen and a notepad. Parametrix, an outage insurer, later estimated that the top 500 US companies absorbed roughly $5.4 billion in losses from that one update — from one vendor, on one Friday in July.

Now imagine the same morning, but the thing that fails is not a kernel driver from a security vendor or a name server in us-east-1. Imagine it is the inference layer of one of the three companies on which a growing share of the world’s software is now functionally dependent. Imagine the engineers sitting in front of those broken systems have spent the last three years doing very little except prompting and reviewing — and so when the prompt no longer works, neither do they.

That is the shape of the risk this essay is about. It is not the science-fiction risk of a superintelligence going rogue. It is a quieter, more bureaucratic, more probable risk: that the way the software industry is integrating AI right now is hollowing out the human capacity required to keep software running when the AI stops working. And that the consequences of this are going to land hardest not in Mountain View or Redmond, but in places like Dhaka.

The Numbers Behind the Hollowing

Begin with the data, because the data is now too consistent to argue with. In the 2024 Stack Overflow Developer Survey, 76 percent of professional developers said they were using or planning to use AI in their workflow, up from 70 percent the previous year, and the share actually using AI at work jumped from 44 percent to 62 percent in twelve months. By the time the 2025 survey landed, 84 percent of developers were using AI tools in some capacity. GitHub reports that 90 percent of Fortune 100 companies have adopted Copilot; Copilot itself crossed 20 million users in July 2025. Cursor, a competitor that did not exist in any meaningful sense three years ago, crossed $100 million in annualised revenue in January 2025 and exceeded a billion by the end of that year, deployed at 53 percent of the Fortune 1000.

These are not adoption curves. These are wholesale absorption curves. The technology has reached the inside of the production loop at almost every serious software company in the world inside three years. Compare that to the time it took for version control, or unit testing, or even the cloud, to become standard practice; we are watching something move through the industry roughly five times faster than anything before it.

And while it moves, the entry rung is being sawed off. Entry-level developer postings in the US fell from 3.2 percent of all postings in April 2022 to 1.2 percent by 2025, a roughly two-thirds drop. UK entry-level technology roles fell 46 percent in 2024 alone. A widely cited analysis put the collapse in junior developer hiring between 2023 and 2024 at 67 percent. A Harvard working paper covering 62 million workers and 285,000 firms found that at companies actively adopting AI, junior employment dropped by 7.7 percent within six quarters of adoption — and a 2024 SHRM survey found that 70 percent of hiring managers believe AI can do the work of an intern, with 57 percent saying they trust the AI’s output more than the intern’s.

Read that last sentence again. The majority of people doing the hiring now trust a stochastic text generator more than a graduate from a four-year computer science programme. That is not a productivity statistic. It is a cultural statement about who gets to enter the profession.

Layer on the layoffs. Roughly 246,000 people lost tech jobs in 2025, with around 69,840 explicitly tied to AI restructuring, according to industry trackers. Microsoft confirmed that 40 percent of its 2025 layoff cohort were developers. Coinbase cut 14 percent of its workforce and openly described the goal as becoming “lean, fast, and AI-native.” Meta is reported to be preparing another 8,000-person round under the same logic. The pattern is unambiguous: companies are not firing across the seniority spectrum proportionally. They are firing in the middle and the bottom and keeping the top — because the top is what reviews the AI, signs off on the AI, takes the blame for the AI.

What Senior Engineers Actually Are

This is where most policy debates about AI and labour go wrong. They treat “senior engineer” as a job description rather than a biography. A senior engineer is not a person who knows the answers; a senior engineer is a person who has been in the room when things went wrong enough times to develop a feel for what to look at when the next thing goes wrong. That feel is acquired in a very specific way. You write a function. It breaks. You sit with it. You learn why. You write another. It breaks differently. You learn why again. Over five to ten years, you compress thousands of these small wrong turns into intuition. There is, so far, no substitute for that process. Not bootcamps, not certifications, not even very good documentation. The compression happens through doing the wrong thing and finding out.

What AI coding assistants do, very efficiently, is remove the doing of the wrong thing. They eliminate the small struggles — the typo, the off-by-one, the misunderstood API contract — that used to be how craft was transmitted from a senior engineer to a junior in the slack window between standup and lunch. As one widely-read essay put it bluntly: why would a senior spend thirty minutes walking a junior through a design pattern when the junior can ask Claude and get a working implementation in thirty seconds? Both sides experience this as a productivity gain. Neither side experiences what is being lost.

What is being lost is the mentorship interaction itself, and the mentorship interaction is the only known process by which the industry produces its next generation of seniors. Microsoft has noticed this internally and has begun piloting preceptor-style programs that pair senior engineers with cohorts of two or three juniors for six-month rotations. The fact that the company most aggressive about replacing junior work with AI is also the company most explicitly investing in re-creating the apprenticeship it broke is the tell. They know what they have done.

The arithmetic of the next decade is brutally simple. If you stop hiring juniors in any volume in 2024, you have no mid-level engineers in 2028 and no seniors in 2031. The people currently in their forties and fifties retire on roughly the schedule they have always retired on. The supply of replacement seniors is whatever the pipeline produced, and the pipeline produces seniors with a ten-year lag. We have, in effect, stopped planting trees and are still cutting them, and we have done this in lockstep across most of the industry simultaneously, which means the shortage will not be local or fixable by any one firm. It will be everywhere at once.

What worries me most is the second-order effect on the engineers who do remain. A senior who came up in 2010 spent five years writing the kind of code AI now writes for them. The senior of 2035 will, if current trends continue, have spent five years prompting and reviewing. They will be older, more expensive, and structurally less capable than the seniors they replaced — because they will never have been forced through the small humiliations from which competence is actually built. We are not just shrinking the pipeline. We are degrading the quality of what comes out of it. The seniors of the 2030s will, on average, be less qualified than the seniors of the 2020s. They will, however, be in far greater demand.

The Concentration Problem

The second risk, and the one that gets less airtime, is what the industry has built underneath all this prompting. Three companies — OpenAI, Anthropic, and Google — now control roughly 88 percent of the enterprise large-language-model market. OpenAI alone is processing more than two billion API calls a day across enterprise customers who have already restructured their teams around the assumption that those calls will succeed. Anthropic powers a large share of coding workflows, document processing, and customer service automation at companies that have already shed the headcount that used to do those tasks manually. Further down the stack, TSMC sits as a near-monopoly producer of the advanced-node chips on which all of this depends, and which sit on a single contested island in the South China Sea.

If you have spent any time around critical-infrastructure thinking, you will recognise this immediately as the kind of concentration that previous decades spent a lot of regulatory effort trying to prevent. Banks are not allowed to have a single counterparty larger than a certain share of their balance sheet. Power grids are not allowed to rest on a single substation. We have, through pure market dynamics and without anyone choosing it, recreated for the cognitive layer of software exactly the kind of single-point-of-failure architecture we forbid in finance and energy.

And we have already seen the previews. The October 2025 AWS event was not unusual; between August 2024 and August 2025, AWS, Azure, and Google Cloud collectively logged more than a hundred outages. CrowdStrike’s July 2024 morning showed that a single faulty file from a single vendor can ground global aviation and drop hospital systems offline for the better part of a week. Now imagine those outages, but in a world where the engineers who would normally jury-rig a workaround have spent the previous two years doing very little except writing tickets for an AI agent to address. The mean time to recovery in such a world is not a technical question. It is a question of whether the human knowledge to recover even still exists.

The European Systemic Risk Board, in its December 2025 report on AI and systemic risk, explicitly raised this concern: financial institutions are now dependent on a small number of AI providers, monitoring is “at an early stage,” and the regulatory toolkit has not caught up. The IMF, in a parallel warning, called AI-driven cyber risk a financial-stability threat. These are not the easily-alarmed corners of public policy. These are the institutions whose job it is to look at the boring numbers and decide whether the system is about to fall over.

There is also a geopolitical face to this. The capabilities that matter — frontier-model training, advanced chips, large-scale inference infrastructure — are overwhelmingly concentrated in the United States and China, which together control more than 90 percent of global AI data-centre capacity. The rest of the world is not really a participant in the production of this technology. It is a consumer of it, dependent on terms set elsewhere. When the OECD or the EU debates digital sovereignty, this is the situation they are debating: the cognitive infrastructure of every modern industry now runs on rails owned by perhaps six companies in two countries.

Bangladesh, in This Picture

This is where I write from, so this is where the picture has to come into focus. Bangladesh has roughly 750,000 ICT professionals across about 4,500 IT and IT-enabled firms. Official ICT service exports reached $724.6 million in fiscal year 2024-25 — short of the government’s $5 billion target by a margin embarrassing enough that it now goes mostly unmentioned at industry events. Add in the freelancer economy, where Bangladesh is the world’s second-largest supplier of online labour with more than a million active workers, and the true figure is probably north of a billion dollars in foreign exchange a year. The BPO sector alone employs more than 80,000 people across about 400 firms, around 40 percent of them women.

A lot of that work — call it most of that work — is precisely the kind of work that GitHub Copilot, Cursor, and the new generation of inference-priced automation tools are designed to absorb. Junior implementation, routine integration, content moderation, data labelling, transcription, customer support, basic web development for foreign clients. The Daily Star reported in 2025 that AI has already eliminated roughly 30 percent of entry-level jobs from the Bangladeshi BPO market in the previous eighteen months. One firm went from 250 employees in mid-2023 to 150 by the time the article ran. Pakistan grew its IT exports 18 percent in the same window to $3.8 billion; Bangladesh’s official figure grew 7.7 percent to under a billion. The gap between the country that pivoted faster and the country that did not is now wide enough to see from low orbit.

The temptation in Dhaka is to treat this as a productivity story. The same Bangladeshi engineer, augmented by AI, can now do the work of two or three engineers, the argument goes, and so export earnings can grow even if employment does not. This is true for about eighteen months. Beyond that, two structural problems land. First, every other country’s engineers also have AI, which means the productivity gain does not accrue to any particular country; it shows up as price compression in the global market for software services and squeezes margin out of everyone. Second, the entry-level work that historically funded the on-ramp into the profession is exactly the work AI is best at, which means the country loses its main mechanism for building the next cohort of senior engineers domestically. The juniors who would have become Bangladesh’s senior architects in 2034 are right now not getting hired in 2026, because their first job has been quietly replaced by an API call.

The longer-term picture is bleaker still, because Bangladesh, like most of the global south, is a price-taker rather than a price-setter on the AI infrastructure itself. The inference that the country’s call centres and software shops now depend on is billed in US dollars to corporations in San Francisco. If those prices rise — and the economics of frontier-model training make rising prices structurally likely — the squeeze hits a Bangladeshi BPO’s margin before it hits an American buyer’s. If the providers restrict access for any reason, whether commercial, political, sanctions-related, or simply because a submarine cable was cut in the wrong place, the country’s IT export sector has no domestic substitute to fall back on. There is no national large-model capability. There is no domestic compute of meaningful scale. We have, as a country, walked into a deep dependency on infrastructure we did not build, do not control, and cannot replace.

What I Am Not Saying

I want to be careful here, because the cost of being read as a Luddite is that the actual argument gets dismissed. I am not saying AI coding tools should be banned, or that no engineer should use one. I use them myself, often, and they are genuinely useful. I am not saying the productivity gains are imaginary. They are not. I am saying that the way the industry is currently absorbing this technology — fast, uncoordinated, with the cost falling on the entry rung and the dependency concentrated in three or four firms — is producing a set of second-order risks that almost nobody is sized to absorb individually, and that compound into a system-level risk that is not being managed by anyone.

The honest version of this critique is that the productivity case for AI in software is real but oversold, the displacement case is real and understated, and the concentration case is real and almost entirely unaddressed outside a handful of think tanks and central banks. The combination of those three things is what worries me. Any one of them, on its own, would be a problem we could probably grow through. All three together, on a five-to-ten-year timeline, are a structural transformation that the institutions designed to manage transformations are nowhere near keeping up with.

What Would Help

I think three things would help, none of them sufficient on their own. First, firms should be made to count, internally and publicly, the cost of the experience they are not building — the way carbon emissions started to appear on balance sheets in the 2010s after a long fight to make them visible. A junior engineer who is not hired in 2026 is a senior engineer who does not exist in 2034. That is a balance-sheet item, not a vibes-based concern, and it should be measured. Second, the AI-provider concentration question needs the same treatment that banking concentration got after 2008. Systemically important inference providers should face redundancy, failover, and substitutability obligations, and large customers should face concentration limits — the way no bank can lend more than a fixed percentage of its capital to any single counterparty. Third, countries like Bangladesh should be investing now, while the window is still open, in domestic compute, domestic talent pipelines for AI engineering specifically, and domestic substitutes for the most dependency-heavy parts of their software-export economy. Not because national autarky is achievable. It is not. But because the cost of having no alternative at all, the day the dependency becomes a problem, is higher than the cost of having a partial alternative ready.

None of this happens by accident. The current trajectory — fast adoption, junior-layer hollowing, three-firm concentration, no public accounting of the experience deficit — is the path of least resistance for every individual actor in the system. Each firm hiring fewer juniors saves money this quarter. Each developer using more AI ships more this sprint. Each country deferring its own AI infrastructure investment saves capital this fiscal year. The pattern is rational at every level except the level at which it has to be paid for, which is the level at which nobody is in charge.

The Honest Conclusion

I do not know whether we are heading for what could fairly be called a doomsday scenario. I do not think doomsday is the right word, and I am suspicious of anyone who uses it. What I think is more likely is something less cinematic and more grinding: a software industry that becomes progressively less capable of fixing its own problems, increasingly dependent on a small set of cognitive utilities that occasionally fail, increasingly unable to onboard new humans into the craft, and increasingly unequal in who gets to participate at all. A worse version of the world we already have, arrived at by everyone making locally reasonable choices over the next decade.

Whether that is a doomsday or just a long disappointment depends, I think, on whether the institutions that govern this transition — companies, governments, professional bodies, international standards organisations — can find their voice in the next three to five years. The window for steering this is open. It will not be open indefinitely. The decisions that decide what 2035 looks like are being made right now, in hiring plans, in cloud-vendor commitments, in the design of computer-science curricula, in the procurement choices of national governments. Most of those decisions are being made by people who are responding to immediate pressures and who do not have the time, the mandate, or the incentive to think about the system as a whole.

The job of essays like this one is to insist, against the pressure of every quarter’s productivity numbers, that the system as a whole is the thing that matters. The job of the people reading them is to act, in whatever small way is available, as if the next generation of engineers actually needs to exist. If we wait until 2034 to discover that we forgot to make them, it will be too late to start.