One Thing at a Time

Break the work into small tasks; don't ask for an entire application at once.

Break the work into small tasks; don't ask for an entire application at once. Have it do one thing at a time, something you can verify on its own. Done? You confirm. Then the next.

What you'll run into:

• It generates hundreds or thousands of lines in one go, and you give up reading halfway and just run it
• When something breaks, you can't tell which step introduced it, so you rewrite the whole block
• You change one thing and it casually touches three unrelated files

The cost of a big task is not in generation, it's in verification. AI writes code almost instantly; reading and fixing it costs you time. Two thousand lines at once means you either read all of it or skip verification and just run it—most people pick the second option, and pay for it a few steps later.

How big should one step be

Judge the step size with four tests:

The second test is the most practical. You know whether you'd actually read it—if you suspect you'd skip, it's not small enough.

Step size is, at bottom, verification cost. The smaller the step, the more you can verify at once and the narrower the search when something breaks; the bigger the step, the more code and relationships each verification forces you to read. Splitting small isn't about code volume—it's about the scope of a single verification.

Small steps have a hidden benefit: every step is a save point you can roll back to. Mess up step three and you revert to step two, with everything before it still intact. With big steps, your only option is to tear the whole block down.

How to break it down

Two things should stay small: the granularity of what you verify, and the scope of what changes.

• Split vertically, not horizontally. Split by one complete user action (record an entry, view a list), not by frontend, backend, and database layers (see thin slice). Splitting horizontally fails because each step ends with no user-visible result; verification gets pushed to the very end, which means you didn't really split. A vertical split ends every step on something you can see and click.
• Data first. The first step is always pinning down entities and relationships. Get this layer wrong and every step after comes back for rework.
• Get it running end to end before filling in. Let the main flow run through from start to finish first; the four states, edges, and exceptions come in a later dedicated step.
• Confirm one step at a time. Look right after each step—don't save up three steps to verify at once. Saving them up means you didn't really split: you still have to read a huge chunk at once, and you still can't tell which step broke things.
• If the spec runs over one screen, split further. This and spec before code are mutual sanity checks: if the spec won't fit on one screen, the step is probably too big.

After breaking it down, write the task list itself into a file and have it update the status after each step. That way, even if the session is interrupted, the progress survives—a concrete way of writing context to the outside, and what makes small steps sustainable.

"Data first" and "get it running end to end" are a pair: data pins down the skeleton, and running it through pins down the main path. Get the skeleton wrong and everything after is rework; branch out before the main path works and the branches lead nowhere. Both done, and this screen finally has a foundation to verify against.