Generating in Small Slices

Asha pasted her whole brief and asked for everything at once. Ten minutes later she had forty new files, a screen that mostly worked and an allergy filter that did nothing. She could not tell which of the forty files was wrong, and every fix she asked for broke something else.

The rule

Generate one thin working slice, check it, save it, then the next.

A slice is a thin piece of the product that runs end to end — through screen, logic and data — even if it does very little. The first slice is often a walking skeleton: the whole path exists, with a fake answer where the hard part will eventually go.

Why slices beat one giant request:

• Checkable. A small change has only a few places where it can go wrong.
• Recoverable. A save point after each working slice — a commit in version control, or your tool's snapshot — means a bad next step costs minutes, not the project.
• Honest. Each slice is checked against its own acceptance check, so broken parts cannot hide inside a big result that only looks finished.

Put the riskiest parts early, and make sure each slice leaves the app working.

The shortcut

Skeleton first, then swap fakes for real, one at a time. List the slices, and after each one: run it, check it, save it.

If slice 3 goes wrong, Asha returns to the save point after slice 2 and asks again, more precisely. Nothing that already worked is at risk.

A tempting alternative is building layer by layer: all the screens first, then all the server code, then the database. It feels organised, but nothing runs end to end until the very end, so the first real test happens when everything is already built. Slices cut across the layers so that every step can be run and checked.

Drills

Answer fast — trust the rule.

Remember

• Generate one thin working slice, check it, save it, then the next.
• Skeleton first, then swap fakes for real, one at a time.
• Trap: one giant request with no save points, impressive in minutes and untraceable for days.