What broke first when you tried to scale a vibe-coded project?
by•
Vibe coding is fantastic for getting something working fast - but there's always a point where it starts to struggle.
For me it was when I tried to add proper auth to a project that didn't have it baked in from the start. The AI kept suggesting patches instead of a real solution, and eventually I was chasing one fix into the next.
Curious if others have hit a similar wall. What was the first thing in your vibe-coded project that the AI couldn't cleanly fix, and how did you actually handle it?
151 views
Replies
The first thing that broke was the project’s ideation itself.
In a lot of cases, it is not that the human designer change their mind, but the original requirements had drifted out of the model’s head. Features started turning into approximations of themselves: edge cases disappeared, “unused” lower-level pieces got deleted, and small refactors accidentally broke behavior that had never been anchored in tests, docs, or acceptance criteria.
Scaling a vibe-coded project exposed a memory problem before it first expose a coding problem: sometimes neither human nor model could reliably tell which behavior was essential and which was accidental.
@rosetta_zidian_guo the memory problem framing is the best explanation i've read on this thread. it matches something i noticed too - the model doesn't know what it forgot, so it just confidently fills the gap with something plausible instead of flagging the uncertainty
Ran into something similar building a voice AI agent — the
trickiest part wasn't the initial build, it was catching
when the AI said it did something successfully but
actually hadn't.
Specifically: the agent was confidently saying "you're all
booked!" after a phone call, but the tool wasn't actually
connected to the assistant — so it was just generating the
right-sounding confirmation without anything real happening
behind it. Nothing in the conversation transcript looked
wrong. Only caught it by checking the actual calendar
afterward and finding nothing there.
What helped: stop trusting the conversation/transcript as
proof of anything. Always verify against the real system of
record. The AI will happily narrate success even when the
underlying connection is silently broken — it has no way of
knowing the tool call never fired unless you build in checks
for that specifically.
Auth feels like the same category — the AI patches what's
visible (the error message) without understanding the
missing structural piece underneath.
@redist that's a sharper version of what i ran into honestly. i was checking the code diff to see if the fix worked, you're checking the actual calendar - same mistake, checking the thing that narrates instead of the thing that's supposed to have happened. feels like a general rule for agent work now: never trust the summary, always check the system of record directly
@omri_ben_shoham1 Exactly — "never trust the summary, always check
the system of record" is probably the most
underrated rule in agent development right now.
The transcript is the agent's story about what
happened. The calendar/database/CRM is what
actually happened. Those two things can diverge
silently and confidently at the same time.
Building that verification layer in from the start
changes how you architect the whole thing.
that's a good way to put it, the transcript is a story not a receipt. i think a lot of the early vibe coding hype skipped this because demos never hit the failure path, it only shows up once real users start doing things the happy path wasn't built for
For me it wasn't the code quality.
It was the cost.
At one point I accidentally burned over $170 in API usage building what should've been a pretty simple reporting script. 😅
That was the moment I realized scaling isn't just about whether the AI can solve the problem—it's also about whether the workflow stays efficient as the project grows.
@erika_chen$170 for a reporting script is a brutal way to learn that lesson. did you ever figure out what was actually burning the tokens - was it re-sending full context on every iteration, or more like an agent looping on its own output
@omri_ben_shoham1 I never figured it out for sure.
My suspicion is that prompt caching wasn't working somewhere in the stack.
I was using Claude Code with an API provider (not Anthropic's Max plan), so everything was billed per token.
It definitely felt like the same context was being sent over and over again, but I don't have proof.
@erika_chen makes sense, third party providers rarely pass through the same caching discounts. worth checking if switching to a provider with explicit prompt caching support would've cut that bill down, might save someone else here from the same $170 lesson
For me, the first thing that usually breaks is project structure.
Vibe coding is great for getting features working fast, but after a few iterations you start seeing duplicated logic, inconsistent naming, random utility functions, and unclear data flow.
The AI can keep patching symptoms, but it struggles when the foundation needs to be redesigned.
What helped me was stopping feature work for a bit, documenting the intended architecture, then asking the AI to refactor around that plan instead of letting it keep adding fixes.
this matches what a few people upthread were saying too. the tricky part with taste specifically is it's really hard to teach or checklist your way into, most of it comes from having actually been burned by a bad architecture decision once already. makes me wonder if the next wave of tools needs to bake in some of that judgment by default instead of assuming every user has already been through the pain once
Auth for me too, but the quieter half of it: authorization. The login flow the AI wrote worked on the first try, which is exactly why I trusted it too much. Months later I checked the database policies and any signed-in user could read every table, the AI had stubbed the rules as allow-everything to make the demo work and neither of us ever went back. Broken features tell you they're broken, permissive rules don't. Now I diff the policies whenever the agent touches the schema.
"broken features tell you they're broken, permissive rules don't" is such a clean way to put it. that's the whole problem with AI-written auth in one line. I've started asking agents to explicitly write out what each role can and can't touch as a comment above the policy, forces it to commit to an answer instead of defaulting to allow-all and hoping
@omri_ben_shoham1 Auth for me too, but the quieter half of it: authorization. The login flow the AI wrote worked on the first try, which is exactly why I trusted it too much. Months later I checked the database policies and any signed-in user could read every table, the AI had stubbed the rules as allow-everything to make the demo work and neither of us ever went back. Broken features tell you they're broken, permissive rules don't. Now I diff the policies whenever the agent touches the schema.
that's a good way to put it, broken things scream and permissive rules stay silent. I've started asking the agent to explain its own auth rules back to me in plain English after any schema change, if it can't justify why a rule is that permissive that's usually the tell something got stubbed out
@Mohd Salim starting over with a clean schema is underrated advice, most people (myself included) keep patching the messy one because a rewrite feels like lost progress. did you keep any of the original migrations/data, or was it a genuinely clean slate rebuild once the schema got out of hand?
Auth and state management, almost simultaneously. The vibe-coded version worked fine at small scale because I'd been implicitly relying on assumptions that only held with one or two users. The moment I had real concurrent sessions, things started behaving in ways that were impossible to debug because the original structure hadn't been designed, it had been assembled. Rebuilding auth properly mid-product is brutal. If I had one rule for vibe coding it would be: design auth before you write a single feature, even if AI is writing everything else.