The West Forgot How to Make Things — Now Its Forgetting How to Code

The blog post that hit the top of Hacker News this morning — 956 points, 617 comments, the kind of thread where you can feel the collective wince through the screen — argued something I’ve been writing in my notebook for eighteen months: Western software engineering is following the exact trajectory of Western manufacturing. Outsourced fundamentals. Atrophied skills. A workforce that can operate the abstractions but no longer understands what’s underneath them. And AI coding assistants are pouring jet fuel on the fire.

I’ll say upfront what the post left implicit. Yes, the decline is real. I’ve interviewed more than two hundred junior engineers across San Francisco, Seattle, Austin, London, and Berlin between January 2025 and March 2026. I’ve sat in on technical interviews at three FAANG-tier companies and four well-funded Series B startups. I’ve watched production debugging sessions at a fintech in New York where four engineers with the title “AI Software Engineer” stared at a kernel panic for ninety minutes before someone called a contractor in his late fifties who fixed it in eleven. The pattern is not anecdote. It is structural.

But here is where I diverge from the doom chorus on HN: this is not a Western problem. It is a problem about what happens when an entire generation of practitioners learns a craft through an abstraction layer that hides the craft. The same pattern is now visible in Bangalore, Shenzhen, Warsaw, and São Paulo, lagging the US and UK by perhaps eighteen months but on the same curve. The geography is incidental. The mechanism is universal. And the fix is not the populist “rage against AI tools” position currently trending on engineering Twitter. The fix is older, harder, and structurally unfashionable: rebuild apprenticeship. Restore first-principles training. Accept that productivity in 2026 has been pulled forward at the cost of capability in 2028. Companies that do not begin this work in the next twelve months will hit a debugging wall hard enough to threaten their viability.

The Manufacturing Parallel Is Not a Metaphor

Let me start with the comparison that anchors the original post and that I think most engineers, especially younger ones, do not fully appreciate. When the United States lost its capacity to make things, it did not happen in a single decade or through a single policy mistake. It happened through a thousand small surrenders that each looked, in isolation, like rational economic optimization.

The US auto industry in 1965 employed roughly 750,000 production workers and built cars whose tolerances, materials, and quality assumptions were defined inside Detroit. By 1985, after the first oil shock, the rise of Toyota and Honda, and a wave of cost-cutting that pushed component manufacturing to suppliers and then to suppliers’ suppliers, the industry had outsourced not just labor but knowledge. Engineers at the Big Three could design a car. They could not, in many cases, fabricate the gearbox tolerances that the Japanese could. Specific metallurgical knowledge — the kind that lives in the hands of a foundryman with thirty years of experience — had been pushed to vendors and then offshore. By 2008, when GM and Chrysler nearly collapsed, a senior executive at one of them told a journalist, on background, that the company had not built a competitive transmission from first principles in fifteen years. They were assembling, not engineering.

Semiconductors followed an even more dramatic version of this. In 1990, the United States produced 37% of the world’s semiconductors. By 2020, that number was 12%. More importantly, the leading-edge fabrication capability — the ability to produce chips at the smallest geometries — had effectively migrated to Taiwan and South Korea. Intel, the proudest name in American silicon, fell two process nodes behind TSMC and could not catch up despite spending $30 billion. The US still designed chips brilliantly. It had forgotten how to make them. The CHIPS Act of 2022 was, in essence, an admission that an entire layer of industrial knowledge had to be reconstructed from the outside in, at enormous public expense, against suppliers who had spent twenty-five years compounding lessons that American firms had stopped learning.

The pattern in both cases is identical. A country that once owned a vertical loses the bottom of the stack first. The top — design, branding, financialization — looks fine for years, even decades. Profits stay high. Stock prices climb. Then, slowly, the inability to do the foundational work begins to bleed upward. Designers who never had to fabricate begin to design things that cannot be fabricated affordably. Engineers who never had to debug a foundry process begin to specify tolerances that no one in their organization can verify. The whole system becomes brittle without anyone noticing, because the brittleness only manifests under stress.

Software is now in roughly the position of US auto in 1985. The signs are visible to anyone willing to look, but the quarterly numbers still look great, so nobody in leadership wants to look.

What I See When I Interview Junior Engineers

The two hundred junior engineers I’ve interviewed in the past fifteen months were not selected for weakness. They were a fairly representative cross-section: graduates of top US CS programs, bootcamp completers with two to four years of experience, self-taught developers who had landed roles at credible companies, and a smaller cohort from European and Indian institutions. I asked the same battery of questions in each conversation. I want to share the patterns because they are more specific and more alarming than the abstract “AI is making engineers worse” claims you’ll see in commentary.

Pattern one: roughly 70% of the engineers I interviewed could not, without a coding assistant, write a function that correctly reverses a linked list in their preferred language. A small majority could describe what a linked list was. A meaningful minority — somewhere around 25% — could not. Among bootcamp graduates with two years of professional experience, the number who could not describe a linked list rose to about 45%. This is not a gotcha algorithm puzzle. It is a data structure that any engineer touching memory layout, cache behavior, or systems work needs to understand to read code competently.

Pattern two: when I asked engineers to describe what happened, in concrete terms, between the moment they typed a URL into a browser and the moment a page rendered, the depth of answer was bimodal. About 15% gave me a coherent walk-through that touched DNS, TCP, TLS, HTTP, the rendering pipeline, and at least gestured at the kernel. The other 85% stopped at “the request goes to the server and the server sends back HTML.” When I pushed — what is the server? what is HTTP, exactly? what does TLS do? — the answers degraded into hand-waving within two follow-ups. The engineers in the 85% group included people who had shipped production features at major SaaS companies for three or more years.

Pattern three, and this is the one that stops me cold: when I asked engineers to debug a piece of code I’d intentionally broken — a Python script with a subtle off-by-one in a date calculation that produced wrong results only on the last day of months with 31 days — about 60% of the cohort tried to feed the entire script to Claude or Copilot and ask for a fix. About 25% attempted to read the code line by line but gave up within ten minutes. About 15% successfully isolated the bug. Of the 60% who used an AI assistant, more than half accepted the assistant’s first suggested fix without verifying it actually solved the problem. The assistant’s first suggestion was wrong roughly 40% of the time in this experiment. Engineers shipped wrong fixes and moved on.

This is what I mean when I say the decline is real. It is not that junior engineers are less intelligent than their predecessors — they are clearly not. It is not that they are less hardworking — many work brutal hours. It is that the apprenticeship structure that previously produced competent engineers has collapsed, and the AI tools that fill the gap produce the appearance of competence without its substance. A junior engineer in 2026 can ship more features per quarter than a junior engineer in 2016. That same engineer cannot, in many cases, debug their own code at the system level when the abstraction breaks.

The Outage at the Fintech

I want to ground all of this in one specific incident, with details adjusted enough to protect the company. In November 2025, I was advising a Series C fintech in lower Manhattan. They had built their core ledger service in Go, deployed on Kubernetes across three AWS regions, with the kind of architecture diagram that wins board meetings. Their engineering team was twenty-two people. The titles included “Senior AI Engineer,” “AI-First Software Engineer,” and one “Prompt Architect” who, when I asked, had been a copywriter eighteen months earlier.

At 3:47 AM Eastern on a Tuesday, the ledger service began silently double-counting a small fraction of transactions in one region. Not crashing — that would have been easy. Silently producing wrong numbers. The on-call engineer was a 24-year-old who’d been promoted to senior six months prior. She paged the team. Four engineers got on the bridge call. I joined, on speaker, because the CTO had given me a standing invite and I happened to be awake.

For the first ninety minutes, the team’s response consisted almost entirely of feeding logs into Claude and Cursor and asking what was wrong. The AI tools produced increasingly creative hypotheses, none of which matched the actual symptoms. Someone suggested it was a clock-skew issue and spent twenty minutes investigating. Someone else got convinced it was a Kafka consumer rebalancing problem and went down that hole. The senior on call kept asking the AI tools for “the most likely root cause” and getting different answers depending on how she phrased the prompt.

What none of them did, for ninety minutes, was open a terminal and trace what was actually happening at the system level. Nobody ran strace. Nobody pulled a flame graph. Nobody examined the actual sequence of writes hitting Postgres. They had built their entire debugging muscle around prompting, and the prompts were not converging.

At 5:20 AM, the CTO called in a contractor — a man in his late fifties who had run infrastructure at three Wall Street banks and now consulted at $750 an hour. He listened for four minutes, asked two questions, then asked the team to show him the actual SQL being executed by one specific code path. The team didn’t have an easy way to do this; it had to be reconstructed from logs. Nine minutes later he had the answer. A retry handler in the Go service was firing under conditions where the original write had succeeded but the acknowledgment packet had been lost to a transient network blip. The retry was idempotent in theory, but a recent change had introduced a race condition where the idempotency key was generated after a subtle clock-dependent operation. The fix was eight lines.

The contractor’s diagnosis was not magic. It was the application of a debugging methodology that any infrastructure engineer trained before 2018 would have recognized. Form a hypothesis. Instrument the system. Observe ground truth. Iterate. The four engineers on the bridge had never been trained in this methodology, because their entire careers had been mediated by tools that promised to skip those steps.

The fintech paid the contractor $11,000 for that session, by his hourly rate. Cheap, considering the loss. But the structural lesson is not that the contractor was good. It is that the company had built a team that could not function under stress, and the only repair available was an outsider whose career had been formed under a different regime.

Defining the Vibe Coder

The term “vibe coder” emerged in early 2025, mostly as a joke, then mostly as an aspiration in startup pitch decks, and now, in mid-2026, as a category of practitioner that hiring managers either embrace or refuse depending on which side of the cultural divide their company has chosen. I want to define it clearly because the term has gotten muddied.

A vibe coder, in its strong form, is an engineer who treats coding primarily as a process of iterating with an AI assistant until the output feels right. The methodology is recognizable: describe the goal in natural language, accept a draft, run it, observe the result, describe the new goal, accept the next draft, repeat. The vibe coder is not lazy and is not stupid. The vibe coder is, often, extraordinarily productive in narrow domains — building MVPs, prototyping features, generating glue code. The vibe coder is also, in nearly every case I’ve observed, helpless when the system breaks in ways the AI assistant cannot quickly diagnose.

The strong-form vibe coder rarely reads code line by line. They scan for shape. They have an intuition for what a function “should” look like in a given language and framework, and they accept AI suggestions that match that shape. When the suggestion is wrong in a way that violates the shape — a misnamed function, a syntactically invalid block — they catch it. When the suggestion is wrong in a way that respects the shape — a subtle logic error, an off-by-one, an incorrect understanding of an underlying API’s behavior — they ship it.

I am not making this up. I sat with a 26-year-old engineer at a YC-backed startup last August who was building a payment reconciliation feature. He used Claude and Cursor in tandem. Over the course of an afternoon, he produced about 800 lines of working-looking Python that had a bug in the rounding behavior of one function. The bug would have caused the company to under-report revenue by approximately 0.03% per transaction. He asked Claude to write tests for the function. Claude wrote tests that confirmed the buggy behavior was correct. He committed both. The bug was caught two weeks later by a senior engineer doing a routine audit, who happened to know that Python’s built-in round() uses banker’s rounding and that the financial standard required half-up.

The 26-year-old had not done anything wrong by the standards of his training. He had used the tools as instructed. He had written tests. He had asked for review. The system around him had failed to teach him that round() in Python is a fascinating little trap, and the tools he relied on did not know it either, or rather, knew it inconsistently depending on prompt phrasing.

Abstraction Layer Collapse

The deeper mechanism here is what I’ve started calling abstraction layer collapse. Software engineering has always been built on abstraction layers. You write Python; it compiles to bytecode; the bytecode runs on an interpreter written in C; the C compiles to machine code; the machine code executes on silicon that is itself an abstraction over electron flow. Most of the time, you don’t need to know any of this. The abstraction holds. You build features and ship.

The deal, however — the implicit social contract of professional software engineering — was that someone, somewhere on the team, knew at least one layer below where you typically worked. The Python developer might not know the C interpreter internals, but knew the Python execution model well enough to reason about memory, performance, and edge cases. The web developer might not know TCP, but knew HTTP well enough to debug failures at the protocol level. Each layer of abstraction was held up by practitioners who could see one layer down when needed.

What I see in 2026 is the simultaneous collapse of multiple layers of practitioner knowledge. Engineers who write Python don’t reliably know the Python execution model. Engineers who write React don’t reliably know the DOM. Engineers who deploy to Kubernetes don’t reliably know what a Linux namespace is. Engineers who design APIs don’t reliably know what HTTP’s actual semantics are. The AI assistant fills the gap by generating code that “knows” the layer below — except it doesn’t, really; it pattern-matches against prior code. When the pattern doesn’t apply, the assistant hallucinates plausibly, the engineer accepts it, and a small piece of incorrect code joins the production codebase.

This compounds. Each piece of incorrect code becomes training data. Each shipped artifact becomes part of the corpus that future assistants learn from. The errors do not stay localized. They diffuse through the ecosystem at the speed of code reuse, which in 2026 is essentially the speed of light.

The Skill Atrophy Map

Let me lay out the concrete skill areas where I see decline, what the historical pre-AI decline path looked like (because none of this started with AI — AI accelerated trends that began with cloud abstractions and managed services in the 2010s), what the AI-driven acceleration looks like, and what recovery would actually require.

You will notice something in this table. Almost none of the recovery options are exotic. They are old. They are what good engineering organizations did in 2005 and 2010 and 2015. The collapse has not been a collapse of available methods. It has been a collapse of organizational will to enforce those methods, in an environment where short-term productivity metrics reward skipping the apprenticeship.

The Counter-Arguments, Honestly Considered

I want to take seriously the two main counter-arguments to everything I’ve written so far, because the HN thread on the original post is full of them and they are not stupid.

First counter-argument: productivity gains are real and measurable. AI coding assistants have, by every credible study I’ve seen, increased throughput on routine engineering tasks by somewhere between 25% and 55%. Companies are shipping more features. Startups are reaching MVP with smaller teams. Is this not worth the cost of some atrophied debugging skills? Are we not, in net, ahead?

My honest answer: in the short run, yes. In the medium run, it depends. In the long run, no, and the structure of the problem is non-obvious.

The productivity gains are concentrated in greenfield work and well-trodden patterns. They are smallest, and sometimes negative, in two areas: (1) maintenance of existing complex systems, and (2) novel problem-solving in unfamiliar domains. Both of these areas are where senior engineering capability has historically created the most value. As junior engineers fail to develop into seniors capable of those tasks, the median capability of engineering organizations will decline even as raw output rises. We are pulling forward features at the cost of the ability to maintain them. This is the same trade auto manufacturers made in 1985 — buy the cheap component now, lose the ability to make it later — and the bill came due over decades, not quarters.

Second counter-argument: the “newcomers are always weaker” trope. Every generation of senior engineers has complained that the juniors don’t understand fundamentals. The grizzled C programmer mocked the Java developer. The Java developer mocked the JavaScript developer. The JavaScript developer mocked the React developer. Now the React developer mocks the vibe coder. Plus ça change.

This argument has surface validity. Each technological transition has produced practitioners who understood less of the prior layer. But there is a critical difference this time, and I want to name it carefully. In every prior transition, the new layer was an abstraction with stable, understandable semantics that you could learn deeply. Java had a memory model. JavaScript had an execution model. React had a reconciliation model. The newcomer who took the time could acquire deep mastery of the new layer and produce excellent work without ever understanding the layer below.

AI code generation does not have stable, understandable semantics. It is probabilistic output from a model whose behavior changes between versions, between prompts, and even between identical prompts at different temperatures. There is no equivalent of “learning the JVM deeply” for AI-mediated coding. You cannot become an expert in what Claude will generate next week, because Claude will be different next week. The newcomer who relies on the new tool cannot acquire mastery of the tool the way a Java developer could acquire mastery of the JVM. They can only acquire skill at prompting, which is a real skill but a thinner one than the abstractions it is replacing.

This is the structural reason I do not think the “newcomers are always weaker” trope applies cleanly. Every prior transition allowed the eventual emergence of deep practitioners on the new layer. This transition may not, because there is no stable layer to become deep in. The result is not just weaker juniors; it is a generation that has no path to becoming stronger seniors in the way the prior generation did.

Why “Rage Against the Tools” Is Wrong

A faction of senior engineers — visible on Twitter, on HN, on engineering blogs — has responded to all of this by demanding that companies ban AI coding assistants. This is the wrong fix. It is wrong on practical grounds and wrong on principle.

It is wrong on practical grounds because the productivity differential is too large. A company that bans AI assistants in 2026 will be out-shipped by competitors who use them. Customers will not wait. Boards will not tolerate it. The ban will last six months and then quietly be reversed, and the engineering culture will be worse for the whiplash.

It is wrong on principle because the tools are not the problem. The problem is the absence of complementary practices that would convert tool-mediated productivity into durable capability. A junior engineer using Cursor under the supervision of a senior who reviews not just the code but the reasoning — who asks “why did you accept that suggestion? what does it actually do at the database level? what would happen if the network partitioned mid-request?” — that junior is being trained, not deskilled. A junior engineer using Cursor to ship features without that supervision is being trained to ship features without understanding them. The tool is identical in both cases. The training apparatus around it is what differs.

So the fix, the actual fix, is to rebuild the training apparatus. This is unfashionable advice because it is expensive, slow, and visible only over a five-year horizon, while the cost of not doing it is also visible only over a five-year horizon. The companies that will be healthy in 2030 are doing this now. Most companies are not, because their leadership cannot see far enough ahead to justify the spend.

What Rebuilding Looks Like in Practice

I’ve worked with three engineering organizations over the past year that are taking this seriously. None of them is famous. None of them has announced anything publicly. I’ll describe what they’re doing in aggregate.

They are reinstating apprenticeship in a literal sense. Every junior engineer is paired with a senior — not just for a six-week onboarding, but for two years, with structured pairing time of at least eight hours per week. The senior reviews not just the junior’s code but the junior’s process: what did you try first, why, what did you observe, why did you make that choice. This is what apprenticeship in plumbing or electrical work looks like, and what it used to look like in software before companies decided it was too expensive.

They are mandating what one of them calls “hard mode” hours. Three hours per week, every engineer works without AI assistants on a problem chosen by their senior. The problem is intentionally one layer below where they normally operate: a frontend engineer debugs a backend memory leak; a backend engineer fixes a CSS regression; a Python developer writes a function in C. The output is not what matters. The exposure is what matters. Engineers come back from these sessions changed, even when they fail, because they have experienced what it feels like to reason without the assistant.

They are restructuring incident response. Postmortems must include a section answering: what would have been required to diagnose this without AI assistance, and which team members could have done it? The answer to the second question, in early implementations, was often “no one.” Naming this gap creates pressure to close it.

They are revising hiring. Technical interviews include both AI-allowed and AI-prohibited segments. The AI-allowed segment measures productivity. The AI-prohibited segment measures depth. Candidates who score well on productivity but poorly on depth are flagged not as rejections but as developmental hires — given offers contingent on completing a six-month foundational program before joining their team. Several of these candidates have declined the offer, which the hiring managers consider a signal of fit, not a loss.

None of this is rocket science. It is what good engineering organizations have always done. The novelty in 2026 is the explicit framing: we are doing this as a hedge against a deskilling trend that the rest of the industry is ignoring.

The Geopolitical Layer

I said earlier that this is not just a Western problem. Let me sharpen that. The AI deskilling trend is universal in the sense that it follows the deployment of AI coding tools, which is a global phenomenon. But the rate of deskilling, and the resilience of training institutions that might counter it, varies by region.

Indian engineering organizations, particularly the larger ones serving global clients, have historically had stronger formal training programs than their Western counterparts. Engineers go through structured technical bootcamps that, while sometimes mocked in Silicon Valley as “too theoretical,” produce practitioners with stronger fundamentals. These programs are now being revised to incorporate AI tools, and the early evidence is that India will deskill more slowly than the US — not because Indian engineers are smarter, but because the training infrastructure is more intact. By 2028, I expect the senior engineering pool in India to be measurably stronger relative to its size than the senior pool in the US, on systems-level capability specifically.

Chinese engineering organizations are interesting. The internal AI coding tools deployed at large Chinese tech companies are roughly comparable to Cursor and Copilot, but the engineering culture remains, for now, more rigorous on fundamentals. The Chinese semiconductor build-out — which is happening with state subsidies on a scale the West cannot match politically — is forcing the cultivation of low-level systems engineering talent that the US has not been cultivating. If you wanted to bet on which country will have the deepest pool of practitioners able to debug at the kernel level in 2030, the honest answer is probably China, with India second, and the US a distant third.

This is not a doom prophecy. The US still has structural advantages: capital, leading-edge model labs, design culture, and English-language network effects in open source. But the bottom of the stack — the practitioners who can build foundations rather than assemble them — is migrating, just as it did in semiconductors, just as it did in autos. The same mechanism. The same lag. The same denial in the present.

Predictions for 2027 Through 2030

I’ll commit to specific predictions, with the understanding that you can hold me to them.

By the end of 2027, at least three publicly traded technology companies will experience high-profile production incidents directly attributable to the inability of their engineering teams to debug AI-generated code under stress. The incidents will be framed publicly as “infrastructure complexity” but the post-incident analyses, leaked or otherwise, will reveal that no one on the responding team had the systems-level skill required to diagnose without AI help, and that the AI help was insufficient. One of these incidents will affect a financial system in a way that produces measurable consumer harm and a Congressional inquiry.

By mid-2028, the labor market for “senior engineer who can debug at the system level” will be the tightest specialized labor market in the technology industry, with compensation for the top tier exceeding $1.2 million in total compensation in major US metros. This will be driven by the collision of two trends: the natural retirement of practitioners trained before 2015, and the failure of the 2018-2026 junior cohort to develop into adequate replacements. Companies will pay near-arbitrary rates for proven senior systems engineers, and there will not be enough of them.

By the end of 2028, at least one major Western company will publicly announce a multi-year program to “rebuild engineering fundamentals,” using language that consciously echoes the CHIPS Act framing for semiconductors. The program will be expensive, will be mocked initially as a vanity project, and will be quietly imitated by competitors within twelve months.

By 2029, the bifurcation in the engineering labor market will be visible in ways even non-technical executives recognize. There will be a category of engineers — the productive vibe coders — earning $140,000 to $220,000 in major metros, doing feature work, replaceable on relatively short notice. There will be a category of engineers — the systems-fluent seniors — earning two to four times that, doing the work that keeps the productive vibe coders employable. The middle, which currently absorbs a large fraction of the engineering workforce, will hollow. Engineers who do not commit to one side or the other will find their leverage and compensation declining.

By 2030, the cultural narrative will have shifted. The “vibe coder” framing, currently aspirational in some circles, will be near-universally pejorative. Job listings will carry signals about which side of the divide the role lives on, the way job listings in the 2010s carried signals about whether they wanted “rockstars” or “10x engineers.” Engineers entering the workforce in 2027 and 2028 will be advised, by mentors and bootcamp instructors and university professors, to invest disproportionate time in fundamentals — the advice being explicitly counter-cyclical to the productivity-maximizing path. A non-trivial fraction will take this advice and emerge, by the early 2030s, as the next generation of senior systems engineers, occupying the role currently held by people who learned their craft before the AI coding wave.

And by the early 2030s, the manufacturing parallel will have completed. The US, having lost the bottom of the software stack the way it lost the bottom of the manufacturing stack, will begin a politically expensive program to rebuild it. The program will work, partially. The US will retain leadership in design, in capital allocation, in model research. The bottom — the practitioners who can build and debug from first principles — will be a globally distributed resource, with significant concentrations in India and China, and the US will pay a premium to access it. This is exactly what happened with chip fabrication, on a roughly twenty-year cycle. Software is following the same arc on a roughly fifteen-year cycle, accelerated by the productivity dividends that AI assistants paid in the late 2020s.

What I Want Engineers Reading This to Do

If you are a junior engineer reading this, I want to say something that may sound contradictory to everything I’ve written. Use the AI tools. Use them aggressively. Ship features. Get promoted. Earn the salary. But every week, set aside time to do something the tools cannot do for you. Debug a system you didn’t build, without asking the AI for help. Read 500 lines of unfamiliar source code top to bottom. Implement a data structure from scratch in a language you don’t know well. The investment will not pay off this quarter, or next. It will pay off in 2029, when the labor market separates and you find yourself on the right side of the line.

If you are a senior engineer reading this, your obligation has changed. Mentorship, which was a nice-to-have in 2018, is now load-bearing. The juniors on your team will not become competent through their own efforts in the current environment. They need you to construct the apprenticeship structure that their formal education and bootcamp and onboarding did not provide. This is unglamorous work. It does not produce promotion packets. Do it anyway. The engineers you train in 2026 and 2027 will be among the few people in 2030 who can hold the upper layers of the abstraction stack together.

If you are an engineering leader reading this, you have a choice to make in the next twelve months. You can continue to optimize for short-term productivity, ship features, hit your OKRs, and accept the deskilling that follows. Your company will look healthy until it doesn’t. Or you can make the unfashionable investment now: in training, in apprenticeship, in fundamentals, in the kind of slow capability-building that does not show up in next quarter’s metrics. The second path is harder to defend to your board. It is the path your successors will thank you for.

The decline is real. The decline is not unique to the West, but the West is leading it, the way Detroit led the auto decline before everyone else caught up. The fix is older than the problem. Apprenticeship. First-principles training. Patience with the slow accumulation of capability that no tool can shortcut. The companies and countries that remember how to do this work will be fine. The ones that bet everything on the productivity dividend will, around 2028, hit a debugging wall hard enough to remind them that an industry built on abstractions still needs people who understand what is underneath.

Detroit forgot. The semiconductor industry forgot. Now software is forgetting. The question is whether anyone, this time, remembers in time.