Part 4

The work cycles

2 min read

4.1 A project is not an increment

There are two sizes of work, and confusing them causes most of the mess. An increment is a small, self-contained change. A project is a larger effort with its own intent, scope, and spec. You open a project deliberately. You don't let a "quick change" quietly become a three-week rebuild without ever writing down what you're doing.

4.2 The intent spec, written before any code

Before building, write the design doc: the goal, the current state of the code, the decisions already made, the data model (new tables and columns), the slices, the list of tests, and what's explicitly deferred. It's the source of truth, and it lets anyone (another session, or an AI) pick up the thread. Writing it is not overhead. It's the cheapest place to be wrong.

4.3 The delivery chain, in order

BrainstormDecideSpecGroundPromptBuildVerifyShipTest liveskipping a step does not remove it, it returns later and more expensive
The chain runs in order. Skipping a link doesn't save time — it moves the cost downstream.

Brainstorm, then decide the real trade-offs one at a time, then spec, then ground (read the existing code so you build in the right place), then prompt the executor, then build, then verify (build, type-check, re-read, test in a real browser), then commit, push, deploy, then test the slice. Skipping a link doesn't save time. It moves the cost downstream, where it's bigger.

4.4 Classify work by reversibility

Reversibleundone in a minuteCopy, styling, a settingA feature behind a flagDecide fast, alone.Reversible with effortundoable, but it costsA screen rebuildAn internal API changeWrite the decision down.Hard to undothere is no going backA schema migrationMoney, customer dataProve it first. Always.
Sort work by how expensive it is to undo, and spend your caution where undo is costly.

The single most useful sorting question: if this goes wrong, how expensive is it to undo? Three verdicts. Cheaply reversible, like a visual tweak: move fast, fix forward. Reversible with effort, like a change to how data is shaped: verify harder, keep a rollback path. Hard to reverse, like moving money, a destructive data migration, or anything users can't un-see: slow down, prove it, test it for real. You don't apply the same caution everywhere. You spend it where undo is expensive.

4.5 Debugging as a method, not a vibe

When something breaks, don't poke at random. Work in phases: reproduce it reliably, isolate where it happens, form one hypothesis, test that one hypothesis, fix, then prove the fix with the exact signal the bug would show if it came back (Law 4). Random poking sometimes works and teaches you nothing. A method works and compounds.

4.6 Refactoring in waves

Don't rewrite everything at once. Change in small, provable waves. After a mass change, prove it with an invariant (Law 6), not a re-read. And never run two waves in parallel on the same area: they edit the same big files and step on each other.