In December 2025, AWS CEO Matt Garman called replacing junior developers with AI “the dumbest thing I’ve ever heard.” Juniors, he said, are “probably the least expensive employees you have” and often “the most experienced with AI tools.”

A few weeks later, Anthropic CEO Dario Amodei predicted that AI “could someday wipe out 50% of entry-level jobs.”

Two CEOs. Same industry. Opposite conclusions from the same data. The confusion is understandable, because the industry is asking the wrong question. “Will AI replace developers?” is a yes-or-no framing for a problem that isn’t yes-or-no. The better question: what replaces the apprenticeship that turned juniors into seniors?

Because that apprenticeship is dying. And nobody has a plan for what comes after.

The numbers nobody wants to reconcile

The data looks contradictory, until you read it at the right altitude.

The U.S. Bureau of Labor Statistics projects +15% growth for software developers through 2034 (much faster than average). BLS explicitly cites AI, IoT, and robotics as drivers of that demand, not threats to it.

At the same time, the BLS “computer programmer” category (the narrow, coding-only role) has declined 27.5% in two years, hitting its lowest level since 1980. Software engineering job postings sit at 65% of February 2020 levels, a five-year low according to Indeed data cited by the Pragmatic Engineer.

These aren’t contradictions. They’re the same story, told at two different zoom levels. Coding is shrinking. Engineering is growing. The job that was primarily about typing code is disappearing. The job that involves designing systems, evaluating trade-offs, and directing tools (including AI) is expanding.

The split shows up starkly in age data:

SignalData
Developer employment ages 22-25-20% from late 2022 peak (Stanford)
UK entry-level tech roles-46% in 2024, projected -53% by end 2026
Junior employment at AI-adopting firms-9 to 10% within six quarters (Harvard, 62M workers)
Senior employment at same firmsBarely moved
Hiring mechanismHiring freezes, not layoffs; promotions for existing juniors increased

And then there’s the HBR bombshell. A survey of 1,006 global executives (Davenport and Srinivasan, December 2025) found that 60% made or planned headcount reductions in anticipation of AI. But only 2% cut jobs due to actual AI implementation proving it could replace the work. Companies are laying off workers because of AI’s potential, not its performance.

Klarna is the poster child. Cut 40% of its workforce. Quality tanked. Customers revolted. Then it started quietly rehiring. Salesforce announced “no more software engineers in 2025.” Microsoft laid off 15,000+ (over 40% from engineering) while Satya Nadella reported 30% of code was AI-written. Google, meanwhile, has 30% AI-generated code, no developer layoffs, and a growing headcount.

Two signals, one trend: fewer coders, more engineers. Which raises an uncomfortable follow-up: what happens to the people who were supposed to become the engineers?

Jevons was right (again)

I wrote about William Stanley Jevons two weeks ago, in the context of working hours. The short version: in 1865, Jevons noticed that making coal use more efficient didn’t reduce consumption. It made coal-powered industry viable in new places, and consumption exploded.

The same pattern has played out in software three times already.

Compilers (1950s-60s): “We won’t need as many programmers once machines translate high-level languages.” Result: programming became accessible to non-specialists, software ate new industries, and developer employment grew by orders of magnitude.

IDEs and frameworks (1990s-2000s): “Visual Basic and Java will let business analysts write their own software.” Result: more software was built, more developers were hired to maintain it, and the web created an entirely new category of engineering work.

Cloud and SaaS (2010s): “Serverless and low-code will eliminate backend developers.” Result: cloud lowered the cost of deployment, which enabled startups that wouldn’t have existed, which hired developers.

Each time, the prediction was the same: efficiency reduces headcount. Each time, Jevons was right: efficiency reduces cost-per-unit, which increases demand, which increases total employment. BLS isn’t projecting +15% growth despite AI. It’s projecting +15% growth because of AI.

Alfonso Fuggetta made the same observation from Italian soil: while commentary panicked about AI labor exposure, Wall Street Journal data showed software engineering postings actually growing. Efficiency lowers the bar for building software, which means more software gets built, which means more people are needed to build it.

But this cycle has a twist the previous three didn’t. The aggregate number of developers may grow, but the composition is shifting. Jevons demand will go to people who can direct AI agents, evaluate architectural trade-offs, make production systems reliable. Not to people who can write boilerplate. The paradox creates a specific kind of demand: senior demand. And that’s where the pipeline problem bites.

The pipeline flip

For fifty years, the path from junior to senior looked roughly the same. You got hired to do work that was necessary but not complex: bug fixes in legacy services, CRUD endpoints, writing tests, updating dependencies. Nobody hired you for your judgment. They hired you because the team needed someone to handle the growing backlog of small tasks, and they bet you’d absorb enough context over three years to start making architectural decisions.

This model was never efficient. Most of what juniors learned came not from the boilerplate they wrote, but from what surrounded it: reading other people’s code, navigating deployment pipelines that broke in ways the docs didn’t cover, debugging production incidents at 2 AM, and living inside a codebase long enough to understand why certain patterns existed and which ones were mistakes. The grunt work was a holding pen. The actual education happened through immersion.

AI doesn’t kill the learning. It kills the job that provided the immersion.

If an AI agent can write the CRUD endpoint, fix the dependency, and generate the test in seconds, there’s no economic reason to hire a junior to do it over days. The Harvard study quantifies this precisely: AI-adopting firms hired 5 fewer junior workers per quarter post-2022. Not fired. Never hired in the first place.

The bootcamp market tells the same story from the other side. General Assembly shut down. Lighthouse Labs closed after acquisition. Turing School announced closure in June. 2U’s bootcamp segment saw a 23.3% revenue decline driven by a 40% enrollment drop. The “learn to code” narrative, which powered a decade of career-change marketing, collapsed when the entry-level jobs it promised started disappearing.

The education world is split on what to do. Harvard’s CS50 banned ChatGPT, Copilot, and other AI tools, building constrained in-house AI that supports learning without short-circuiting it. Stanford launched CS146S, “The Modern Software Developer,” its first AI software development class, integrating AI from day one. UCSD created a $1.8M GenAI in CS Education Consortium funded by Google.

The disagreement on how is total. The agreement that the old model is dead is unanimous.

Why you can’t skip the learning

If the apprenticeship is dying, maybe vibe coding is the shortcut? Andrej Karpathy coined the term in February 2025: give in to the vibes, embrace exponentials, forget the code exists. By late 2025, he’d walked it back himself, calling it “passé” and advocating instead for “specification engineering,” which is really just a fancy name for “know what you want before you ask the machine.”

The graveyard explains the reversal. Escape.tech audited 5,600 vibe-coded apps and found over 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of PII including medical records and IBANs. A vibe-coded payment processor approved $2 million in fraudulent transactions. Georgetown’s CSET found that 45% of AI-generated code contains security vulnerabilities (for Java, over 70%). GitClear analyzed 211 million changed lines and found code duplication increased eightfold while deliberate refactoring collapsed from 25% to under 10%.

I wrote about the talent pipeline fractures and the cognitive load transformation earlier this month. The vibe coding disasters are what those fractures look like in production.

This is not a junior-bashing argument. I’ve caught myself accepting AI output I shouldn’t have. The difference is that I can usually spot the failure before it ships, because I spent decades building the mental models that let me evaluate AI-generated code against production reality. A junior using the same tools, with the same access, in the same IDE, produces a fundamentally different outcome. Not because the AI is worse. Because the human validator is still forming.

The specification engineer

If vibe coding is the wrong model, what’s the right one?

Martin Fowler noted in February 2026 that “LLMs are eating specialty skills,” meaning the need for dedicated frontend or backend specialists is declining as “the LLM-driving skills become more important than the details of platform usage.” Kent Beck’s framework distinguishes skills AI deprecates (language syntax mastery, framework API memorization) from skills it amplifies (vision, architectural strategy, code quality taste, system design judgment).

I’d call this the specification engineer. Not a coder, but a director of AI agents who must understand enough about every domain to validate the output.

When I built a prison monitoring platform in 9 days, I didn’t write 11,000 lines of Python. Claude did. But I made every architectural decision: structured output over free text, narrative memory as flat JSON over graph database, batch inference for cost, pgvector for semantic search, Terraform for infrastructure. I was the specification engineer. The AI was the implementation layer.

This requires more multidisciplinary knowledge, not less. When your AI agent writes a database migration, a backend API, and a frontend component in 30 seconds, you need to evaluate all three. You need to know enough about database indexing to spot missing indexes, enough about API design to catch broken pagination, enough about frontend rendering to notice accessibility gaps, enough about security to find the exposed endpoint.

Addy Osmani captured the split: “Seniors use AI to accelerate what they already know how to do; juniors try to use AI to learn what to do. The results differ dramatically.” Fastly’s survey puts numbers on this: senior developers (10+ years) report that 32% of their shipped code is AI-generated, compared to 13% for juniors. Seniors ship 2.5x more AI code because they can quality-control it.

The Pragmatic Engineer reports that teams are shrinking from “two-pizza teams” (6-10 people) to “one-pizza teams” (3-4). Each remaining engineer covers more surface area. The specification engineer isn’t a specialist. They’re a generalist with deep enough understanding across domains to direct AI effectively, and that’s a profile that takes years to build. You can’t shortcut it with a better prompt.

The Hollywood model

This is where I’ll make a prediction that might age badly.

If companies need seniors (Jevons says demand is growing) but won’t train juniors (the pipeline data says they aren’t), the industry will shift toward something resembling Hollywood film production.

In Hollywood, there are no “junior directors” at Marvel. You assemble a team of proven experts for a project: a director, a DP, a production designer, a VFX supervisor. Each brings decades of craft. They collaborate intensely for months, then disband. Careers are built on portfolios of shipped work, not years served at one studio.

Software engineering is already moving this way. Contract-based senior teams assembled for a product sprint. Platform teams of 3-4 specification engineers, each directing a fleet of AI agents. Juniors don’t enter through corporate apprenticeship; they enter by making “indie films.”

The economics make this possible. When I built BehindBarsPulse, the total infrastructure cost was Google’s $300 free GCP credits plus a few dollars for email delivery. A full-stack monitoring platform with AI editorial generation, semantic search, and statistics dashboards, for the price of a coffee. The cost of the “indie film” has collapsed to near zero.

So here’s the pipeline flip. The old model: get hired as a junior, write boilerplate for three years, absorb context, get promoted, become a senior. The new model: build 50 full-stack applications using AI in your first two years. Watch 40 of them collapse under real-world edge cases, bad data models, or security vulnerabilities. Learn architecture through rapid, unshielded failure. Build a portfolio of production systems that demonstrate you understand why the naive AI choices fail.

The apprenticeship didn’t die. It flipped from “slow immersion inside a company” to “high-velocity failure outside one.”

Whether this is better or worse depends on whether the learning actually transfers. Indie projects teach you to start things. They don’t teach you to maintain them. Production codebases have properties that personal projects never will: ten years of accumulated debt, three teams writing conflicting patterns, deployment pipelines that fail in undocumented ways. You can build 50 apps and never once navigate a monolith someone else wrote in 2017.

There’s one bridge that might fill that gap: open source. OSS is the only place an unhired junior can experience large-scale legacy code, strict CI/CD pipelines, and human code review from experienced maintainers. Contributing to a 100K-line open source project, with its merge policies, its historical architectural decisions, its grumpy maintainers who reject your PR because you didn’t read the contributing guide, is closer to corporate apprenticeship than any indie prototype. The indie path builds; the OSS path teaches you to maintain and collaborate. You probably need both.

The Hollywood analogy also carries a warning. In film, the model produces extreme inequality. Most actors are broke. Most indie directors never get a second feature. If software follows this path, it’s an opportunity for the disciplined and a cliff for everyone else.

The market bifurcation

Not every company will follow the same path. I see two tiers forming.

Tier 1 companies (cost optimization): aggressive junior hiring cuts, maximum AI automation, leaner teams. They’ll show short-term savings and long-term pain. When the seniors they depend on leave, the replacement pipeline doesn’t exist. The industry estimate for replacing one mid-level engineer, including recruitment, onboarding, and lost productivity, is approximately $2.1 million. The math catches up.

Tier 2 companies (talent investment): structured junior programs paired with AI tools, deliberate mentorship frameworks, investment in the specification engineering skillset. These companies will have a competitive advantage in 18-24 months, especially in regulated markets where vibe-coded apps don’t survive compliance review.

The HBR data makes this concrete. If 60% of executives are cutting on anticipation and only 2% on evidence, that’s a speculative bubble in workforce reduction. Bubbles pop. Klarna already popped. The companies that maintained their pipeline while others gutted theirs will be positioned to absorb the talent demand when Jevons kicks in.

What I’m betting on

I’ve spent 25 years building engineering teams and I’m now back in the trenches writing Go. Here’s where I’ve landed.

Jevons will win. More software will be built. More developers will be needed. But the role will look different: less typing, more directing, more validating, more cross-domain judgment. The cognitive load doesn’t shrink; it transforms. The working hours don’t decrease; they intensify.

The specification engineer is harder to become, not easier. Anyone who tells you AI makes software engineering simpler is confusing typing with engineering. The typing got easier. The thinking got harder. And the bar for what counts as “senior” just moved up.

Companies cutting juniors on hype are building a talent time bomb. The 2% evidence figure from HBR will be cited in retrospectives for years. Cutting your pipeline because AI might replace the work, without evidence that it can, is a bet against Jevons and against every previous wave of automation.

The indie path will produce some extraordinary engineers. Not all of them, maybe not even most. But the ones who build 50 apps, watch 40 fail, and learn why, will arrive at “senior” with a portfolio of production scars that no three-year corporate apprenticeship could match. The friction shifted from “boilerplate inside a company” to “failure outside one.” The learning potential is still there. The safety net isn’t.

I wrote in January that “productivity has shifted from writing speed to validation speed.” I’d extend that now: the career path has shifted from apprenticeship speed to failure speed. The developers who learn fastest from their failures, not from their prompts, are the ones who’ll make it through.

One question I’d leave for anyone hiring engineers in 2026: if the apprenticeship is dead, how do you tell the difference between an “indie senior” who learned architecture through fifty failed apps, and a lucky vibe coder who shipped one that happened to work? Because the resume looks the same. The take-home looks the same. And if your interview process can’t distinguish them, you’re back to the broken hiring signal I wrote about two weeks ago, just from the other direction.

Methodology note

This article was written with AI assistance (Claude Code for research aggregation and drafting, Gemini for structural review). The research draws on BLS data, Harvard/Stanford labor studies, HBR executive surveys, and industry reports from GitClear, Fastly, METR, and Escape.tech. All citations link to primary sources or first-party reporting.

The prediction about the “Hollywood model” is mine, informed by two rounds of adversarial challenge with a second AI (Gemini) that pushed back on the core assumptions. The strongest counterargument: the Hollywood model works in film because the craft is stable, and software’s constant reinvention might make portfolio-based careers less portable. I don’t have a good answer for that yet.

Acknowledgments

This piece builds on three earlier articles that examined the problem from different angles: the talent pipeline fractures, the cognitive load transformation, and the Jevons Paradox in working hours. The “pipeline flip” framing emerged from a structured debate between Claude and Gemini that forced me to separate what I believe from what the evidence actually supports.

Sources