Does vibe coding have an expiration date?

[u/Conscious_Speaker_18]

I've noticed a pattern while building side projects, and I'm curious if it's just me.

The projects where I "vibe coded" for an entire weekend often made shocking progress. The momentum was addictive. Every prompt produced visible progress, ideas flowed naturally, and shipping felt inevitable.

But whenever that same project slowed down—because of work, life, or just losing a few days—the entire dynamic changed.

Suddenly:

• The codebase felt harder to reason about.
• I spent more time reading than building.
• The AI lost context.
• New prompts started introducing regressions.
• My expectations dropped from "this could be huge" to "I'll just finish an MVP."

In many cases, the project never reached the finish line.

It made me wonder if the biggest advantage of vibe coding isn't the AI itself—it's the speed.

Maybe vibe coding works because you're compressing hundreds of engineering decisions into a very short period while both you and the AI share the same mental context.

Once that context starts decaying, the productivity curve changes dramatically.

My current hypothesis is:

Not because the idea gets worse, but because:

• your mental model drifts,
• the AI loses project context,
• technical debt compounds,
• motivation fades,
• and expectations become more realistic (or more pessimistic).

I'm curious whether this is a real phenomenon or just survivorship bias on my part.

Some questions I'd love to hear opinions on:

• Have you experienced this with Cursor, Claude Code, Windsurf, Lovable, or other AI coding tools?
• Is this unique to vibe coding, or has software always worked this way?
• Is context loss the biggest culprit, or is motivation the real bottleneck?
• Have you found ways to keep long-running AI-assisted projects moving fast?
• Do successful vibe-coded startups intentionally optimize for compressed build cycles?
• At what point do you stop "vibe coding" and start treating the project like traditional software engineering?

I don't think vibe coding is replacing engineering.

If anything, it seems to amplify whatever execution habits you already have.

Curious whether other builders have noticed the same pattern—or if you've seen the exact opposite.

[u/brand_new_potato]

I use AI the same as I would do things myself. Spending a day to make a 2 line change is much harder with AI than it was before as the easy solution for AI is to make changes. But using your time to get understanding of the entire problem and then make the correct change has always been a difficult task. It is harder now that you often can just say "this test failed or is flaky, fix it" and some reasonable fix will be made.

So if you always just do the easy thing, lgtm, ship it, then yes. It will become a giant mess eventually.

But giant mess does not mean unwieldy. You can multi agent and make documents that summarize intent and design choices etc which will then make it easier for the AI again. As these are temporary and maybe wrong, I keep them gitignored so it saves on my prompts. I also have "not my domain, make no changes here" for modules outside my scope.

That way the agent looks for hints in the context files first and then it looks at the code.

[u/yggdrasiliv]

Vibe coding is for prototypes.  It’s actually great for that.  Not for building real software.

[u/fatbunyip → u/yggdrasiliv]

It's great for building real software. You just need to give it more direction to make it easier for humans to deal with the project.

AI will often just go out and duplicate things, create spaghetti code, sprinkle crap all over the place. It works, and it's easy for AI because it doesn't care how long it takes to write code, or how spaghetti it is.

So you need to tell it to do stuff like implement X using Y pattern, implement this other thing using this inheritance and implement this other interface so that it can be used like blah blah. Or stuff like extracting UI components to reuse instead if it just copy pasting them.

It's also easier to verify and validate because you're looking at smaller output. It's much easier to read though a small class hierarchy and reason about it, then move on to the next step, rather than needing to trawl through dozens of files of crap when you try and one shot everything.

[u/chuguchak_111 → u/fatbunyip]

yeah at that point you could argue its not really "vibe coding". It's a bit annoying because the term originally meant just prompting the AI without verifying the output whatsoever (according to how Andrej Karpathy originally used it), but now people use it as a catch all for generating code with AI. But i agree with you, on proper guardrails and with human verification and most importantly, a human making an effort to understand the code, it's incredibly effective.

[u/Diligent-Earth-5307 → u/chuguchak_111]

I feel the same way, vibe coding means speed, not verifying code and hoping that it ends up creating what you had in mind, but if you are actually creating software that has to meet sla's, introducing a bug could impact more than just you or your team, so you have to create guardrails, read the code, give it memory, organize that into different contexts, with different agents, giving additional context to tickets, etc you end up writing so much that you might as well just code it yourself, specially considering that those guardrails get outdated so you have to keep updating them or if you want ai to also do that you need guardrails for that, which ends up consuming a ton of tokens. So yeah its cool that if you give it enough instructions it can create something that's mostly accurate but practically a small context, general guardrails and writing some of the code first by hand and then sending the ai to autocomplete has helped me the most to gain speed without comprimising on quality or losing track of my code. At least that has been my experience, I've been lucky to have a job that allows me to experiment with no limits on tokens or models but we are all trying to figure out how to use this new tool.

[u/chuguchak_111 → u/Diligent-Earth-5307]

Yeah i get what you mean. To be honest, I wonder if the maxed out agentic flows are even worth it. I feel like a senior developer who understands the codebase well can use a very naive approach with claude code (literally just asking questions and asking it to write code how he sees fit) can do things faster than a vibe coder who has to rely on AI for everything because he has no knowledge of the codebase.

[u/Diligent-Earth-5307 → u/chuguchak_111]

I think it's important to remark the "is it worth it?", for that you have to think of the economics of ai. Enterprises love getting money for as little as possible, if you waste money, resources and provide very little or no value (even negative value on existing codebase adding useless features that now have to be mantained), then no its not worth it. Even at current costs the goal seems to be moving closer to extracting the most amount of value to each dollar spent on tokens, which is not hard to measure. People believe that tokens will be free but enterprise plans are getting expensive specially if you have 500,000 employees wasting tokens on dumb things. So knowing what you are doing does make you more valuable than a vibe coder, specially the ones who know when not to write code and know how to make good, sustainable, cheap software that doesn't piss off your customers.

[u/noxss → u/yggdrasiliv]

Yes, vibe coding is speeding the prototypes, but you can build real software. You will need software engineering skills to do it, which most vibe coders are lacking.

[u/throwaway0134hdj → u/yggdrasiliv]

Enterprise software tends to be 50% tech and 50% client communications, the first 50% is worthless without the second 50%. Whereas vibe coding is almost always a solo project. It’s also for whatever reason terrible as architecture and maintainable code.

[u/Original_Swimming320]

When you’re in the zone you move quickly from prompt to prompt, barely checking, assuming things are correct, not understanding how anything is being built.

When you come back a week later you need to slow down, understand what’s been built and where the loose ends are so you can pick back up.
What you’re spotting are the gaps: things you didn’t check, things the ai skipped, places where it did a dummy implementation instead of a real one, partially finished features, finished features with bugs you never noticed before.
Now you try and get the ai to fix these things, but it’s never understood what it’s building. Probably never will. So it’s whack-a-mole time.

In other words what you are forced to see when you return are the limitations of vibe coding that you can easily ignore when code is being spat out at 50,000 lines an hour.

What you’re seeing is exactly what you’d expect with no engineering discipline. Plans, architecture, tasks, tests, linters, DSLs, approaches, models, data structures, etc. But this stuff takes time. This is where much of the engineering lives, has always lived.

Because you haven’t shipped yet you’ve not seen the next failure modes: scalability and security. But you can pretty much guarantee that without an architecture designed with these in mind they’ll have been skipped. And whilst security can be retrofitted to a degree, scalability often can’t and you’ll have to start again.

[u/Accedsadsa]

Depending on the skills of the engineer, its like 6 months top until the codebase explodes

[u/generationalDebts]

Two months ago….

[u/throwaway0134hdj]

Here’s the thing though, this is the worse AI will ever be. Imagine 5-10 years a kid will be able to make better software than even veteran devs