Simon Willison on Vibe Engineering vs Vibe Coding in 2026

Simon Willison's distinction between vibe coding and vibe engineering is the clearest framing of AI-assisted development to emerge in 2026, and it explains why the same tools produce throwaway prototypes for some teams and shippable products for others. Vibe coding is what Karpathy named, accepting AI output without reading it. Vibe engineering is something different, using AI agents inside a disciplined development process that includes testing, code review, source control, planning, and a deep understanding of what is being built. Willison's argument is that vibe engineering is the actual practice that scales, and that conflating it with vibe coding has confused the industry.

This piece walks through Willison's framing, the practices he names as required for vibe engineering, and what the distinction means for teams trying to ship AI-assisted code into production.

Where the Distinction Came From

Willison's original post on vibe engineering was a response to a year of confusion. Karpathy had coined "vibe coding" in February 2025 to describe a casual mode of AI-assisted programming where you "fully give in to the vibes" and let the AI do whatever. The term went viral. Within months, every CTO was being asked whether their team did vibe coding, every founder was claiming their MVP was vibe coded, and every conference had a talk on whether vibe coding was the future.

The problem, Willison argued, was that the term covered both the throwaway weekend project and the serious team using AI agents to ship production code. Those are very different activities with very different success rates, and lumping them together produced bad decisions on both sides. Founders thought they could ship a SaaS by vibe coding, and engineering leaders dismissed all AI-assisted work because vibe coding looked irresponsible.

The pattern to copy is the early debate around test-driven development. TDD started as a fringe practice, became a religion for some, then settled into a useful tool inside a broader discipline. Vibe engineering is going through the same arc. The label is new, the underlying practices are not, and the value comes from combining them with AI rather than choosing between them.

What Willison Says Vibe Engineering Requires

Willison's writing on this is unusually concrete. He lists specific practices that distinguish vibe engineering from casual vibe coding. The list is small, but each item has weight.

Source control discipline. Every change goes through git, every meaningful change is its own commit, and you can always roll back. This is not optional. Vibe coding without source control is gambling.

Automated testing. AI is good at writing tests, and Willison's argument is that the bar for "shippable" should include tests that the AI helped write but that you also reviewed and reasoned about. He advocates for tests as the primary contract that makes AI output safe.

Written planning. Before generating code, write down what you want. Willison points out that AI agents perform substantially better when the prompt is structured around a written plan than when it is structured around a vague goal. He treats specs as executable artifacts.

Code review at speed. Every line of AI-generated code gets read before it merges. The review can be fast, but it cannot be skipped. The skill is reading 400 lines in 5 minutes and spotting the three things that matter.

Practices 5 Through 7 and Why They Compound

The remaining practices are slightly less obvious but are the ones that separate teams that ship AI-built products from teams that ship AI-built demos.

Observability. Once code is in production, you need to know what it is doing. Willison argues that vibe engineers invest heavily in logs, metrics, and traces because AI-generated code fails in subtler ways than human code, and you cannot rely on intuition to predict where it will break.

Deep understanding. This is the practice that distinguishes vibe engineering from vibe coding most clearly. Willison insists that you have to know what the code is doing, not just that it works. The goal is not to write less code but to understand more code per hour, because AI lets you read 5x more in the same time.

How Willison's Framing Plays Out in Practice

Reading Willison's posts and his interviews from 2025 and 2026, a consistent picture emerges of what a vibe engineer's day looks like. It is recognizably engineering. It just happens to use AI as the dominant input mode.

A vibe engineer starts the day by writing a short plan in markdown. They open Cursor or Claude Code, paste the plan, and ask for a first pass. They read the output, run the tests, find the gaps, ask for fixes, run the tests again. Once the feature is working locally, they review the diff in detail (often using a separate AI session to summarize what changed), commit it with a meaningful message, push, and watch the CI run. They look at the production logs after deploy. The whole cycle is faster than 2023, but it is still a cycle, not an open loop.

The contrast with vibe coding is sharp. A vibe coder skips the plan, accepts the first AI output, runs the app, sees it work, and ships. They skip the tests, skip the diff review, often skip the commit, and find out in production whether the code does what they think.

The second mistake is treating vibe engineering as a tool stack rather than a practice. There is no Cursor setting that turns vibe coding into vibe engineering. The difference is in what you do around the AI, not in which AI you use.

What This Means For You

Willison's framing gives engineering teams a vocabulary for the gap between the AI-assisted code that ships safely and the AI-assisted code that breaks production. Adopting it is a small move that pays off in better team conversations.

• If you're a founder: Ask your engineers whether they are vibe coding or vibe engineering on each project. Both are valid, the answer should match the stakes.
• If you're changing careers: Build the disciplines (tests, source control, planning) before you optimize the tools. Willison's order matters.
• If you're a student: Practice both modes on different projects. Vibe coding for learning, vibe engineering for portfolio pieces you want hiring managers to take seriously.