Bliki: Vibe Coding

Martin Fowler · rss · 2026-05-21 source ↗ Reader 🖥️

Agent Harness Agentic Engineering Agile & XP Code Quality Disposable vs. Durable Code Lethal Trifecta LLM Limitations Malleable Software Riding Model Improvements Vibe Coding

Vibe coding — building software by prompting an LLM without ever looking at the generated code — is a distinct practice from agentic programming, useful only for disposable software, because forgetting the code exists produces serious risks in security, maintainability, and correctness.

practical · expository — A bliki definitional entry. Practical because its ultimate purpose is to guide action: how readers should use vibe coding (only for disposable software) and how they should talk about it (don't conflate with agentic programming). Expository in form — Fowler defines a term, distinguishes it from a neighbouring concept, and enumerates risks — rather than constructing a sustained argumentative case.

Structure

Part	Role
Opening definition paragraph	Establishes the working definition and its scope (best for disposable software)
Karpathy attribution and quoted X post	Provides the etymological anchor and shows the originator's own framing ('forget that the code even exists', 'throwaway weekend projects')
Distinction from Agentic Programming (linking to NovemberInflection and SemanticDiffusion)	Conceptual disambiguation — the load-bearing move of the post
Who it suits (non-programmers; experienced programmers for prototypes)	Scopes the legitimate use cases
Limitations and risks: security (Lethal Trifecta), code quality / maintainability, hallucination and non-determinism	Evidence for the constraint that vibe coding is unsuitable for serious software
Concluding prescription: disposable software only; consequential code 'should not be forgotten about'	Practical recommendation

Key terms

Vibe coding Vibe Coding
Building software by prompting an LLM and iterating on the result *without ever reading the generated code*. The defining feature is 'forgetting the code exists.'
Agentic Programming Agentic Engineering
Letting an LLM (often an agent) write most or all of the code, but the human still cares about the code: reviews it, attends to its internal structure.
Semantic Diffusion Agile & XP
Fowler's own coined process by which a term's precise original meaning is diluted as it spreads through wider usage.
November Inflection Riding Model Improvements
Fowler's label for the moment (late 2024) when LLM-driven coding crossed a usefulness threshold for serious programmers.
Lethal Trifecta Lethal Trifecta
A specific class of agentic-AI security vulnerability (linked, not redefined here); invoked as the canonical risk non-programmers must understand.
Harnesses Agent Harness
The surrounding tooling/scaffolding around an LLM that shapes what it can do (linked to his harness-engineering article).
Disposable software Malleable Software
Software built for a limited audience (often just the author or a small group) where low quality, weak maintainability, and accepted risk are tolerable.

Propositions

explicitVibe coding is defined by the practice of not looking at the generated code.conf: high
explicit⚡ disputed & corroboratedVibe coding and agentic programming are categorically different practices.conf: high
contradictsVibe coding and agentic engineering are getting closer than I'd like · p1 — Fowler insists vibe coding and agentic programming are categorically distinct, against Willison's report that they are converging in his own practice.
supports ←SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p11 — Balakrishnan's 'vibe coding vs vibe engineering' burn-line reinforces Fowler's insistence that vibe coding and disciplined agentic engineering are categorically different practices.
explicitAndrej Karpathy coined the term in February 2025.conf: high
explicitVibe coding lowers the skill threshold for building software to the point that non-programmers can do it.conf: high
explicitestablishedVibe-coded software is appropriate only for disposable use.conf: high
refinesA model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code · p4 — Fowler converts the robustness-gap risk for vibe coders into a scoping rule: vibe-coded software is acceptable only for disposable use.
supports ←Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile · p7 — Kim's sawzall warning and Fowler's 'vibe-coded software is appropriate only for disposable use' make the same risk argument from different corpus entry points — both insist on keeping Karpathy's original, narrow meaning intact against production drift.
supports ←How AI will change software engineering – with Martin Fowler · p2 — Both sources state, independently, that vibe-coded software is only appropriate for disposable/throwaway use — this video restates Fowler's own bliki position in his own words.
explicitdevelopedSecurity is the most serious risk of vibe coding.conf: high
extends ←Fragments: July 21 · p5 — Adds a concrete infrastructure-level mitigation (isolated infrastructure plus deterministic data-access controls to defuse the lethal trifecta) to the earlier general claim that security is vibe coding's most serious risk.
refines ←Looking back at the Future of Software Engineering unconference · p10 — Specifies the concrete mechanism behind vibe coding's security risk: vendor tools can't safely reach production data/APIs, so static data gets embedded, bypassing access control or leaking it — pointing to platform-level data guardrails as the fix.
explicitWell-structured code makes LLMs more effective, not less needed.conf: high
supports11) AI-spesial med Vilde Opsal og Anders Sveen · p4 — Fowler's claim that well-structured code makes LLMs more effective matches the Heis argument that information architecture becomes more important, not less, under code agents.
explicitLLM non-determinism means edits can introduce regressions in unrelated parts of the code.conf: high
supportsLLMs Corrupt Your Documents When You Delegate · p7 — Non-deterministic edits introducing regressions in unrelated code matches the sparse-but-severe, silently compounding error finding.
explicitConceptual hygiene — keeping vibe coding and agentic programming distinct — is worth defending against popular usage.conf: high
implicitThe category 'disposable software' is stable and identifiable in advance.conf: high
implicit⚡ disputed & corroboratedReading code is the mechanism that produces accountability for its quality, security, and correctness.conf: high
contradictsPodcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p9 — Fowler argues reading code is the very mechanism that produces accountability for quality and security, contradicting the prediction that dropping code review is inevitable progress.
extends ←How AI will change software engineering – with Martin Fowler · p3 — The bliki post says reading code produces accountability; this video supplies the mechanism (Unmesh Joshi's 'learning loop') for why skipping that reading specifically forecloses future tweakability, not just accountability.
contradicts ←What's an Orchestrator—and Why Does Software Need One? · p11 — O'Brien claims shipping without reading every line is compatible with genuine accountability if you understand the system well enough to debug it; Fowler's piece holds that reading the code is specifically the mechanism that produces accountability for its quality, security and correctness.
supports ←Who cleans up after the vibe-coding party? · p3 — The influx of AI-generated OSS contributions from people 'sometimes without the ability to understand the output' is a real-world accountability breakdown exactly where Fowler's claim predicts it -- reading code is what produces accountability, and these contributors never read it.
implicitThe risks of vibe coding scale with code lifetime, audience size, and data sensitivity — not with code volume per se.conf: medium
refines13) Tobias K. Torrissen om kodekvalitet, konferanser og AI · p16 — Fowler turns Torrissen's discrete quality modes into continuous scaling dimensions: risk grows with code lifetime, audience size, and data sensitivity, not with code volume.
explicitLimitations of vibe coding are a moving target tied to model and harness capability.conf: high
implicitFuture LLM capability gains will not eliminate the value of structured code for LLM consumption.conf: medium

Arguments

Vibe coding is a distinct practice from agentic programming and the distinction is worth preserving. strength: high

Explicit premises:

Vibe coding's defining feature is forgetting the code exists.
Many programmers now have LLMs write all their code but still review it and attend to its structure.
Those two practices are different to use and different in their consequences.

Implicit premises:

Distinctions in practice that produce different consequences deserve distinct terms.
Semantic Diffusion is a real and corrosive force on technical vocabulary.

Inferences:

Discourse about 'AI coding' that fails to make this distinction will produce muddled empirical claims (e.g. about productivity, quality, risk).
Studies of 'vibe coding' productivity that include code-reviewing developers are not measuring vibe coding.

Vibe coding should be confined to disposable software. strength: high

Explicit premises:

Vibe coding produces security risks (Lethal Trifecta, credential exposure).
It produces large volumes of low-quality code that is hard to evolve.
LLM hallucination produces subtly incorrect behaviour.
LLM non-determinism causes regressions even in unchanged areas.

Implicit premises:

The cost of these risks is acceptable when the software's blast radius is limited to its author or a close group.
Authors of vibe-coded software can correctly anticipate their software's eventual blast radius.

Inferences:

Vibe coding is a poor fit for any software that touches credentials, customer data, or regulated environments.
Tooling or social practices that prevent vibe-coded software from escaping its disposable context would meaningfully reduce its risks.

Well-structured software remains valuable in an LLM-heavy world. strength: medium

Explicit premises:

Vibed code is hard for LLMs to modify and enhance later.
Empirically, well-structured code currently makes life easier for LLMs too.

Implicit premises:

Human and LLM consumers of code share enough cognitive constraints that structures helpful to humans are also helpful to LLMs.
Today's empirical pattern is a reasonable predictor of the near-term future.

Inferences:

Investments in code structure and design discipline are not made obsolete by capable LLMs.
Engineering leadership that defends design quality has a continued, possibly amplified, role.

Narratives

Karpathy's X post: he talks to Cursor Composer via SuperWhisper, 'Accepts All' without reading diffs, copy-pastes error messages back to the model, lets the code grow beyond his comprehension, and treats the whole thing as amusing weekend play.
→ Both attributes the term and instantiates its defining attitude — a working programmer demonstrating that vibe coding is play, not professional practice. It silently supports the proposition that vibe coding is only fit for throwaway work, because the originator himself frames it that way.

Questions addressed

✅ What does 'vibe coding' actually mean?
It is building software by prompting an LLM without looking at the generated code; the operative phrase is 'forget that the code even exists.'
✅ How is vibe coding different from other forms of AI-assisted coding?
Agentic programming retains human attention to the code; vibe coding abandons it. The consequences differ accordingly.
✅ When is vibe coding appropriate?
For disposable software used by the author or a close group who understand and accept the risks.
✅ What are the dominant risks?
Security (esp. Lethal Trifecta), maintainability collapse, hallucinated incorrect behaviour, non-deterministic regressions on edits.
⭕ How does an author know up front that their software will remain disposable?
⭕ What organisational practices or guardrails should constrain vibe coding inside a real engineering org?
⭕ What happens when vibe coding is done by someone with no programming knowledge but the resulting tool quietly becomes load-bearing for a team or business?

Gaps

incompleteFowler offers no mechanism for detecting when 'disposable' software is silently graduating into consequential software. The disposable/consequential boundary is treated as legible to the author, but in practice it is one of the most common failure modes in software organisations — internal scripts becoming critical infrastructure.
Read next: Cutler on institutional overload and shadow systems; classic discussions of 'tactical' vs 'strategic' programming (Ousterhout, Philosophy of Software Design); literature on shadow IT and end-user computing.
incompleteThe piece is silent on team and organisational implications. It treats vibe coding as a relationship between one author and one LLM. But the most consequential question for an engineering leader is what vibe coding does to teams that mix it with agentic programming: shared codebases, code review norms, ownership.
Read next: Kent Beck's recent writing on AI and design discipline; Gene Kim's vibe coding series; Steve Yegge's manifesto; DORA's 2025 AI findings.
closed byTrust Factory — Beck addresses the team/organizational dimension Fowler leaves out: single-player augmented development erodes trust across four vectors, and trust is the binding agent current AI-coding methodology debates ignore.
incompleteNo discussion of what 'forgetting the code exists' does to the author's mental model and learning trajectory. For non-programmers it bypasses learning entirely; for experienced programmers used routinely it may atrophy the skills that allow agentic programming to be done responsibly.
Read next: Literature on automation complacency, skill decay (e.g. aviation HCI); also writings on AI's effect on programmer cognition (Marcus, Karpathy himself in other settings).
closed byPresentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — Supplies the automation-complacency and skill-decay evidence the gap's reading direction requests: manual and diagnostic skills deteriorate when unused, capability induces complacency, and mental models erode faster than AI generates code.
incompleteThe security treatment is gestural — pointing at the Lethal Trifecta — and does not address the asymmetry that non-programmers, the very population vibe coding most empowers, are least equipped to recognise security trifectas in their own systems.
Read next: Simon Willison on prompt injection and lethal trifectas; agentic-AI security taxonomies; end-user security literature.
closed byFragments: July 21 — Addresses the flagged asymmetry (that non-programmer citizen developers are least equipped to recognize or manage the lethal trifecta themselves) by describing a mitigation that removes the burden from them entirely: deterministic infrastructure-level access controls that protect vibe-coded apps regardless of the developer's own security awareness.
incompleteNo engagement with the cultural/professional question of whether vibe coding deserves the name 'coding' at all, or whether legitimising it as a coding practice (rather than, say, 'spec-driven prototyping') invites exactly the diffusion problem Fowler is trying to push back against.
Read next: Naur on programming as theory building; the broader 'what is programming' debate that has resurfaced post-LLM.

Closes gaps elsewhere

13) Tobias K. Torrissen om kodekvalitet, konferanser og AI · g4 — Provides the distinction Torrissen's camp-3 taxonomy conflates: vibe coding (never looking at the code, appropriate only for disposable software) is categorically different from professional agentic programming (p1, p2, p5).

Bliki: Vibe Coding

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents