Small Diffs, Frequent Commits
Why the one-shot mega-prompt fails, and how splitting work into reviewable pieces makes the AI dramatically more useful.
The single most common way people fail at vibe coding is asking for too much at once. It feels efficient. It is the opposite, and the reason why is worth understanding precisely rather than taking on faith.
The mega-prompt trap
Here is the prompt almost everyone writes in their first week:
Build me a task app with user accounts, projects, due dates,tags, a calendar view, email reminders, and dark mode.You will get something. It will run. And then you are stuck, for three reasons.
- 1You cannot review it
Two thousand lines across fifteen files. Nobody reviews that properly, so you accept it unread — and now you are maintaining code you have never seen.
- 2You cannot debug it
Something is broken. Which of the eight features caused it? Every one is a suspect, because they all arrived together.
- 3You cannot steer it
The AI made a hundred decisions you never saw. By the time you disagree with one, the rest are built on top of it.
What good looks like
Same app. Ten prompts instead of one:
1. Set up the project with a page that lists hardcoded tasks.2. Add a form to create a task. Keep it in React state.3. Add a checkbox to mark a task done.4. Persist the list to localStorage.5. Add due dates with a date picker....Each one is reviewable in a minute, runnable immediately, and committable. If step 5 breaks something, steps 1 to 4 are still good and you know exactly where the problem is.
Why the AI does better too
This is not only about your comprehension. Small requests get better output, for a reason that follows directly from the previous part of this course.
One large request
The model must satisfy eight constraints at once. Anything it produces for feature one has to remain consistent through feature eight, and consistency degrades as the output grows.
Eight small requests
Each has one goal, and each new one can see the real, working code from the last. It is building on facts rather than on its own predictions.
Commit like you mean it
Small diffs only pay off if you actually snapshot them. The loop is short enough to become muscle memory:
$ git add .$ git commit -m "Add due dates to tasks"Do that after every prompt that works. It costs three seconds and it is what makes git restore . a real option instead of a threat — you can always throw away the current mess without losing the last good state.
When bigger is actually fine
The rule is not absolute. A large change is reasonable when it is mechanical and verifiable — renaming a symbol across forty files, say, where the type checker confirms the result and any error is loud rather than subtle.
The distinction is not size. It is whether you can tell that the change is correct. Forty files of a rename you can verify beats one file of logic you cannot.
Key takeaways
- If you cannot write the commit message, the prompt was too big.
- Small requests produce better AI output, not just more reviewable output — each one builds on real code instead of predictions.
- Commit after every prompt that works. Three seconds buys you a working undo.
- When something breaks, small diffs tell you where. Large ones make everything a suspect.
- Size is not the real test — verifiability is. A big mechanical change the compiler checks is fine.