Vibe Coding Is Dead. I Know Because I’m Still Living the Hangover.

Hello, this is S.

I build an app called 観 (Kan) — a CBT and Buddhist philosophy tool — from a small town in Shimane Prefecture, Japan. No team. No office. Just me, Claude Code, and a lot of trial and error.

For most of 2025, I was vibe coding. I would describe what I wanted, accept the output, move on. The UI came together faster than I had any right to expect. I felt like I had discovered a superpower.

Then I hit the backend.

The code that had felt magical started to feel like a house I had decorated but never actually inspected. The walls looked fine. I had no idea what was in them.

That experience is, apparently, universal. And Andrej Karpathy — the person who named the feeling — just announced it’s over.

What vibe coding actually was

On February 2, 2025, Karpathy posted a description of a new way of working with AI. He called it vibe coding: “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He described accepting all diffs without reading them, copy-pasting error messages without comment, working around bugs he couldn’t fix by asking for random changes until they disappeared.

He was describing a real thing millions of developers had started doing. Merriam-Webster listed it as a trending expression within weeks. Collins English Dictionary named it Word of the Year for 2025. Y Combinator reported that 25% of its Winter 2025 batch had codebases that were 95% AI-generated.

The party was real.

What happened when the party ended

By late 2025, the data was coming in:

CodeRabbit’s analysis of 470 open-source GitHub pull requests found AI co-authored code contained 1.7 times more major issues than human-written code — logic errors, security vulnerabilities (2.74x higher), misconfigurations (75% more common). Veracode’s 2025 report found 45% of AI-generated code contains security vulnerabilities.

A January 2026 paper titled “Vibe Coding Kills Open Source” argued that the approach reduces user engagement with maintainers, hollowing out the open-source ecosystem that vibe coding depends on.

And then there was the maintainability problem nobody talked about enough: vibe-coded projects become what developers started calling “black boxes” — code that looks fine from the outside, works initially, and becomes increasingly impossible to debug or extend as it grows. Forrester analyst Andrew Cornwall described it cleanly: “Vibe coding is great for prototypes but not wonderful for brownfield or production code.”

I felt this directly. The 観 app’s UI is manageable. The backend and database integration remain the main challenge — not because the technology is hard, but because I had accumulated layers of generated code I didn’t fully understand, and each new addition created new unexpected interactions.

That’s the vibe coding hangover. You don’t feel it while you’re building. You feel it when something breaks three files away from where you were looking.

Karpathy’s one-year update

On February 4, 2026 — exactly one year after his original post — Karpathy wrote a retrospective. He admitted the vibe coding tweet was “a shower of thoughts throwaway tweet that I just fired off.” He hadn’t expected it to define a year of developer culture.

More importantly, he proposed a new term: agentic engineering.

His reasoning: “Today, programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny.” The new default is that you are not writing code directly 99% of the time — you are orchestrating agents who do, while acting as oversight. “Engineering” is in the name deliberately. There is art, science, and expertise to it. It is something you can learn and improve at.

The distinction matters. Vibe coding was about surrendering control. Agentic engineering is about wielding it at a higher level of abstraction. You are no longer the person typing code. You are the person who designs the system, specifies the requirements, reviews the output, and decides what gets merged.

Simon Willison, co-creator of Django, drew the clearest line: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding — that’s using an LLM as a typing assistant.”

That framing redeems a lot of what developers have been doing. The problem was never using AI. The problem was the “forget the code exists” part.

What changed in my workflow

I did not stop using Claude Code. I use it more than ever. What changed is my relationship to the output.

I now read the diffs. Not all of them in full detail — that would be slower than writing the code myself — but I read enough to understand the structure of what was added. If I cannot explain to myself what a file does and why, I do not accept it.

I write specifications before I prompt. Not elaborate documents — a few sentences that force me to think through the architecture before asking an AI to implement it. The act of writing the spec catches half the problems before any code is generated.

I treat context management as a skill. Long sessions accumulate noise. I have started splitting work into phases — a planning session with no code, an implementation session with only relevant files loaded — because I noticed output quality degraded when the context became cluttered.

None of this is heroic. It is just the basic engineering discipline that vibe coding’s original framing encouraged people to skip. Adding it back does not make the work slower. It makes the output usable beyond the first demo.

What this means for 2026

Forrester Research analyst Diego Lo Giudice wrote in Q4 2024 — more than a year before Karpathy’s update — that “vibe coding will transform into vibe engineering by the end of 2026.” He was right on schedule.

The developers who will do well in this transition are not the ones who were best at vibe coding. They are the ones who understand systems well enough to direct agents toward correct, maintainable software. The new bottleneck is not generating code. It is understanding what happens when that code runs in production.

Spiros Xanthos, CEO of Resolve AI, put it well: “The bottleneck isn’t generating code anymore. It’s understanding what’s happening when that code breaks.”

That is a skill that rewards engineering fundamentals — architecture thinking, systems understanding, the ability to read and reason about code you did not write. The developers who skipped those fundamentals during the vibe coding peak are going to find the transition harder.

From rural Japan, I can tell you the transition is uncomfortable and necessary. The app I am building now is slower to develop than it was in the peak vibe coding period. It is also, for the first time, something I could actually maintain.

That trade-off is the whole point.

I write about AI tools and building in public from rural Japan. If your company builds developer tools and wants to reach this audience, reach out: oliverblackwood717@gmail.com

note.com/oliver_wood | medium.com/@johnpascualkumar077