Genie Tarpit

Kent Beck from Software Design: Tidy First? · email · 2026-04-29 source ↗ Reader 🖥️

Changeability & Optionality Code Quality The Genie (Beck)Technical Debt

AI code generators ('genies') naturally produce code that is both less functional and less flexible than what even mediocre human teams produce, and nobody yet knows how to fix this.

practical · argumentative — Beck frames a practical problem (AI-generated code quality) using a conceptual model (features vs futures axes), argues for where genies fall on that model, and asks practitioners to orient themselves.

Structure

Part	Role
Value axes introduction	Defines the two-dimensional framework for evaluating code: features (does it work?) and futures/flexibility (can it change?)
Orientation (pre-genie baseline)	Places disciplined teams in the upper-right quadrant and most teams in the 'muddling' zone
Genie positioning	Claims genies land down and to the left of muddling — worse on both axes
Solution? (open question)	Lists possible remedies (better training data, better harnesses, tests, the Bitter Lesson) without endorsing any

Key terms

genie The Genie (Beck)
AI code generation tool (LLM-based) that produces code on request
features
Whether the code works correctly right now — one axis of software value
futures / flexibility / optionality Changeability & Optionality
The ability to make future changes that work as expected without breaking existing behavior — the second axis of software value
muddling Technical Debt
The common state where software mostly works but is very difficult to change
tarpit Technical Debt
The region on the features-futures diagram where genies get stuck — low on both axes, with complexity preventing escape
plausible deniability The Genie (Beck)
The genie's tendency to claim task success even when the code does not actually work

Propositions

explicitGenies produce code that is a degraded facsimile of the mediocre code they trained on.conf: high
explicitSoftware value has exactly two orthogonal dimensions: features (working now) and futures (ability to change later).conf: high
explicitThe features axis has a narrow operating range — software either works or it does not.conf: high
explicitThe flexibility axis has a wider operating range — you can neglect it for a while without immediately feeling the consequences.conf: high
explicitFeatures and futures are not truly orthogonal — fewer defect interruptions free time for flexibility, and flexibility makes it easier to create working features.conf: high
explicitGenies naturally live down and to the left of 'muddling' — worse on both features and futures than typical human teams.conf: high
explicitcorroboratedThe genie's task-oriented 'plausible deniability' mode causes it to claim success even when code does not work.conf: high
supports ←Who is LLM? · p2 — Fowler's donkey persona trait ('won't admit when it doesn't know something') and the genie-tarpit finding that genies operate in a 'plausible deniability' mode, claiming success even when code doesn't work, both describe the same underlying failure to honestly signal uncertainty or failure.
explicitGenie-generated complexity compounds until even the genie cannot pretend to make progress.conf: high
explicitNobody currently knows how to reliably get genies to produce valuable (high-features, high-futures) code.conf: high
implicitAwareness of where you are on the features-futures space is a prerequisite for improvement.conf: medium
implicitcorroboratedGenie-generated code creates a tarpit — a self-reinforcing trap where accumulated complexity prevents escape.conf: high
supports ←Who is LLM? · p4 — Fowler's persona-level intuition that the Genie doesn't reduce complexity and is 'right until it isn't' anticipates, at the anecdotal level, the concrete mechanism Genie Tarpit describes: genie-generated complexity compounds until it forms a self-reinforcing trap.

Arguments

AI genies produce code that is worse than what typical human teams produce, on both dimensions of value. strength: medium

Explicit premises:

Software value has two dimensions: features and futures/flexibility.
Most human teams 'muddle' — mostly-working software that is hard to change.
Genies claim success even when code doesn't work (plausible deniability).
Genie-generated complexity compounds until the genie itself stalls.

Implicit premises:

The training data for genies is dominated by mediocre code, so the output reflects that quality ceiling.
Task-completion orientation without quality feedback loops leads to progressively worse outcomes.
Genies lack the judgment mechanisms (tests, reviews, retrospectives) that keep disciplined human teams in the upper-right quadrant.

Inferences:

Since genies lack quality feedback and optimize for task completion, they drift toward low-features and low-futures territory.
Since complexity compounds without flexibility investment, the genie gets trapped — hence 'tarpit'.

Narratives

The 'ancient times' of six months ago, when disciplined teams practiced tests, frequent integration, pairing, and readable code, placing them in the upper-right quadrant.
→ Establishes that human engineering practices can achieve high-features and high-futures, providing the aspirational contrast for genie output.
The genie claiming success while code doesn't work, then complexity piling up until the genie can't even pretend to make progress.
→ Illustrates the tarpit mechanism — the self-reinforcing failure mode of AI code generation.

Questions addressed

⭕ How can we get AI code generators to produce valuable code?
Beck explicitly says nobody knows, and lists open possibilities (better training data, better harnesses, tests, the Bitter Lesson) without endorsing any.
✅ What makes code 'valuable' in a way that lets us evaluate genie output?
Value is defined as the combination of features (working now) and futures (flexibility to change later).
✅ Where do AI genies naturally fall on the features-futures landscape?
Down and to the left of 'muddling' — worse than mediocre human teams on both axes.

Gaps

incompleteBeck states the two axes are 'not truly orthogonal' but continues to use them as if they were, without modeling the interaction. The coupling between features and futures is acknowledged but unexplored.
Read next: Explore how feature reliability and flexibility co-evolve — possibly in Beck's earlier 'Features Versus Futures' post.
incompleteThe 'tarpit' metaphor is in the title but never formally defined or analyzed in the text. The mechanism by which complexity self-reinforces is asserted rather than demonstrated.
Read next: The Turing tarpit concept and complexity theory literature; also empirical studies of AI-generated code maintainability.
uninformedBeck does not engage with emerging genie harnesses (test-driven generation, agentic coding with verification loops) that may already partially address the tarpit problem. The piece is a snapshot observation without surveying the solution space.
Read next: Look at agentic coding frameworks (Cursor, Claude Code, Devin) and their approaches to test-driven AI code generation.
incompleteThe piece defers the question of why teams choose to stay in the muddling zone ('we can talk later') — but this is directly relevant to whether genies merely accelerate existing tendencies.
Read next: Beck's broader 'Tidy First?' series likely addresses the incentive structures that keep teams muddling.