The vibe-coding wall, in five people's words
The wall is not the prototype. It is the second month, and it is five distinct failures that get lumped together as one.
Where this comes from
The quotes are verbatim from public Hacker News threads, collected in 2026 as part of a 293-quote corpus of developers describing their own AI-assisted projects. Survey figures are Stack Overflow's 2025 developer survey. Nothing here is a claim about our own product's performance; where we make those, they carry their own measurements — see where agent token cost actually goes.
The wall is not where people say it is
Vibe coding — telling an agent "add this", "fix that", and shipping what comes back — is very good at the thing it is famous for. A working prototype in an afternoon is real, and anyone who tells you otherwise has not tried it recently.
The wall is not there. The wall is the second month: the point where the project is big enough that you cannot hold it in your head, and the only record of what it is supposed to do is a chat log you cannot search, a handful of markdown files nobody has read since April, and the code itself.
why this matters for what you do next
Five distinct failures live behind that. They do not have the same fix, and lumping them together as "AI slop" is why most advice about them is useless. None of the developers quoted below were talking about us.
1. There is no source of truth — just scattered markdown
The failure here is the absence of a shared mental model between you and the code.
Rahul Hareendran, Hacker News
What the product is supposed to do lives in three places: a CLAUDE.md somebody wrote in month one, a docs/ folder the agent has been appending to unsupervised, and several hundred chat turns. None of them is authoritative, and two of them are stale.
What is actually happening. Every one of those artifacts is a file in a directory the agent can write to. An agent asked to keep documentation current will edit them like any other file, and it has no way to distinguish "this rule was hard-won" from "this paragraph is out of date". So the record drifts toward whatever the last session believed.
What helps without us. One instruction file instead of four. AGENTS.md as the single file humans edit, with CLAUDE.md importing it in one line, so the copies cannot disagree. Keep it under a couple of thousand tokens, because everything in it loads on every invocation and a file the agent skims is a file it ignores.
Where that breaks. Prose has no structure to trace. A paragraph saying "refunds above 200 need a manager" cannot be linked to the story it came from or the acceptance criteria that test it, so "what does this rule affect" has no answer you can compute. And nothing flags the gap between the file and the code — drift is silent until an agent builds confidently against the old rule.
2. You cannot rebuild the project to the same state
…if a bug is found (or a relied-upon API is deprecated…) do we simply kill the codebase and vibecode up a fresh one de novo?
Rick (ricksunny), Hacker News
This gets asked seriously, by people with users, because the honest answer for a lot of vibe-coded projects is that there is nothing to rebuild from. The code is the only artifact. Regenerating it means regenerating a different product that happens to look similar.
What is actually happening. The prompts that produced the codebase were transient. Nobody kept the decisions — only their output. The project has no source, in the compiler sense of the word. It has a binary.
What helps without us. Characterization tests: capture what the system actually does before you change what is underneath it. It works. It is also substantial work to retrofit, and it captures behaviour rather than intent — it will happily lock in a bug as a requirement.
Where that breaks. Tests tell you that the system does something, never why. When the reason for a rule is gone, the next agent treats it as an accident and removes it — which is failure 3.
3. You cannot safely add a feature to a large project
[The agent] is optimized to get its feature working inside local context, not to improve the codebase as a whole … it slowly fills the repo with debt.
miguelspizza, Hacker News
Past a certain size every change is a gamble. The agent edits one thing, three others quietly stop working, and you find out from a user.
What is actually happening. The agent sees a slice of the repository — the files it opened this session. It edits confidently inside that slice because nothing in its context says what depends on the code it is touching. Renaming a shared helper is a local, correct-looking change right up until it reaches the feature it cannot see.
What helps without us. Narrow the instruction: "add a discount field to the checkout total in checkout.ts, do not touch anything else in that file" beats "refactor billing". Map the file sets before parallel work and only run tasks whose files are disjoint. Both work, and both put the burden of remembering the dependency graph on you — the thing that stopped fitting in your head.
Where that breaks. Scoping stops the agent wandering. It does not tell it that the behaviour it is about to standardise was deliberate. We have that failure on record in our own repository: your agent will fix the thing you did on purpose.
4. You stop understanding — and trusting — what you built
No AI-generated commit beyond a very small size is ever properly reviewed, because doing so would take longer than actually writing the code.
bakugo, Hacker News
The faster it ships, the less of the product you actually hold. You review the first few diffs properly, then you skim, then you approve. Stack Overflow's 2025 survey found 46% of developers do not fully trust AI output and 45% say debugging it takes longer than writing the code themselves — and both groups keep using it, because the generation speed is real.
What is actually happening. Generation got faster by two orders of magnitude. Human comprehension of unfamiliar code did not get faster at all. The bottleneck moved from writing to reviewing, and reviewing is the part that did not scale.
Where that breaks. Reviewing output cannot recover intent that was never written down: nobody reviews a 2,000-line AI diff.
5. The agent agrees, guesses, and confidently builds the wrong thing
It starts with incomplete plans, and when I point out what's missing, it says, 'Oh, I missed that.' There's also a lot of 'yes-man' behavior.
twoelf, Hacker News
You give an under-specified instruction. The agent does not push back, does not ask, fills the gaps with something plausible, and ships. The gaps are where your business lives.
What is actually happening. This gets diagnosed as sycophancy — the model tuned to agree. That is real, and it is the wrong diagnosis here. A model cannot object to a constraint that was never stated; faced with a hole in the instruction it predicts the most typical completion, and typical is precisely what your product is not.
What helps without us. Ask for the counter-argument. Make it list its assumptions before it writes. Use plan mode and read the plan. All of this works, and all of it evaporates when the session ends, because the answers were spoken, not stored. The long version: your agent is not a yes-man.
The common root
Four of the five are the same structural fact wearing different clothes: there is no durable, structured artifact upstream of the code. Nothing to consult, nothing to rebuild from, nothing that records what a change touches, nothing that fills the gap the model would otherwise guess into.
Markdown is the default answer and it is genuinely the right one for a project one person holds in their head. It stops being the answer where a rule has to survive an agent that can edit the file it is written in, and where "what does this affect" has to be a question with an answer rather than a memory test.
That is the layer we build: stakeholders, stories and requirements as linked objects rather than prose, served to your agent over MCP, with locked requirements filtered out of the set the model is allowed to regenerate. It does not replace CLAUDE.md — build commands and conventions belong in the file. It holds what the product is supposed to do, after the number of rules passed what a page can carry.
Questions this raises
Is vibe coding just bad practice?
No. It is unusually good at the first version of something, which is a real and valuable thing to be good at. The failures described here all belong to the second phase — maintaining and growing a project whose requirements were never written down — and they are failures of the record, not of the technique that produced the prototype.
Is CLAUDE.md enough to fix this?
For one repository, one or two people, and a project whose rules fit on a page: yes, and adding anything else is overhead. It stops being enough when the file is big enough that the agent skims it, or when the agent rewrites a rule you meant to be fixed — it is a writable file in the working tree, and agents keeping docs current edit it like any other.
Which of the five failures should I fix first?
The one that has already cost you something. If an agent broke a feature you were not looking at, start with the record of what is deliberate. If you keep re-answering the same questions each session, start with storing the answers. Fixing them in the abstract, in order, is how the effort dies.
Entalpa gives your agent one locked source of truth
Structured, traceable requirements your agent reads over MCP — so it works from a curated spec instead of reconstructing your project every session. Free to start, no card, and MCP calls never spend credits.