When Execution Gets Cheap, Taste Gets Expensive

One of the better lines from Kerp's fireside was not about AI replacing work. It was about AI moving the hard part.

He was talking through what happens when the cost of execution falls across more than code. Not just "I can build an app faster," but also "I can spin up the first version of a course tool, a judging workflow, a grading assistant, a pitch artifact, a research pass, a form-filling process, or a marketing draft without assembling a whole team first."

That changes the shape of the work.

For a long time, execution cost acted like a filter. If you had an idea for software, someone would ask if you had a technical cofounder. If you wanted a classroom polling tool, a grading dashboard, or a startup judging workflow, the default path was usually a vendor, a budget, an internal approval loop, or a pile of unpaid nights. A lot of useful small tools never cleared that bar. They were too specific, too local, too weird, or too cheap to justify the machinery around them.

Kerp described the newer pattern from inside his own work. He sees product-shaped problems everywhere. Canvas has an API, so he can build a layer that helps him run courses. A startup competition needs a first-round filter, so an LLM workflow can read student pitch materials through multiple judge personas and narrow the pile before humans enter. Exams need consistent grading, so a Claude skill can ingest an answer key, question the instructor about grading logic, calibrate against early samples, and then run the rest of the batch.

None of those examples mean judgment disappeared. They mean execution stopped being the only scarce thing.

That is the useful distinction. The prototype is cheaper. The deck is cheaper. The workflow is cheaper. The first draft is cheaper. The code is cheaper. But the cost that disappears from production tends to reappear in selection.

What should exist? Who is it for? Which version is worth keeping? Which generated answer is almost right but dangerous? Which feature looks finished but breaks the actual process? Which audience will care enough to use it, trust it, fund it, or pass it along?

Kerp put it plainly: if everyone can do the execution piece, what is left?

One answer is taste. Not taste as decoration. Taste as the ability to notice what is worth making, what should be cut, and what feels wrong before the spreadsheet catches up.

Another answer is sequencing. Cheap execution makes it tempting to build everything at once. Better builders will know the order: sketch, test, narrow, throw away, rebuild, ship the part that proves the point. The work becomes less about whether you can produce output and more about whether you can arrange the right outputs in the right order.

A third answer is judgment. Kerp made the same point about engineering: code generation is a task engineers do, but it is not the whole job. The deeper function is understanding systems, processes, security, failure modes, and quality. When more code appears faster, somebody still has to absorb the output and decide whether it belongs in the thing people depend on.

And then there is distribution. If execution gets cheaper for everyone, making something is no longer enough to make it matter. The remaining advantage sits with the people who know where the work should land, who already have trust, who can explain the thing clearly, and who can get the right ten people to care before trying to impress ten thousand.

That is probably the more grounded version of the AI productivity story. Not a clean replacement narrative. Not a magic wand. A relocation of scarcity.

For builders, that is good news and bad news.

The good news is that more strange, local, public-good-shaped tools become possible. The tiny workflow that used to be too bespoke to fund can now be tested. The course utility, the DAO coordination helper, the research assistant, the internal dashboard, the one-off client prototype: more of them can exist long enough to prove whether they deserve to live.

The bad news is that taste cannot be outsourced as easily as output. You can ask a model for twenty versions. You still need to know which one is alive.

That makes the builder's job less like typing the thing into existence and more like directing a flood. More material. More options. More almost-right artifacts. More pressure to know what good looks like.

Execution got cheaper.

The invoice moved to taste.