Writing

Loop engineering

Mar 2026 · 6 min

The unit of engineering productivity isn't the brilliant idea. It's the loop: the edit-run-observe cycle you repeat hundreds of times a day. Halve its length and you don't get twice as much done — you get to attempt problems that were previously too expensive to try.

Measure the loop, not the task

Before optimising anything, time your actual loop. How long from "I change a line" to "I see the result"? For most people it's dominated by waiting — slow builds, manual verification steps, flaky environments.

Cut the waiting

  • Make feedback local. A test that runs in 200ms gets run; a suite that takes five minutes gets skipped.
  • Automate the observation. If you're manually clicking through a flow to check a change, that's loop latency you pay every single time.
  • Keep state hot. Restarting from cold is a tax on curiosity.
# A loop worth having: watch, rebuild, re-run on save
$ bun test --watch

The compounding effect

A tight loop changes what you're willing to attempt. Experiments that felt reckless become cheap. You explore more, and exploration is where the good ideas actually come from.