Slices, not sprints
Hand an agent a big feature and you get a big diff you cannot review and should not trust. The fix is not a better prompt. It is a smaller unit. Spec-first, one independently-deployable slice at a time, each in its own worktree.

The fastest way to get a useless result out of a coding agent is to give it a big job. Ask for the whole feature and you get a 2,000-line diff that touches forty files, mostly works, and is completely unreviewable. You cannot tell what it got right from what it confidently invented. So you either rubber-stamp it or you throw it away. Both are bad.
The reflex is to write a better prompt. That is not the lever. The lever is the size of the unit.


The unit is a slice
My unit of work is not a sprint and not a ticket. It is a slice: the smallest vertical cut that is independently deployable and, more importantly, independently reviewable. If I cannot review it in one sitting and tell whether it is honest, it is too big.
A real example. I needed a capacity engine. It shipped as four slices, layers hard separated:
- Slice 1, the engine. Pure compute. No database. No clock. Deterministic. You can test it to death because it has no world to mock.
- Slice 2, the API on top of it.
- Slice 3, the query path that feeds it.
- Slice 4, reconciliation.
A bigger migration ran the same way, as numbered slices one through eight, each one landing on its own. Big-bang migrations die in review. Sliced ones land on a Tuesday and nobody notices, which is the goal.
Spec first, then a failing test, then code
Every slice gets a short spec before a line of code. Dated, with the problem, the data model, and an explicit list of non-goals. The non-goals matter more than the goals, because an unleashed agent will happily build three slices ahead and call it helpful.
Then TDD order, on purpose. Failing test, implementation, passing test, commit. One commit per logical unit. This is not nostalgia. With an agent the test is the leash. It is the thing that catches the plausible-but-wrong code that reads fine and runs fine and is quietly doing the opposite of what you asked. The spec says what; the test proves it; the slice keeps both small enough that the proof is cheap.
One slice, one worktree
Slices live in their own git worktree. So I can have five of them in flight at
once without them stepping on each other, each with its own agent, its own branch,
its own clean tree. The naming is boring on purpose, one directory per feature, and
I have run dozens at a time across a single repo.
Because these are my own projects, there is no rollout ceremony. No soaking, no canary, no gating. A green slice ships straight to main. The discipline goes into the slicing and the review, not into a deployment pipeline that pretends each change is a moon landing.


What this is not
It is not ceremony for its own sake. A two-line fix does not need a spec and a worktree, and if you wrap one in process you have missed the point. The discipline scales with how much you are letting the agent touch. Small blast radius, small process. Large blast radius, slice it down until the blast radius is small again.
The bottom line
Agents made typing free, which means the bottleneck is now review. Everything about how I work is bent around that one fact. Slice so the diff is reviewable. Spec so the agent has a leash. Test so a clean-looking lie gets caught. Worktree so the work runs in parallel without tangling.
The spec is the contract. The slice is the unit. The worktree is the workbench. Get those three right and the agent is an asset. Skip them and it is a very fast way to generate code you are afraid to merge.
