Upstream Work in the AI Era — When Code Gets Cheap, What Gets Valuable?

When implementation gets cheap, which parts of the cost remain, and what becomes expensive by comparison? We put the relationship between deciding and reworking into an equation, then design specs for AI as lossy compression of intent — starting from zero assumed knowledge.

An analogy: when typesetting vanished, did editors lose their jobs?

Arranging type for print used to be a skilled trade. Once desktop publishing arrived, the cost of that step fell to roughly nothing.

Publishers did not empty out. What got cheap was arranging the letters, not deciding what to publish. If anything, once anyone could typeset, the volume of printed material went up — and the ability to pick what was worth reading became the scarce part.

The same shift is happening in writing code. The time spent working out "how do I write this line" has visibly shrunk. What has not shrunk is the time spent deciding what to build, and what counts as done. Let's break that down as a cost structure rather than a vibe.

Intuition: bottlenecks don't disappear, they move next door

Picture a factory line. When the stages run in series and one of them is much slower than the rest, that stage sets the pace for everything. Put a machine in and make it ten times faster, and total time still doesn't go to zero — the next-slowest stage simply steps forward as the new bottleneck.

That is what teams are experiencing. Because "building" got fast, the stages on either side of it became relatively more visible: time spent killing ambiguity in the request, time spent choosing between options, time spent checking whether what came back is right.

There's a second effect that is easy to miss. Being able to build fast also means you can now travel in the wrong direction fast. When implementation was slow, that slowness acted as a speed bump: you had room to notice, mid-build, that a feature wasn't needed. With that room gone, deciding direction has to happen earlier and more deliberately.

Mechanism: split the cost into three parts

Argue for upstream work in words and it turns into moralizing. Write it as an equation and the structure shows up. The total cost of delivering a feature:

$C$ is total cost, $D$ is the cost of deciding (gathering the request, comparing options, making the call), $B$ is the cost of building (implementation and everything around it), $p$ is the probability the spec is wrong, and $R$ is the cost of redoing the work once that error surfaces.

What the equation says, in words: everything it takes to ship a feature is just deciding, plus building, plus the redo you sometimes have to pay for. The rework term carries $p$ because it doesn't happen every time, so $p\,R$ is expected rework cost.

Cheaper implementation means a smaller $B$. $D$ barely moves — listening to a request and weighing options are hard to hand off to a tool. Part of $R$ shrinks along with $B$, but the underlying structure stays: mistakes propagate downstream before anyone notices. That mechanism is covered in Upstream Engineering from Scratch.

Once $B$ is small enough, total cost is roughly $C \approx D + p\,R$. So ask how much $C$ moves when $p$ moves a little:

The right-hand side is nothing but $R$, which says: whatever you shave off the probability that the spec is wrong, you save that much multiplied by the entire rework bill. Upstream effort turns into money only once $R$ multiplies it. The larger $R$ is — that is, the later mistakes surface — the more an hour spent upstream is worth. Conversely, if a mistake shows up in five minutes, just build the thing. How thick your upstream process should be isn't a matter of conviction; it's set by the size of $R$.

A wrong heading turns speed into a loss

The other thing worth separating is quantity from direction. As vectors, the useful part of your output is its projection onto the intended direction:

$|v|$ is how much you built and $\theta$ is the angle between intent and result. At zero degrees, everything you built counts. At ninety degrees, no amount of building counts at all. Past ninety, the value is negative — and not metaphorically: that's code you have to delete and dependencies you have to unpick, each with a real bill attached.

Put in words: what counts as value is not how much you built, but only the share of it that points where you meant to go.

Cheap implementation means it's easy to grow $|v|$. When $\theta$ is small, value grows in proportion. When $\theta$ is large, the loss grows in proportion too. Running fast only pays when you're pointed the right way.