The Yes Engineer Confuses Typing with Judgement

A take has been doing the rounds: software engineering ran on code rationing for fifty years; LLMs have ended the rationing; the "No Engineer" who enforced it is now a liability; the "Yes Engineer" who ships ahead of the discussion wins the next decade.

It's a tidy framing. It's also wrong in a way that's worth taking apart, because the error is the same one that surfaces every few months in a different costume.

The first problem is that authoring cost and ownership cost are not the same thing, and the No Engineer was almost never gatekeeping authoring cost. Writing the code was the cheap bit. What got rationed was everything downstream: the maintenance surface, the operational burden, the coordination tax, the security footprint, the cognitive load on the next person who has to reason about the system, the migration cost when the framework you adopted in good faith gets abandoned in eighteen months. LLMs collapse the cost of producing the first draft. They do approximately nothing for any of that. If anything they make it worse, because the ratio of code to considered thought just got worse by an order of magnitude — there is now more plausible-looking code competing for the same finite quantity of human attention.

The second problem is that "no" is not a single word doing a single job. There are at least four versions of it, and the piece treats them as one.

"We don't have bandwidth" is a capacity no. Yes — LLMs genuinely move that one. Fine.

"This won't scale" is an architectural no. Typing speed has nothing to do with it. The scaling problem is about contention, coordination, data gravity, and failure modes. None of those got cheaper.

"We need a design doc first" is a coordination no. It exists because three teams need to agree on an interface before anyone builds against it. Generating the doc faster doesn't help; the bottleneck is the agreement.

"That's out of scope" is a strategic no. It's about whether the thing should exist at all. An LLM that can write the code does not, by writing the code, settle the question of whether the code should exist.

The viral framing collapses all four into the first one, declares the rationing system obsolete, and waves through the rest. This is the move to watch for. One input got cheaper. The piece treats the entire decision system as obsolete on that basis.

The third problem is the implicit equation of shipping with progress. The Yes Engineer who ships three versions only wins if those versions were directionally right. If they shipped the wrong thing fast, the org now owns three times the cleanup, three times the user expectations to manage down, and three times the rollback cost — which is precisely the bill the No Engineer was trying to avoid sending. Output is not outcome. We knew this before LLMs; we will continue to know it after.

There is a defensible kernel here, and it's worth keeping. Capacity-based gatekeeping was always the weakest of the four nos, because it tends to deflect work that should happen rather than work that shouldn't. "We don't have bandwidth" rations everything equally — the good idea and the bad — and the bad one would have been killed by one of the other three nos given the chance. LLMs do erode the capacity no, and that's a net good. More ideas get to face the architectural, coordination, and strategic questions on their own merits.

But those questions do not get easier. They get more important, not less, because the volume of plausible-looking code arriving at their door has gone up tenfold. The judgement layer was always the valuable bit. We just used to be able to pretend that capacity gating was doing some of that work for free, because the things that didn't get built didn't have to be evaluated.

That's gone now. Everything gets built. Everything has to be judged. The Yes Engineer who hasn't noticed this isn't winning the decade — they're generating the cleanup work for the people who have.