Build7 min read

What building faster
actually requires.

Speed is not typing faster. It is reducing uncertainty, shortening feedback loops, and keeping the system healthy enough to change.

Teams rarely move slowly because engineers cannot write code fast enough. They move slowly because the next decision is unclear, feedback arrives late, and every change feels dangerous. The fastest teams are not rushing. They are removing friction from the path between a decision and what a user can experience.

Front-load the expensive thinking

Ambiguity is cheap in a conversation and expensive in a codebase. A short architecture session can expose a missing decision about ownership, data, permissions, or edge cases before it becomes a week of rework.

We do not try to design every future state. We decide what must be true for the first useful version, make those constraints visible, and leave intentional seams for what we do not know yet.

The fastest path is usually the one with the fewest unknowns, not the fewest lines of code.

Work in thin vertical slices

A slice is valuable when it travels through the whole product: input, decision, data, interface, and outcome. A polished screen without a real loop is a picture. A thin vertical slice is something a user can actually react to.

  • Choose one user and one job.
  • Connect the smallest real data path.
  • Make the outcome observable.
  • Put it in front of someone before adding breadth.

Keep the delivery loop healthy

Martin Fowler’s work on agile fluency emphasizes a progression from focusing on business value to delivering reliably and then optimizing decisions. The lesson is practical: a team cannot sustainably move faster if it cannot release, test, and recover with confidence.

Automated checks, small changes, clear ownership, and a production-equivalent environment are not bureaucracy. They are the infrastructure of speed.

Use AI as leverage, not a steering wheel

AI can compress exploration, generate a first pass, explain unfamiliar code, and make repetitive work cheaper. It does not decide what deserves to exist. Product judgment still comes from understanding the user, the system, and the tradeoff.

Give AI narrow, inspectable tasks. Keep the human responsible for the acceptance criteria. Review the output at the boundary where it can affect users, data, money, or trust.

Research notes

Paul Graham, “Do Things that Don't Scale”
James Shore and Diana Larsen, “The Agile Fluency Model”

Next noteDesigning useful AI workflows