On fewer, better things

Every process I have worked inside assumes that making things is expensive. Rounds, design reviews, sprint planning where the unit being planned is production time. None of that is arbitrary. It was built on one fact that used to be reliably true: getting from an idea to an artifact took long enough that you had to be careful which ideas you spent it on.

That stopped being true, and it didn't stop because of AI. Figma took a chunk out of it, component libraries took another, and by the time generative tools arrived the cost of a plausible artifact had been falling for a decade. They finished the job.

The constraint is not gone, though. It moved.

It moved somewhere with no tooling

When producing is cheap, the expensive thing becomes deciding what is worth producing and judging whether what came out is any good. Both were always part of the work, neither was ever the bottleneck, so neither got a process of its own. A roadmap comes close, but it is rationing production time, and there is no sprint planning for taste.

I have worked in many large product suites where parts overlapped. Most enterprises run into this at some point, and all of it happened while producing was expensive. Cheaper production adds no judgment about what is worth building. It removes the friction that was standing in for it.

The judging half is harder, because evaluating something is not cheaper than making it. Build it yourself and you understand it for free: you know what you traded away, and which parts are holding it up. When it arrives finished you know none of that, and working it out later costs more. A slow, legible cost got swapped for a fast, invisible one.

Advait Sarkar has a name for the part that survives: critical integration, deciding when to hand a task over, framing it, and judging what comes back. In a TED talk he put it less politely. "I've become a professional validator of a robot's opinions."

His prescription is a machine that argues back, "Socratic gadflies" in place of robot secretaries. It exists now, and a tool you have to ask to challenge you is still obeying.

Being challenged by a machine is still evaluation, and evaluation is already most of what is left. His own survey of 319 knowledge workers found the work shifting toward verification and stewardship of what the machine produced. The apprenticeship was finding the mistake yourself, and being shown it is not the same.

The part I find uncomfortable

Judgment has to come from somewhere. I have no story for where the next decade gets theirs if building is the step we automate.

So how do you teach judgment to someone whose first five years of making produce nothing that breaks in front of them? And when it breaks, do they know why, or do they ask the thing that made it?