The thing that made engineers un-poolable just left the building

The constraint that kept engineering from being pooled broke quietly, and not because anyone set out to break it. In an earlier article, Why you could never pool an engineer, I said that constraint was state, the knowledge that made an engineer valuable and couldn't leave them. Here I'll explain how it broke, because the way it broke matters more than the fact that it did.

The obvious story is that AI writes code now, so you need fewer people, so the problem shrinks. That's true and it's not the point. Fewer people in the same shape is still the shape. What actually changed is quieter: the tools that produce the work also, as a side effect of how they have to be used, write down why. To get anything useful out of them you have to state the constraint, the convention, the thing that must not change, the reason the obvious approach was rejected. The things that used to live in a senior engineer's head because nobody had a reason to write them down are now written down because the work can't start otherwise. The state is being externalized not by a documentation initiative but by the production process itself.

Look back at the list from the previous part. Why the ugly module exists; which refactor was abandoned and why; what the regulator asked for; who vetoes what; what breaks when you touch the safe-looking function. Each of those is exactly the kind of thing you now have to put in front of a tool before it can do the task well, and once it's in front of the tool it's in the system. For the first time, the two halves of an engineer's state, the organizational memory and the knowledge of the code, have somewhere to live other than the engineer.

When the state lives in the system, the person stops being the only place it exists. A second person can pick up where the first left off, not because the first wrote a handover under time pressure on their way out, but because the record was built as the work was done and is current as of this morning. That's the separation cloud had from the start: a layer that moves and a layer that holds the state. Engineering just got it.

Now the objection, because it's the right one and I'd rather make it myself. If the tools keep improving, won't they simply do all of this, and the people with them? Part of the answer is yes, and it's a part I take seriously; a lot of what I was paid for over the years was throughput, and throughput is what the tools replace first. But look at what's left when throughput goes. Deciding what this particular product should do. Choosing among several reasonable options the one that's right for this case and this customer. Knowing which output to reject, and why. That part doesn't shrink as the models improve; it becomes the whole job. And it's the part that was always the actual constraint on quality. A generated system inherits whatever the prompt failed to say, and the things a prompt fails to say are, almost by definition, the things that take judgment to know.

So the tools getting better doesn't dissolve the problem. It moves it. The question stops being "can we produce enough" and becomes "who decides, and is their judgment available when the work needs it." Which is the same question the first part asked about the specialist you need for a week a quarter, now asked about judgment instead of hours.

And judgment, it turns out, has the properties that pooling needs. It's needed in bursts, it's uncorrelated across customers, and now that the state it works on lives in the system instead of the person, it can be applied to more than one system without starting from zero each time.

Put those two things together, the state externalized as a by-product of the work, and the human part of the work shrinking to the part that was always the scarce part, and the arithmetic from the previous part stops being a thought experiment. The thing that couldn't be pooled can be.