Where vibe coding hours actually go

The shape you expect vs the shape it is

The demo version of vibe coding is one sentence and one app. The lived version has a long tail. Toggle these to see the difference between the pitch and the practice.

We counted a real week

mk0r keeps a record of the prompts people send. We pulled seven days of it into scripts/recent-user-prompts.json: 280 prompts from 65 separate build sessions. Group those prompts by session and the picture is blunt. The first prompt of a session is the build. Everything after it is iteration.

65 of those 280 prompts were first builds, one per session. The other 215 were follow-ups. That is the headline: for every minute spent describing the app, roughly three more go into shaping it afterward. 37% of sessions stopped after a single prompt, but the median session that kept going took a handful of turns, and the longest one ran 45 prompts on a single app.

What those 215 follow-up prompts were

Reading the actual text of every non-first prompt, the hours sort into five buckets. The largest is not what most guides warn you about. It is not grand architecture. It is the small, repetitive work of getting v1 to match what was in your head.

Two thirds of the loop is fixing and refining. People paste an error, describe a layout that drifted, or say a version of "closer, but the X is still wrong." This is the real cost of vibe coding, and no first prompt removes it. The skill is making each pass cheap.

The first prompt is the cheap part

Generation is fast because the model is good at turning a sentence into a plausible app. Convergence is slow because only you know whether the result is the app you meant. The loop below is where a build session actually lives. Step one happens once. Steps three through five repeat until it is right.

External research lands on the same shape. A widely cited 2025 study measured experienced developers using AI assistance and found they were slower than without it, even though they predicted the opposite. The time did not vanish. It moved out of writing and into reviewing and correcting. Vibe coding does not dodge that. It just makes each correction a sentence instead of a diff.

Why mk0r treats every prompt as a commit

If 77% of the work is the loop, the tool should be built around the loop. mk0r is. Every prompt you send runs through commitTurn in src/core/e2b.ts: the agent's file edits are staged and committed to a git repo inside the sandbox, and the new commit SHA is pushed onto a history stack.

That one design choice is what makes the iteration loop cheap. Because each turn is a real commit, undoTurn, redoTurn, and jumpToSha are exact operations, not best-effort guesses. A turn that made things worse is one step back to the last good version, byte for byte. You never have to re-describe an app from scratch to escape a bad turn. The loop you spend 77% of your time in has an undo button, and that button is real version control, not a memory trick.

How to spend the iteration hours well

You cannot delete the loop. You can make every pass through it cost less. Four habits, drawn straight from the prompts that converged fastest in the log:

1. One change per turn

   A turn that asks for five things gives you five things to verify and no clean version to roll back to. Small turns converge faster than big ones.

2. Describe the symptom, not the stack trace

   "The submit button does nothing on tap" converges faster than 200 lines of pasted console output. Give the model the observation, let it find the cause.

3. Undo instead of arguing

   When a turn goes sideways, step back to the last good version and re-describe from there. Three rounds of "no, not like that" is slower than one undo.

4. Front-load the first prompt

   Name the audience, the core screens, and the visual feel up front. It will not remove the loop, but it lands v1 closer to your intent and saves a few correction rounds.

Common questions