Small iterations beat big rewrites in vibe coding

Where the big rewrite habit comes from

The habit is baked into the original description of the practice. In a post on X, Andrej Karpathy described giving in to the vibes, accepting every suggestion, pasting error messages back in with no comment, and letting the code grow beyond his own comprehension. He was honest about the limits in the same breath: not too bad for throwaway weekend projects. If you work that way, scope grows by default, because there is nothing in the loop that forces a change to stop at a size you can hold in your head.

Karpathy has since revised the framing. As The New Stack reported, he described programming via LLM agents as an increasingly default professional workflow, but with more oversight and scrutiny, and offered a different label: agentic engineering, on the grounds that you are orchestrating agents rather than typing the code, and that there is skill in doing it well. Simon Willison landed on a parallel term, vibe engineering, separating the fast and loose end of the spectrum from professionals who accelerate their work with models while staying accountable for what they ship.

Both revisions point at the same lever. The difference between the two ends of that spectrum is mostly the size of the step you take between checks. Everything on what vibe coding is still applies; what changes is how much you let happen before you look.

The pull request evidence

The strongest argument for small steps is not a preference, it is what happens when agent output meets a reviewer. The empirical study On the Use of Agentic Coding: An Empirical Study of Pull Requests on GitHub found that “too large” sat among the three commonest rejection reasons. The mechanism the authors describe is unremarkable: large pull requests raise reviewer cognitive load, and a reviewer who cannot hold the change in their head rejects it or waves it through. Their recommendation to developers is blunt. Split large, multi-purpose pull requests into smaller submissions that are easy to review.

The cause sits on the prompting side. Agents given broad directives tend to produce comprehensive solutions that address several issues at once, because that is what a broad directive asks for. Analysis of failed agent pull requests shows the same shape from the other direction: failures correlate with larger change sets, more files touched and failing CI. One practitioner account of this describes a feature that should have needed changes in about three files arriving as a pull request that modified fourteen, with edits spread across layers the work did not require.

That is the real cost of the big rewrite. Not that the code is necessarily worse line by line, but that the unit of work has become too big to accept or reject with any confidence. You are left choosing between merging something you have not understood and throwing away an hour of generation.

Why long sessions get worse, not better

There is a second reason to keep steps small, and it is a property of the tools rather than of you. An agent works inside a context window, and during a session that window fills with files it has read, tool output and earlier messages. As it fills, output quality drops, because the model is weighing irrelevant context from ten steps ago against what you just asked for. The practical guide to stopping context rot in million-token coding agents cites degradation that begins early in a session and worsens as the context window fills.

This matters because a big rewrite is, by construction, a long session. You are asking the model to hold the whole shape of the change in the one place where its reliability is falling fastest. The mitigation is unglamorous: finish a unit of work, commit it, then start a fresh session for the next one so the context contains the current task and the files it needs rather than the archaeology of the last hour. The details of how context is assembled and spent are covered in how vibe coding works.

What one iteration actually looks like

A usable iteration has four parts, and they are the same four whether you are adding a form field or a payment flow.

• One outcome you can state in a sentence. If the sentence needs an “and”, you have two iterations.
• A check that can fail. A test, a route you load, a command you run. Something that distinguishes working from plausible.
• A diff you read. A change confined to the files you expected is the signal that the model understood the request.
• A commit. Small enough that reverting it costs nothing and loses nothing else.

The Painless Vibe-Coding guide puts the loop as vision, small step, check, stabilisation, and adds two details worth stealing. Ask for diff-only patches rather than rewrites of whole files, and settle your design conventions early so each step has something to conform to. Willison’s account of vibe engineering is stricter still on version control: every meaningful change is its own commit, so you can always roll back. Working without source control is not a lighter process, it is a bet that nothing will go wrong.

Tests earn their keep here more than anywhere else. Willison’s point is that models reward the engineering habits that were already good ideas: automated tests work well where a project has a thorough suite, and without one an agent may report success it never verified, or break an unrelated feature that nobody notices for a fortnight. Test-first suits agents that can iterate in a loop, because the loop then has a stopping condition that is not your patience. More of this sits under vibe coding best practices.

Iterate on the plan, not on the code

The most useful reframing of small steps is not about code size at all. Teresa Torres, writing on vibe coding best practices at Product Talk, describes always starting with a plan and iterating on the plan rather than in the code, with the agent as the thing she iterates with. Even with planning artefacts in place, she still works in small batches.

This is cheaper than it sounds. Revising a plan costs a few paragraphs; revising a generated implementation costs a review you have to do properly. It also gives the next prompt something concrete to carry, which is the difference between a model filling gaps with assumptions and a model following a spec. The structure that makes a prompt land, goal then context then constraints then an example, is set out in how to write a clear prompt for an AI coding tool.

A written plan is also what makes the small-step discipline survive a bad session. When output goes sideways, you rewind to the last commit and re-prompt from the plan rather than negotiating with an agent that has lost the thread.

When a rewrite is the right call

Incrementalism is a default, not a rule, and pretending otherwise produces its own failure. Some situations genuinely favour starting again.

The first is a throwaway prototype, which is exactly the case Karpathy allowed for. If the artefact exists to answer a question and will be deleted on Friday, the review overhead of small commits buys you nothing. Be honest about whether the thing really is disposable, because prototypes that get demonstrated to a customer rarely stay disposable.

The second is when the shape is wrong rather than the details. If a series of small patches has each been reasonable and the result still contradicts itself, patching further compounds the problem. Re-prompting from a corrected plan against a clean branch is often faster than untangling five iterations of accommodation.

The third is when the redo is genuinely cheap, and that is a condition rather than a feeling. It is cheap when the intent is written down somewhere other than the chat history, when tests define what working means, and when the last known-good state is a commit you can return to. Without those three, a rewrite is not a reset. It is a second attempt at the same gamble with less information.

The review you still owe

Small iterations make review possible; they do not perform it. The gap in the original definition of vibe coding is the diff read, and no amount of step-sizing fills it on its own, as covered in reading the diff is the review vibe coding lacks. What small steps buy you is a review you can actually complete: a change of a few files, in the files you predicted, against a test that failed before and passes now.

The things that survive this process badly are the ones nobody runs a check for. Dependencies added quietly, secrets moved into the wrong file, authorisation assumed rather than enforced. Those belong in automated checks that run on every commit rather than in your attention, which is finite and will be spent on whatever is on screen. The failure modes worth building checks for are set out in the risks and limits of vibe coding.

---

Written with AI assistance and reviewed under our editorial policy. Vibe coding changes quickly; details reflect sources current on 2026-09-16. Some passages are the author's opinion. Spotted an error? tell us.