The End of Programming as We Know It

Tim O'Reilly · article · 2025-02-04 source ↗ Reader 🖥️

theoretical · argumentative — A historically-grounded essay arguing against the 'AI ends programming jobs' narrative by analogy to prior programming-paradigm shifts (assembly, compiled languages, GUIs, the web, cloud) and economic-history evidence (Bessen's textile-mill research), synthesized with quotes from several named industry figures (Schillace, Taylor, Osmani, Huyen, Sankar, Yegge, Willison).

Structure

Key terms

• learning by doing
  James Bessen's term (borrowed directly) for the decades-long process by which a technology's productivity benefit is actually realized: inventors make machines more robust, users invent new workflows, businesses adopt, and workers acquire new skills — all simultaneously and gradually, which is why big productivity gains lag the technology itself by decades.
• the 70% problem
  Addy Osmani's observation (quoted at length) that AI gets most people most of the way to a working demo, but the last fraction — making it production-grade — requires engineering judgment that nonprogrammers and inexperienced programmers lack; junior engineers who accept AI output uncritically produce 'house of cards code.'
• programmable surface area
  The total scope of problems across a business, science, or infrastructure that could in principle be addressed by programming; the author's argument is that this surface area expands faster than AI-driven per-programmer productivity, so net demand for programmers rises even as each one becomes more productive.

Propositions

• explicitEvery prior major programming-abstraction shift (assembly language, compiled languages, GUIs/OS driver encapsulation, the web, cloud/API economy) was popularly framed as 'the end of programming,' yet each one increased the total number of programmers and the scope of what got built, because falling cost of creation increased demand (elasticity of demand) faster than it eliminated roles.conf: high
• explicitAt today's largest internet-scale companies (Google, Amazon, Facebook), the bulk of the actual operational work is already done by software/algorithms rather than humans, and human programmers' role has already shifted to supervising and managing these digital workers — a transition that happened gradually and did not eliminate programming as a profession.conf: high
• explicitHistorically, large productivity gains from a new general-purpose technology take decades to materialize — not because the technology is insufficient, but because the workflow knowledge, skill diffusion, and organizational redesign needed to use it well accumulate slowly, person by person and workplace by workplace (James Bessen's 'learning by doing').conf: high
  supportsOrdinary Engineers, Not Heroic Inventors · p6 — Same author returning to the same Bessen/diffusion-theory mechanism in a later essay; this article is the earlier, fuller statement of the 'skill infrastructure diffuses slowly' argument that the later piece applies specifically to GPT/AI diffusion.
• explicitWhat matters for realizing a new technology's benefit is not how fast any one individual can be trained, but how long it takes to build a stable, broadly trained workforce across an entire industry — which is why AI-literacy investment needs to be organization-wide, not just early-adopter individuals.conf: high
  supportsOrdinary Engineers, Not Heroic Inventors · p10 — Both make the same point in different words: the organizational know-how/workforce-wide skill needed to realize a new technology's benefit accumulates gradually and must be broad, not just held by a few early adopters.
• explicitWhen senior engineers use AI coding tools, their visible speed comes from applying years of engineering judgment to constrain and shape the AI's output, not from simply accepting it; junior engineers who lack that judgment accept AI output more readily, producing code that looks complete but collapses under real-world pressure ('house of cards code').conf: high
  supportsAI coding creates two kinds of debt. You're only measuring one · p4 — Osmani's 'house of cards code' / junior-engineers-accept-AI-output-too-readily observation, quoted here, is the same mechanism behind the comprehension-debt findings that gap names (junior engineers losing the judgment to catch bad AI output).
• explicitThe meaning of 'programming' will shift from the physical/mechanical act of writing code to the higher-level abstraction of arranging ideas into executable form — the same shift that happened to 'writing' once mass literacy made the physical act of putting words on paper no longer the scarce, intellectually-marked skill.conf: high
• explicitThe hardest part of deploying an AI agent in a business is not the programming itself but deeply understanding the business processes well enough to know what should be automated, what should remain AI-assisted, and what must still be done by people — Palantir's 'journey from prototype to production,' echoing the 20-year gap between DARPA Grand Challenge-winning Stanley and a fully edge-case-capable self-driving car.conf: high
• explicitIf AI makes programmers roughly ten times more productive, but the resulting expansion of what can economically be programmed ('programmable surface area') across business, science, and infrastructure is twenty-fold, net demand for programmers still rises rather than falls.conf: medium
• explicitBusinesses that use AI-driven productivity gains purely to cut costs will lose to competitors that reinvest the gains into higher-quality services — demand for quality, not just speed/cost, persists even as capability becomes cheaper (illustrated by VFX: a single frame of a modern blockbuster can take as long to render as all of the first Pixar film, despite enormous hardware gains, because quality expectations rose in step with capability).conf: medium

Arguments

Narratives

• James Bessen's study of Lowell, Massachusetts textile mills in the early 1800s: skilled home-based crafters were replaced by 'unskilled' factory workers, wages stayed flat for ~50 years not because factory owners hoarded gains (though they did) but because it took decades for workflows, machine robustness, and worker skill to diffuse — an apprentice craftsman and a new factory worker took about the same time to reach full productivity, just via different kinds of skill.
  → Provides the article's central historical-economic mechanism for why AI's labor effects will likely play out gradually via skill-diffusion lag rather than as a sudden mass-displacement event.
• Stanley, the DARPA Grand Challenge-winning self-driving car (2005), could do something remarkable but needed another ~20 years of development to handle the edge cases of real urban driving.
  → Illustrates the 'journey from prototype to production' gap — a working demo and a deployable, edge-case-robust system are separated by a much longer and harder path than the initial breakthrough suggests.
• Rendering a single frame of a modern Marvel movie can take as long as rendering the entirety of the first Pixar film, despite enormous CPU/GPU price-performance gains (Moore's Law), because the extra compute went into quality (fur, water, reflections) rather than just speed.
  → Supports the claim that falling cost/rising capability shifts competition toward quality rather than simply commoditizing the prior quality level cheaply — an analogy for why AI-driven coding capability will likely raise software quality expectations rather than just cut costs.

Questions addressed

• ✅ Will AI cause mass unemployment among software programmers?
  No — by historical analogy to prior abstraction shifts and Bessen's diffusion-lag mechanism, demand for programmers (broadly redefined) should rise, not fall, as programmable surface area expands faster than per-programmer productivity.
• ✅ Why does AI coding capability (demos, prototypes) not translate directly into deployed business value?
  Because the hard part is understanding and encoding business processes and handling edge cases (the 70% problem, the journey from prototype to production), not generating code per se.
• ⭕ Could the speed and breadth of today's AI diffusion compress Bessen's multi-decade 'learning by doing' lag into a much shorter period than the Industrial Revolution took — and if so, would the article's reassurance still hold over the relevant (much shorter) time horizon?

Gaps

• incompleteThe article's central analogy (AI's labor effects will resemble the Industrial Revolution's multi-decade diffusion lag) never addresses whether today's much faster information diffusion, platform distribution, and AI self-improvement could compress that lag dramatically — which would matter enormously for near-term organizational and team planning even if the long-run 'more programmers, not fewer' conclusion holds. For a team/org planning horizon of 2-5 years, 'eventually it works out' is compatible with a very disruptive intervening period that the article doesn't characterize.
  Read next: Matt Beane's warnings (quoted elsewhere in this corpus) about the rate of change over the 'next year and a half' exceeding the prior two years would be a useful counterweight on timing, even if not on the long-run outcome.
• incompleteThe article doesn't engage with who bears the cost during the decades-long diffusion lag it describes approvingly — Bessen's own finding is that wages stayed flat or depressed for ~50 years during the first Industrial Revolution partly because factory owners hoarded productivity gains. The optimistic framing here ('learning by doing,' 'AI-literate workforce') elides the distributional question of whether today's equivalent of 19th-century factory workers (today's junior/mid-level programmers) will see their share of the eventual gains, or whether gains will again concentrate upward during the diffusion period.
  Read next: Documents in this corpus on who captures AI productivity gains at the org level (e.g. Charity Majors on junior-hiring economics, or pieces on AI and wage distribution) would sharpen this.

Related documents

• AI coding creates two kinds of debt. You're only measuring one
• Ordinary Engineers, Not Heroic Inventors
  Code Was Never the Bottleneck Skill Infrastructure (Ding) Technology Diffusion & Transformation Curves
• Nils Brede Moe's Post
  Code Was Never the Bottleneck Technology Diffusion & Transformation Curves
• AI and the Looming Competition for Margin
  Jevons Paradox Technology Diffusion & Transformation Curves
• How Organizations Use AI: Evidence From ChatGPT
  Skill Infrastructure (Ding) Technology Diffusion & Transformation Curves
• The third golden age of software engineering – thanks to AI, with Grady Booch
  Abstraction Shifts in Programming (History) Code Was Never the Bottleneck
• Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect
  Jevons Paradox Technology Diffusion & Transformation Curves
• We've Stopped Arguing About Whether AI Changes Software
  Code Was Never the Bottleneck Technology Diffusion & Transformation Curves