There is a trend going around X right now called “Developers Debate Vibe Coding’s Role in Real Software.” Reading through it felt like watching the same argument that has been running since Andrej Karpathy first coined the term in February 2025 Karpathy’s original post described giving in to the flow of the model and no longer worrying about the code underneath it. About a year later he revisited the idea and started calling the more disciplined version “agentic engineering” instead. , just with more people piling on. Everyone has a take. Almost nobody disagrees on the actual facts underneath it.
One line from the thread stuck with me more than the rest: “nobody vibe-codes a kernel, or a compiler, or a database.” Everything people actually show off is a SaaS app or a landing page, and whoever wrote that wanted to know why the practice always stops exactly where the engineering gets genuinely hard.
That is a fair question, and I don’t think the honest answer is “because those systems are just harder.” Plenty of SaaS apps are hard too. I think the real answer is economics, and there is a blog post that explains it better than any tweet in that thread. Anton Morgunov wrote an essay called “Vibe coding killed Cursor” that apparently made Hacker News lose its mind for a day, and his argument is mechanical, not philosophical. Every time you send another small prompt to fix an icon or rename a variable, the model isn’t just reading your new sentence, it’s re-reading the entire conversation so far. Ask for ten small tweaks and you are reprocessing a growing wall of context ten separate times, for edits a human could type by hand faster than they could describe in English. On a landing page that’s wasteful but survivable. On a kernel, a compiler, or a distributed system, the amount of context you’d need to hold in one prompt to make even a small change safely is enormous, so every one of those tiny vibe-coded fixes gets slower, pricier, and more likely to quietly break something three files away that the model never looked at. Vibe coding doesn’t stop at hard engineering because the model gets scared. It stops there because the token bill and the failure rate blow up at the same time.
That same mechanic is a big part of why Cursor’s pricing has been such a mess this year, something I already ranted about in an earlier post. Charging one flat price a month while the actual usage pattern is “keep re-prompting small edits until it looks right” was never going to hold up.
Karpathy himself has basically already agreed with the critics, just in nicer language. About a year after coining “vibe coding,” he called it passé and started pushing a new term, agentic engineering, which is really just vibe coding with the guardrails critics were asking for the whole time: stay in the loop, read every diff, treat the model like a fast junior developer instead of a lottery ticket. That’s not a rebrand for its own sake. That’s the person who started the trend conceding the production argument roughly a year after half of X told him so.
| Vibe coding | Agentic engineering | |
|---|---|---|
| Goal | Something working, fast | Something working, and still yours to maintain |
| You review | Rarely, if ever | Every diff, every dependency |
| Fits | Prototypes, weekend builds, throwaway demos | Anything more than one person will ever touch |
| What breaks first | Nothing, until it suddenly does | Your patience, before your production |
Someone else in the thread compared it to managing a person: you can’t hand off an objective, disappear for six months, come back, and expect to understand everything that happened while you were gone. Their point was that AI works the same way. You have to stay involved, keep asking what it built and why, and keep arguing about the architecture instead of vanishing until the output looks done. That is basically the whole debate in one sentence. Vibe coding doesn’t fail because the model is bad. It fails once the person steering it checks out.
There was also a genuinely interesting counterpoint buried in the thread, that non-technical but creative people are already shipping better products faster than a chunk of engineers, because being vague works in their favor now, while an engineer’s instinct to over-specify the prompt drags the output down. I’m not fully sold, but I think there’s something real in there. A model with enough taste behind it doesn’t need someone micromanaging every line, it needs someone with a clear picture of what “good” looks like for the end user. That’s a different skill from writing code, and not every engineer actually has it.
If you want the version of this argument that isn’t trying to win an internet fight, this account of someone’s first real attempt at vibe coding is worth five minutes. No manifesto, no “this changes everything.” Just an honest log of typing more English than they would have typed code, losing context between chats over and over, what they call the “50 first dates problem,” and eventually hitting a bug they couldn’t precisely describe in natural language because natural language was never built for that job. That’s the actual experience for most people trying this on something bigger than a form. Not doom, not magic. Just friction the hype cycle usually skips over.
My own take, for what it’s worth: I use vibe coding for exactly what it’s good at, throwaway scripts, quick UI mockups, testing an idea before committing to building it properly. The moment something needs to survive real users or a second developer, I go back to reading every line, the same way I’d review a junior’s pull request. That’s not me being precious about code, it’s that debugging something you never understood in the first place ends up costing more time than writing it carefully would have. The “vibe coding is tech debt” crowd from the thread basically has this right. Debt isn’t automatically bad, it’s a loan, and loans are fine as long as you know you took one out and plan to pay it back. The failure mode is forgetting you’re in debt at all.
Vibe coding isn’t going anywhere, and I don’t think it should. It made a rough version of an idea cheap enough for non-engineers to build, and that’s genuinely good. I just don’t think “is it the future” is the right question anymore. The better question the thread kept dancing around is future of what, exactly. Future of prototyping, probably already true. Future of shipping and maintaining real systems, only if someone stays in the loop the whole time, reads the diffs, and knows when to stop trusting the vibes.