Only Start When You Can Verify
Don't ask AI to write a whole e-commerce site. Break it into steps small enough to verify. Big prompts make big problems.
The most common way to break: ask AI to "write out this mall." AI spits out thousands of lines, and at the end you can't review, tests are all red, and there's nowhere to even start fixing. The problem isn't AI; the task was too big.
After reading, you should be able to answer:
- Why do big prompts fail more easily?
- What's the criterion for "small enough"?
- How different is having AI run to the end versus going step by step?
Why big prompts fail
- Can't fit all the context in one call: a big feature needs knowledge from a dozen files; AI can't stuff it into one prompt, so it has to guess
- Errors at scale: a few hundred lines hiding several bugs, each hard to locate; fixing one can break another
- Hard to verify: one-shot output has long, dense tests, and you can't tell where a problem starts
- Expensive rework: wrong direction means throwing out thousands of lines, and AI muddles things further
A big prompt is an engineering problem, not a capability one: you're asking AI to finish a chunk of unverifiable work in one go.
The criterion: small enough to verify
A plain standard: when this step is done, can you immediately tell if it's right? copilot-cost
- "Write a product-card component with image, title, price, add-to-cart" → verifiable; run it and you see it
- "Style the product card and wire mock data to it" → verifiable
- "Write a complete mall" → not verifiable, too vague
Anything you can't answer "how do I verify this when it's done" for is not small enough—keep splitting.
The three moves of splitting
- First do the skeleton: the smallest runnable shell, wired all the way through
- Then fill in one verifiable feature: add one real behavior, verify once
- Stack gradually: with every stacked step, verify and commit
Each step small and verifiable, AI's error rate drops level by level, and your rework time shrinks exponentially.
Commit as your safety net
Commit once after each step. That's the insurance against "one bad iteration wiping out hours of work"—if it really breaks, roll back to the last commit point instead of soldiering on over broken code.
- One commit per step, even a small one
- Write the commit message to say what the step did
- When it goes wrong, roll back and try again any time
Small steps plus a commit each is the key move from "churning code" to "directing development." Once you've split well, learn to delegate outcomes, not steps.