Writing code is the last step of the development process

If you measure a software project's progress by how much code has been written, you're measuring the wrong thing.

Code is the fastest part of the process — and getting faster still, with AI helping write boilerplate, generate tests, scaffold a feature's initial structure. What doesn't speed up at the same rate is everything that needs to happen before it: understanding the process, mapping the exceptions, deciding the architecture, validating with the people who'll use it.

The inverted funnel

In practice, a well-run project spends most of its time before writing the first real line of logic: process diagnosis, prototyping, validation with the people who operate day to day. By the time it's time to program, the hard decisions have already been made — what's left is execution.

That flips a lot of people's intuition, which associates "being at work" with "being at the keyboard." But a team that already knows exactly what to build writes code fast, because it doesn't have to remake decisions halfway through. A team that starts coding without that groundwork writes fast at the start and slow at the end, because every deferred decision becomes rework.

Where AI actually helps — and where it doesn't

AI accelerates the step that was already the fastest: writing the line of code once the decision has already been made. It doesn't replace the slower, more important step, which is deciding what to build. Asking AI to "solve the problem" without having done that work first just moves the ambiguity inside the generated code — faster, but just as wrong.

What this changes day to day

A healthy development process treats code as the last visible step of work that started well before it: in the diagnosis, in the prototype, in the conversation with whoever uses the system every day. By the time it's time to write, the hard work is done — and that's exactly why it's possible to move fast without it turning into a hack.