The keyboard was never the bottleneck
Mike Amundsen · article · 2026-04-16 source ↗ Reader 🖥️
Changeability & OptionalityCode Was Never the BottleneckNear-Zero-Cost CodeSociotechnical ArchitectureSoftware Design Fundamentals
Generative AI commoditizes the lowest levels of programming work — producing code for known problems under fixed assumptions — but the harder, higher-level challenges of designing systems that survive change remain untouched and are now more visibly important.
theoretical · argumentative — The article advances a thesis about the nature of programming difficulty and where AI fits within it. It is structured as an argument with a taxonomy (the four levels) serving as supporting evidence. No practical how-to advice is offered.
Structure
| Part | Role |
|---|---|
| Opening: 'AI replacing programmers' claims | Problem statement — acknowledges the real change while asserting the claims misidentify where difficulty lives |
| The levels (four-level taxonomy) | Analytical framework — decomposes programming into solution-specific, repeatable, shared, and socio-technical levels |
| Shopping/book example | Concrete illustration of the four levels applied to a single domain |
| Where AI is strong | Concession — grants AI's real power at levels 1 and partially 2 |
| What changes / The boundary | Core argument — the progression from answers to abstraction to anticipation, and AI's limitation at generalization under changing constraints |
| Why structure doesn't go away | Corollary — APIs and shared contracts become more, not less, important when code production is cheap |
| What this means / And So… | Conclusion — the shift is in where difficulty resides; an opportunity to 'get better at getting better' |
Key terms
- the keyboard Code Was Never the Bottleneck
The act of producing code — typing, syntax, implementation — as opposed to the intellectual work of design and judgment - solution-specific computing
Level 1: code that solves one problem under fixed assumptions and has no further role once the task is done - socio-technical systems Sociotechnical Architecture
Level 4: systems operating within human institutions, shaped by policy, incentives, interpretation, and accountability — the 'system' includes people and organizations - anticipation Changeability & Optionality
The design skill of building systems that support a range of possible futures, including unanticipated ones - scaling design Changeability & Optionality
Making design itself — not just runtime behavior — able to absorb change, support extension, and remain coherent across teams over time
Propositions
- explicit⚡ disputed & corroboratedThe limiting factor in programming has never been the speed of producing code, but the ability to understand problems, define boundaries, anticipate change, and build for evolution.conf: highsupports ←AI Demands More Engineering Discipline, Not Less · p9 — Both make the identical claim (Majors in footnote 9) that the limiting factor in software was never the speed of writing code, so cheap/free code generation does not remove the actual hard parts.supports ←The "funhouse mirror": How AI reflects the hidden truths of your software pipeline · p2 — Both hold that the limiting factor was never the speed of producing code; Laycock draws the consequence that accelerating code-writing without fundamentals produces debt, not value.extends ←From AI Code to Trusted Software: Harness Engineering in Practice · p4 — Frisinger's claim that code generation 'stopped being the bottleneck some time ago' and that verification is now the constraint extends the sibling extraction's four-level bottleneck thesis by naming the specific structural fix (mechanically-enforced repository standards, i.e. a harness) for the downstream bottleneck it identifies.contradicts ←Henrik Kniberg's Post · p1 — Kniberg's 'coding is no longer the primary bottleneck' implies coding once was the constraint; Amundsen asserts producing code was never the limiting factor.
- explicitGenerative AI is very effective at level 1 (solution-specific computing) and partially effective at level 2 (repeatable local workflows), but its effectiveness drops sharply at levels 3 and 4.conf: high
- explicitcorroboratedAI does not replace programming; it compresses and commoditizes the lower levels while exposing the importance of the higher ones.conf: highsupports ←The AI paradox: More automation, more humans, more work | Dan Shipper · p8 — Same claim in different vocabulary: AI commoditizes the lower levels of work and pushes humans permanently up to the higher ones.
- explicitThe need for shared contracts (APIs, stable interfaces) becomes more pronounced, not less, when code is produced more quickly and by more contributors with less shared context.conf: high
- explicitProgramming work can be decomposed into four distinct levels with different goals, constraints, and failure modes.conf: medium
- explicitLower costs of code production can lead to more rapid production of solution-specific code without corresponding gains in system design.conf: high
- implicitcorroboratedThe value of human programmers is shifting toward planning, architecture, and the exercise of judgment about possible futures.conf: highsupports ←Inside a Software Factory · p17 — Both converge on the same claim: as AI absorbs more of the execution work, the durable human value shifts toward planning, architecture, and judgment about what's worth building — Iusztin frames it as the factory's permanent bottleneck, Amundsen as levels 3-4 of a four-level taxonomy.
- explicitAI-generated code that works in isolation characteristically fails when inputs vary, coordination is required across components, or it is exposed to real-world conditions over time.conf: medium
Arguments
AI does not replace programming; it shifts where difficulty and attention are required. strength: high
Explicit premises:
- The bottleneck in programming was never code production but understanding problems, defining boundaries, and anticipating change.
- AI is effective at producing code for known problems under fixed assumptions (level 1).
- Higher-level programming challenges (shared systems, socio-technical systems) involve evolving constraints, multiple stakeholders, and anticipation of change.
- AI struggles with maintaining coherence across systems as they grow and evolve.
Implicit premises:
- The distribution of programming work across the four levels is such that higher levels represent the bulk of long-term value.
- The skills required at higher levels (judgment, anticipation, design for change) are not readily automatable by current generative AI approaches.
Inferences:
- Since AI addresses the historically non-bottleneck part of programming, it cannot eliminate the need for programmers.
- Since higher-level work becomes more visible when lower-level work is automated, the role of the programmer shifts upward rather than disappearing.
APIs and shared contracts become more important, not less, in an AI-assisted development environment. strength: medium
Explicit premises:
- When multiple actors depend on a system, expectations must be made explicit.
- AI enables code to be produced more quickly and by more contributors with less shared context.
Implicit premises:
- More contributors with less shared context increases the coordination burden.
- Shared contracts (APIs) are the primary mechanism for managing coordination across contributors.
Inferences:
- More producers plus less shared context equals greater need for explicit coordination mechanisms.
Narratives
- Book-shopping agent example across four levels: from a single-purpose agent finding one out-of-print book, to a repeatable multi-source search system, to a multi-user e-commerce platform, to a full ecosystem handling currencies, tax, fraud, and external dependencies.
→ Makes the abstract four-level taxonomy concrete by showing how the same domain escalates in complexity at each level - Reference to Douglas Engelbart's 'getting better at getting better'
→ Frames the opportunity positively — AI could enable meta-improvement in how we build systems, not just faster production of code
Questions addressed
- ✅ Is AI replacing programmers?
No — AI is shifting where the difficulty resides, commoditizing lower-level code production while making higher-level design and judgment more visibly important. - ✅ Are APIs dead?
No — the need for shared contracts becomes more pronounced, not less, when code production is cheaper and contributors have less shared context. - ✅ Where exactly does AI's effectiveness in programming break down?
At the boundary between solving known problems under fixed assumptions and generalizing under changing constraints — roughly between levels 2 and 3. - ⭕ Will the opportunity created by cheaper code production actually be realized?
Acknowledged as uncertain — lower costs could equally lead to more throwaway code without design gains.
Gaps
- incompleteThe four-level taxonomy is presented as self-evident without empirical grounding, prior art references (beyond Engelbart), or criteria for distinguishing the levels in practice. It is unclear whether the levels are discrete, overlapping, or a continuum, and what determines when a system transitions from one level to another.
Read next: Compare with established taxonomies: Lehman's laws of software evolution, the Cynefin framework, or Conway's law literature for more rigorous level-distinction criteria. - incompleteThe claim that AI-generated code characteristically fails at higher levels is asserted as an observed pattern but supported only by a brief characterization ('works in isolation, fails when inputs vary'). No specific examples, studies, or failure cases are cited.
Read next: Look for empirical studies on AI-generated code in production systems, e.g., GitHub Copilot studies, or case analyses of AI-generated code failures in integration contexts. - incompleteThe article does not address the possibility that AI capabilities at higher levels could improve significantly. The boundary between levels 2 and 3 is treated as if it were a stable, inherent limitation rather than a current snapshot of AI capability.
Read next: Follow research on AI agents for multi-component system design, autonomous software engineering agents, and LLM-based architecture reasoning. - incompleteAmundsen argues the opportunity to 'get better at getting better' exists but immediately hedges that it may not be realized. No mechanisms, incentives, or conditions for realizing it are discussed.
Read next: Engelbart's original 'Augmenting Human Intellect' framework, and organizational learning literature (Argyris, Senge) for conditions under which meta-improvement actually occurs.
Closes gaps elsewhere
- Elizabeth Ayer on Mastodon — "The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know" · g3 — Resolves Ayer's scope ambiguity with an articulated position: code production was never the constraint (p1), and AI's effect is to compress the lower levels while exposing the higher-level constraints (p3), i.e. both never-was and constraint-shift are true at different levels.
Related documents
- CannotMeasureProductivity
- 11) AI-spesial med Vilde Opsal og Anders Sveen
- What good software looks like at REA
- The "funhouse mirror": How AI reflects the hidden truths of your software pipeline
- Applying Best Simple System for Now for Software Design
- Beyond Autonomous Teams in Software Product Development
- Code maintainability plummets in the AI coding era
- We Studied 150 Developers Using AI (Here's What's Actually Changed...)
- Podcast: Formal Methods for Every Engineer in an AI-Powered Future
- Fragments: July 6