The first prompt is magic. The second one breaks it.
This is the limit nobody warns you about. You describe an app, the AI builds something genuinely good, and then your very first edit, the second prompt, quietly wrecks it. The layout you liked is gone, a working button stopped working, and the version you wanted back does not seem to exist anymore. It is not a skill issue and it is not your prompt. It is what the second prompt does under the hood.
Direct answer
The second prompt usually triggers a fresh regeneration of the whole project instead of a targeted edit. A non-deterministic model rebuilds from scratch, so the parts you liked shift or vanish, and most one-shot tools keep no exact copy of the working draft to fall back to. The fix is not a better prompt. It is a builder that snapshots version one before the second prompt runs, so a bad edit is one reversible step away from the exact first draft.
In mk0r that snapshot is automatic: every turn is committed to a real git repo inside the sandbox, and undo is a git checkout, not a re-prompt. Verified against the source on 2026-05-21.
What is actually happening at turn two
The thing that makes the first prompt feel like magic is the same thing that makes the second one fragile. On turn one the model has a clean slate. It picks a structure, commits to a few decisions, and writes a self-consistent draft. Those decisions, which component holds which state, how the data is shaped, what the edge cases are, mostly live in the session, not in obvious comments in the code.
On turn two you say something small: make the header sticky, add a dark mode, change the streak color to red. Many builders treat your prompt list as the source of truth and re-roll the entire project from it. That regeneration throws away the implicit decisions from turn one and re-derives them, differently. The blast radius of a one-line request is the whole app. This is why a tiny edit can rename your files, reorder your layout, and resurrect a bug you fixed in your head an hour ago.
People online describe this as logic drift or entropy that accumulates over a long session. True, but it does not need a long session to bite. It bites hardest at turn two, because turn two is the first time the model has to reconcile a new instruction with a draft it would not rebuild the same way twice. The second iteration is the highest-variance single moment in the whole loop.
The second-prompt cliff, frame by frame
Turn one lands
The mechanism: your first prompt becomes a commit message
Here is the part you can verify. In mk0r, the moment the agent finishes a turn, the chat route commits whatever files changed. The commit message is the first line of your prompt, sliced to 120 characters. So your version history reads like your prompt history, and version one exists as a named commit before the second prompt ever runs. This is in src/app/api/chat/route.ts.
Under that call, in src/core/e2b.ts, the SHA is pushed onto session.historyStack and an activeIndex pointer tracks where you are. Undo is not a re-prompt. It checks out the previous SHA on disk and is byte-for-byte exact:
The browser reaches this through /api/chat/undo for one step back, and /api/chat/revert (which calls jumpToSha) to land on any version in the stack. The model never sees the undo, so there is no token cost and no chance of a different result. That is the whole point: an undo that re-prompts gives you something similar to v1, a git checkout gives you v1.
What to do the moment the second prompt breaks your app
Stop. Do not prompt your way out
The instinct is to type a third prompt to fix the second one. Resist it. A fix-prompt is another re-roll on an already-drifted project, and you compound the variance instead of removing it.
Revert to the last good version
Go back to the commit whose message is your first prompt. In mk0r that is one click, a git checkout under the hood, and the disk returns to the exact v1. No tokens spent, no surprises.
Make the second prompt smaller and more specific
Name the one thing you want changed and the things you want left alone. A narrow instruction gives the model less reason to re-derive the parts that were already right.
Branch if you are unsure
Try edit A, revert to v1, try edit B, then keep the winner. Because each turn is a real commit, comparing two second-prompts is just jumping between two SHAs.
Why most builders cannot just add this
The reason the second-prompt cliff is so common is that most builders never put your project on a real filesystem. The app lives in browser memory or in a transcript of prompts, so there is nothing concrete to snapshot. Their undo has to replay the prompt list and ask the model to produce the project again, which is exactly the operation that loses your first draft in the first place. Undo and the bug are the same mechanism.
mk0r runs the agent inside one persistent session against a real working directory at /app in an isolated sandbox. Files are edited on disk, not regenerated from a prompt list, and each turn is sealed with a commit. That is what makes a byte-exact revert possible. It is an architecture choice, not a feature you can bolt onto a transcript-based tool after the fact.
None of this requires you to know git, run a terminal, or set anything up. You see a list of versions labeled with your own prompts and a way to step back. The version control is doing the heavy lifting; you just describe and revert.
Test the second prompt yourself
Build something with one sentence, then make your first edit and break it on purpose. The revert that brings back the exact first draft is the whole point. No account, no setup.
Build an app at mk0r.comStuck deciding if your idea survives the iteration loop?
Walk me through what you are building and I will tell you honestly whether vibe coding holds up for it or where it will outgrow the envelope.
Second-prompt questions, answered
Why does the second AI prompt break my app when the first one worked?
Because the second prompt usually triggers a fresh regeneration of the whole project, not a surgical edit. The first prompt produced a clean, self-consistent draft. The second prompt feeds both prompts back to a non-deterministic model and asks for the app again. The model re-rolls file structure, renames things, drops the layout you liked, and reintroduces bugs you never had. Nothing about your second instruction was wrong. The tool just rebuilt instead of edited, and most one-shot builders keep no exact copy of the first version to fall back to.
Is this the same thing as the vibe coding iteration wall everyone talks about?
It is the very first instance of it. The iteration wall is usually described as something that arrives around turn ten or twenty after a project drifts into entropy. The second-prompt cliff is the same mechanism showing up at turn two, the earliest possible moment, because the model has nothing to anchor to except your two prompts. If you want the full taxonomy of what goes wrong over a long session, the iteration wall guide breaks it into four separate failure modes. This page is only about the first edit.
What is the actual fix? Better prompting?
Better prompting helps at the margin, but it does not solve the structural problem, which is that a re-roll is non-deterministic. The structural fix is a tool that snapshots your first draft before the second prompt runs, so a bad edit is reversible to the exact bytes of v1 at zero cost. mk0r does this automatically: every turn is committed to a real git repo inside the sandbox, and undo is a git checkout, not a re-prompt. You get the working draft back without the model touching it.
How does mk0r checkpoint my first draft exactly?
After the agent finishes the first turn, the chat route at src/app/api/chat/route.ts runs commitTurn(sessionKey, msg), where msg is the first line of your prompt sliced to 120 characters. That writes a real git commit inside /app in the sandbox and streams a { type: 'version', sha, message } event back to the browser. The SHA is pushed onto session.historyStack and an activeIndex pointer is set to the tail. So before your second prompt ever executes, v1 already exists as a named commit whose message is literally your first instruction.
When I undo the second prompt, do I get the exact first version or an approximation?
Exact. undoTurn in src/core/e2b.ts reads historyStack[activeIndex - 1] and runs git checkout <sha> -- . inside the sandbox, then stages and writes a fresh commit. The disk is byte-for-byte identical to the previous turn. The model is never consulted, so there is zero variance and zero token cost. This is the difference that matters: an undo that re-prompts gives you a different app that is merely similar to v1, while a git checkout gives you v1.
What if I revert to v1, try a different second prompt, and want to compare?
Every turn lives in the history stack, so you can jump between them. /api/chat/revert calls jumpToSha(sessionKey, sha), which checks out any commit you point it at and moves the active pointer. Practically, you draft, branch off v1 with idea A, revert to v1, branch off with idea B, and pick the winner. When you commit a new turn while the pointer is not at the tail, the stack is sliced at activeIndex + 1 so the abandoned branch does not haunt you later, exactly the way an editor's undo history behaves.
Does this work in the no-account, no-setup version, or do I need to sign up?
It works with no account. Open mk0r.com, type your first prompt, and you are an anonymous identity with a session key in localStorage. The sandbox is provisioned on the first prompt, and every turn writes a commit to a private repo tied to that identity. The whole second-prompt safety net runs before you have created any account, which is what zero friction means here. Signing in later just attaches the same session so it survives a device change.
Where does this approach stop helping?
Reversible iteration fixes the second-prompt cliff, but it does not change what the generated app can be. If your idea genuinely needs production-grade auth, multi-user real-time state, payments, or complex data invariants, you will outgrow generated HTML/CSS/JS or a Vite plus React project regardless of how clean the iteration loop is. The honest exit point is when the requirements outgrow the envelope, not when the second prompt feels scary. If iteration is the only thing breaking, the fix is mechanical: revert to the known-good version and make a smaller, more specific edit.
The longer arc of the same problem
Keep reading
The vibe coding iteration wall is four walls, not one
The long-session version of this problem, broken into four distinct failure modes with the file path that defuses each.
Iterate, don't one-shot
Why building up over many small prompts beats trying to specify the whole app in one giant prompt.
Where vibe coding hits its limits: state and auth
The boundary past which generated apps need real persistence and login, and how to tell you have crossed it.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.