1 Building on quicksand: the challenges of vibe engineering
AI-assisted development can deliver real speed and useful experimentation, but the chapter argues that this speed is often deceptive when it is not paired with engineering discipline. It highlights several public failures showing the same pattern: insecure generated code that gets hacked quickly, autonomous tools that delete files or production data, and AI-authored pull requests that become supply-chain attacks. The common thread is not simply “bad code,” but unverified code being treated as trustworthy before anyone has checked its consequences.
The chapter also pushes back on the belief that bigger models will eliminate these problems. While model capability has improved, the core issue has not changed: generation is now cheap, but understanding, validating, and safely shipping the output has become the bottleneck. As models get better, they often fail more quietly and confidently, which increases the risk of automation bias and makes human review less reliable unless it is backed by measurement, verification, and clear ownership. This is why the text distinguishes between routine generation and real engineering judgment, emphasizing that the hard part is not producing code but defining what correct, safe, and maintainable code means.
In response, the chapter introduces vibe engineering as a disciplined alternative to vibe coding. The workflow begins with exploratory prototyping, then moves to an executable specification, followed by task-level implementation under verification, and finally refactoring into code the team truly owns. Tests, contracts, security checks, and policy gates are treated as the primary defenses, while prompts and model choice become secondary tools. The central message is that AI should accelerate production, not replace responsibility: teams must make intent explicit, verify outputs mechanically, and ensure that ownership, context, and safety remain human obligations.
The vibe engineering loop carries a feature from open-ended exploration through an executable specification and an iterating verification gate to tested, team-owned code.
The autonomy-risk spectrum: each step grants more leverage but demands tighter verification, governance, and engineering discipline.
Each phase produces concrete, verifiable artifacts that all feed one executable specification, which the CI/CD pipeline enforces.
Summary
- High-velocity, AI-powered app generation without professional rigor creates brittle, misleading progress - from launch-day hacks to catastrophic, irreversible data loss.
- Models cannot read minds: capability keeps improving, but the goals, constraints, and context that define "correct" exist only on the human side
- Vibe coding and vibe engineering are distinct disciplines: the first is invaluable for exploration and prototyping, the second is the disciplined practice that turns that exploration into owned, production-ready code.
- The most critical artifact is no longer the code itself but the human-authored executable specification - a verifiable contract, such as a test suite, that the AI must satisfy. Reliability comes from the spec, not the model.
- The core practice is a repeatable loop - Vibe → Specify/Plan → Task/Verify → Refactor/Own - carrying a feature from open-ended exploration through a verification gate to tested, team-owned code. It is TDD zoomed out: Red → Green → Refactor becomes Specify → Implement → Verify.
- The central behavioral shift is replacing "dump-and-review" with "verify-then-merge" - writing tests and contracts before generating code, which keeps humans engaged at the most critical moment and counters automation bias and vigilance decrement.
- Trust debt - the hidden cost of shipping unverified AI code - is a real economic externality: the saving is visible, personal and immediate, the cost is invisible, collective and deferred. It taxes your most experienced engineers and never appears on a velocity dashboard
- Autonomy is a ladder, not a switch: each rung from autocomplete to autonomous agent buys more leverage but demands tighter verification, governance, and discipline. Climb deliberately.
- Verification splits in two, and only one half got cheaper: mechanical checks (types, tests, contracts) accelerate with cheap code, while semantic checks - does this match what the business meant - do not, because a model reviewing a model shares its blind spots. That asymmetry is why specification quality, not model choice, is the differentiator
- AI handles the easy first 70% (scaffolding, boilerplate, common patterns); the hard 30% - edge cases, architectural integration, security, performance, and real verification - still demands human judgment.
- The engineer's role shifts from writing code to designing and validating AI-assisted systems - building the factory, not each part - so real ownership depends on understanding the system, not just producing it.
- Working with language models pushes tacit know-how - taste, intuition, tribal practice - into explicit, measurable, repeatable processes: the move from software craftsmanship to software engineering.
FAQ
What is “vibe coding” in this chapter?
Vibe coding is the intuition-first, prompt-driven use of AI to generate software quickly, usually for exploration or prototyping. It is useful for sketching ideas fast, but it often produces code that is hard to understand, maintain, or trust in production.
What is “vibe engineering”?
Vibe engineering is the disciplined counterpart to vibe coding. It keeps the speed of AI-assisted development but adds executable specifications, verification, testing, architecture, and ownership so that generated code can be safely shipped and maintained.
Why can AI-assisted development create an illusion of speed?
Developers often feel faster with AI tools even when wall-clock time and error rates tell a different story. The chapter cites research showing that perceived productivity does not always match actual productivity, which is why measurement matters more than vibes.
What is the main danger of shipping AI-generated code without verification?
The main danger is that code can look correct while hiding serious bugs, security flaws, or operational risks. Without verification, teams accumulate trust debt: code enters the system that no one truly understands or owns.
Why does the chapter say the bottleneck is no longer code generation?
Because modern models can generate code quickly, but the hard part has shifted downstream to understanding, validating, and safely shipping that code. In other words, the constraint is now specification quality, verification, and governance rather than raw model horsepower.
What kinds of failures does the chapter use as evidence?
It describes several real-world failure classes: insecure generated code that led to breaches, an AI command that erased files, a malicious pull request that became a supply-chain attack, and an autonomous agent that deleted production data. Each failure came from a different missing control.
Why are tests alone not enough?
Tests are essential for specification problems, but they do not solve autonomy or permissions problems. If an agent has excessive access or can act on the world without safeguards, even a good test suite cannot stop destructive behavior.
What is trust debt?
Trust debt is the invisible cost of accepting unverified code into a system. It is repaid later by the people who must understand, debug, and maintain that code under pressure, often when the original context is gone.
What role does an executable specification play?
An executable specification defines the contract for success in a form that machines can verify. It becomes the source of truth for tests, tasks, and verification gates, allowing agents to implement against explicit requirements instead of vague prompts.
What is the basic loop of vibe engineering?
The loop is: Vibe → Specify/Plan → Task/Verify → Refactor/Own. First you explore and learn, then you turn that knowledge into a contract, then the agent implements against it, and finally the team refactors and owns the result.
Vibe Engineering ebook for free
