Andrej Karpathy coined "vibe coding" in early 2025 as a half-joke: lean back, talk to the model, accept the diffs, ship it. Eighteen months later it's a workflow, a vibe (literally), and for a non-trivial slice of new software being shipped right now, the dominant way the first version gets written. We use it daily at CruxBit. We also clean up after it. Here's the take we'd give a friend over coffee in 2026 — minus the hype on both sides.
The honest summary
Vibe coding is incredible for the first 70%. It quietly falls apart on the last 30% — exactly the part that decides whether something becomes a product or a graveyard repo. Know which 70 you're in.
What vibe coding actually means in 2026
The 2025 definition was "accept the diff without reading it." The 2026 reality is broader: a conversational, low-friction loop with an agent (Cursor, Claude Code, Windsurf, Zed, Devin) where you describe what you want in plain English, the agent edits files, runs commands and tests, and you steer with feedback rather than typing implementation. Sometimes you read the diff carefully. Sometimes you don't. The vibe is: prompt > type.
That shift in posture matters. You're no longer the bottleneck on keystrokes. You're the bottleneck on judgement — what to build, what trade-offs to make, when to stop.
Where vibe coding genuinely wins
- Prototypes and spikes — getting from idea to a clickable thing in an afternoon, instead of a week
- Throwaway scripts and one-off automations — exactly the work that used to be too small to bother with
- Unfamiliar territory — a new framework, a new language, a new API. The agent reads the docs for you and writes idiomatic code while you learn by reading what came back
- UI iteration — moving pixels, swapping layouts, trying three variants of a card design in twenty minutes
- Glue code — adapters, transformers, the boring 200-line file between two services
If your work this week falls into one of those buckets, vibe coding is probably the right tool and you should feel zero guilt about it. We've built entire client demos start-to-finish this way, and clients have signed contracts off them.
Where it quietly bites
- 1Long-lived production systems. The first commit is fine; commit fifty is a stylistic mess from twenty conversations. Architectural drift is the silent killer
- 2Security-sensitive code. Auth, crypto, anything touching PII. The model writes plausible-looking code that's subtly wrong in ways a hurried reviewer won't catch
- 3Performance hotspots. Idiomatic ≠ fast. The model defaults to clear, generic code — usually right, occasionally a 50x regression on the path that runs a million times a day
- 4Cross-cutting concerns. Logging, metrics, error handling, retry policies. Vibe-coded versions are locally fine and globally inconsistent — every file does it slightly differently
- 5Data migrations and one-way doors. The cost of "accept and see what breaks" goes from low to existential the moment production state is involved
Smell test
If the worst-case outcome of a wrong diff is "tests go red and I retry," vibe-code freely. If the worst-case is "customer data is corrupted" or "we ship a security bug," slow down and read every line.
The traps nobody tweets about
Trap 1: Skill atrophy
Six months of pure vibe coding and engineers notice it — they can still describe what they want, but the muscle memory for writing it from scratch has softened. For senior engineers that's fine, they have the depth to recover anytime. For juniors learning the craft, it's a real concern. Our recommendation for early-career devs: half your week is hands-on, half is agent-assisted. Don't skip the foundation.
Trap 2: The 90% trap
Vibe coding gets a feature to "works on the happy path" faster than you've ever built one. The remaining 10% — edge cases, error states, accessibility, weird inputs, the third browser — takes as long as it always did, sometimes longer because you've lost context on the code you didn't write. Budget for it. The total project time is not 10x faster, even though the first demo is.
Trap 3: Codebase entropy
Without a strong style guide and a sharp reviewer, vibe-coded codebases drift into inconsistency fast. Two files implementing the same thing three different ways. Helpers re-invented in five places. The agent can't fix what it can't see across sessions. The fix isn't to stop vibe coding — it's to maintain a tight repo-wide AGENTS.md or CLAUDE.md and to actually enforce it in PR review.
Trap 4: Loss of authorship
When a bug shows up six weeks later, "I don't remember writing this" is a real and growing experience. git blame points at you. You can't reconstruct why. The mitigation is small but disciplined: leave a one-line comment for non-obvious choices, link the chat or commit message to the [[spec-driven-development-with-ai-2026|spec]] that drove the change, and never merge something you couldn't explain to a teammate cold.
The rules we follow at CruxBit
- 1Vibe-code freely on prototypes, spikes, and anything throwaway
- 2Spec-driven for production work — see [[spec-driven-development-with-ai-2026|the spec-driven post]] for the actual loop
- 3Always read the diff before merging to a shared branch, even if you didn't type it
- 4Tests are not optional just because the agent wrote them — read them, run them, and trust them only when they're assertive about something meaningful
- 5Security, auth, payments, migrations: hand-write or hand-review line by line. No exceptions
- 6Keep a repo-level AGENTS.md / CLAUDE.md and update it when the agent gets things wrong twice the same way
Vibe coding for non-engineers
A real and growing slice of vibe coders aren't professional engineers — they're founders, designers, PMs, analysts, students. For that audience the question is different: when is the output good enough to use, and when does it need a real engineer's eyes? Our rough heuristic: if the thing is for you alone (your dashboard, your script, your weekend tool), ship it. If it touches a customer, takes money, stores their data, or you'd be embarrassed if it broke publicly, get a second pair of eyes on it. The cost of being wrong is asymmetric.
TL;DR
- Vibe coding in 2026 = conversational, agent-driven dev loop. Default tool for prototypes and small work
- Genuinely great for spikes, glue code, unfamiliar tech, UI iteration
- Quietly bad for long-lived systems, security, performance hotspots, cross-cutting concerns, migrations
- The 90% trap is real — first demo is 10x faster, full ship is not
- Codebase entropy is the long-term cost. Repo-level agent rules mitigate it
- For production work, graduate to [[spec-driven-development-with-ai-2026|spec-driven development]]
- If you're a non-engineer: ship for yourself freely, get review before customers touch it
If you're vibe-coding something that's about to meet real users — or you've already shipped one and the cracks are starting to show — drop us a line. We'll send back a candid, no-pressure take on whether the right next step is a rewrite, a tightening, or just a few sharp reviewers.