You let your agent write a whole feature in one shot, and it half-works. Now the change is too big to read, and you cannot tell which part broke what. This chapter fixes that at the source: build in small slices, one working change at a time, so nothing ever grows too big to understand or undo.
5.5.1Ship in slices, never big-bang
A slice is one thin, complete change: it does a single visible thing and leaves the app running. The opposite is the big-bang, one huge change that adds everything at once and only works if every part is right.
The big-bang loses every time. When one large change misbehaves, you are untangling ten things braided together. Cut the same work into slices and each piece is small enough to read and trust before the next.
Rule of thumb: if you cannot name the one thing a change does, it is more than one change.
5.5.2One working change at a time
Cut along features, not layers. A good slice reaches from what the user sees down to where data is stored and does one real thing, so you can run it and watch it work. A bad slice builds half of everything and runs nothing.
Take a login feature. Instead of "build login," your agent works it as a sequence of small changes, each one runnable and each its own commit:
feat: show the login form (no logic yet)
feat: accept email + password, log to console
feat: verify credentials against the database
feat: start a session on success
feat: show an error message on failure
5.5.3Commit after each green step
Green means it works: the app runs and the new slice does what it should. Commit at exactly that moment, never before. You already set your agent to save a snapshot after every working step; this is the discipline that makes that safety net worth having, one green slice, one commit.
A commit on red, code that does not run, poisons your history. Now a "saved" version is broken, and it is useless as a fallback. Only green earns a commit.
5.5.4Small steps make rollback easy
When every commit is one green slice, going back is surgical. A slice breaks something, you undo that one commit, and you are on solid ground again instead of unwinding an afternoon.
It is also how you find the culprit fast. With small steps, the change that caused a bug is one small diff, the handful of lines it touched, obvious on sight. With a big-bang commit, the cause is buried in hundreds of lines. The later chapter on hunting down which change caused a bug turns this into a method.
5.5.5Hand the slicing to your agent
Give it a feature and let it plan the slices for you:
Act as a senior engineer breaking work into small,
safe slices. Take the feature below and return an
ordered list of vertical slices. Rules:
- Each slice does ONE visible thing end to end and
leaves the app runnable, never a half-built layer.
- Order them smallest and safest first, each one
building on the last.
- After each slice, stop, confirm it works, and
commit it with a short clear message before you
start the next.
- If a slice is too big to read in one sitting,
split it again.
The feature to slice up:
Do this now: paste the prompt above with your next feature, and build it slice by slice instead of all at once.
