What Do You Build When AI Can Do the Work?

The code that renders Numeria's 108 readings is the cheapest thing in the product. I could ask an agent to rebuild the screens this afternoon. What I could not ask it to rebuild is which reading a person sees after which, what the copy refuses to promise, or why the navigation has no back button. Those decisions are the product. The code is how they run.

That is the question Jake Van Clief takes on in a 34-minute video published October 21, 2026: What Do We Build Now That AI Can Do the Work? He wrote the script by hand to make a point about what "manual" even means, and the argument is better than the title suggests. It is not a list of safe niches. It is a definition of a program, and once you accept the definition, the answer to "what do I build" falls out of it.

This is my extension of his argument from the product side: what an enterprise PM would tell a founder to own, and what I am doing about it in my own builds.

A program is instructions, a runner and state

A program is any system with three parts: instructions, something that executes them, and an output or state that survives the execution.

Van Clief's point is that none of those parts requires a computer. A company's operating procedures are instructions; a room of clerks is a runner; the filed ledgers are state. A punched card was the instruction for a loom, the weaver and loom ran it, and the cloth carried the result. A CLAUDE.md file, a skills folder and a prompt are instructions in exactly the same sense, and the files an agent leaves behind are the state.

His one-line version is worth keeping: "AI is just part of a program. It is not the program." The model is the part that runs instructions and hands off output. It is the newest runner in a long line of them.

Look at what changes when you swap eras in that diagram. Only the middle slot. That is the whole strategic argument in one picture: the runner is the part that keeps getting cheaper, and the other two slots have always been the builder's job.

He makes it concrete with "check my email." He points out that three years ago an assistant could not do that reliably, and today most of them can. His claim is that the model did not suddenly understand email; somebody wrote down what "check" means, which mailbox, what counts as important, and what to do next. The instructions got better. Somebody's opinion about the work got encoded.

Cheap execution moves value to the layers the runner can't supply

When the cost of executing an idea approaches zero, the value of a product concentrates in the layers that never depended on execution being hard.

I have watched this from both chairs. In enterprise product work, a large share of what a roadmap protected was simply the fact that building was slow: a feature a competitor needed two quarters to match was a real advantage, even if it was ordinary. As a solo builder with an agent, I can match an ordinary feature in a weekend. So can everyone else. The quarter of lead time was the moat, and the lead time is gone.

Drag the slider below and watch what happens to the mix. It is my model, not measured data, but it is the model I actually use when I decide what to spend a week on.

The layers that fade are not worthless. Users still need login screens. They just stop being a reason anyone picks you. The layers that stand are the ones I argued for in what still protects a SaaS when code is cheap, with one addition Van Clief makes sharper than most: your instructions are a layer of the product, not documentation about it.

Manual is whatever layer you are standing on

"Manual" has never meant a fixed amount of effort; it means doing the work at the highest layer of abstraction available to you in your era.

Van Clief opens the video by admitting the irony of hand-writing a script about AI, then dismantles the word. Typing in a word processor runs layers of software written over decades. Someone from an earlier era would call cut-and-paste with scissors manual, and someone earlier still would insist you grind your own ink. Punching the card, writing the code and writing the instructions are the same act at different heights.

Nothing below the person disappears. Machine code still runs every time you bold a word. It just stopped being the part anyone calls craft. That matters for what you build, because the craft moves with the floor. Today the craft is the instructions: what the goal is, what the constraints are, what you assume about the reader, and what the thing should produce.

Van Clief breaks every instruction into those four pieces: a goal, a constraint, an assumption and the thing to be built. He suggests we are slowly inventing a decentralised, domain-specific language for computers out of English, the way legal drafting turned English into something narrower and more exact. I think he is right, and I think most teams have not noticed that their prompt files have become source code.

Someone else's instructions make someone else's suit

When you run instructions someone else wrote, you get output shaped to their goals and assumptions, not yours.

The video's best story comes from Gerald Weinberg's 1971 book The Psychology of Computer Programming. Levine the tailor sells a man a badly fitting suit and talks him into hunching, leaning and lifting a leg until it seems to fit. Walking out contorted, the man is stopped by a stranger who admires the suit: if Levine can make it fit someone that misshapen, imagine what he can do for me.

Most software has asked people to contort like that. Van Clief's point is that AI finally lets products bend toward the person, and that the bending only happens if somebody's instructions are doing it. Use a generic skill, a generic system prompt and a generic model, and you get the median result: writing that sounds like everyone, decisions that fit nobody in particular.

His rule of thumb is the one I would give a product team. Take the non-opinionated parts off the shelf: connectors, authentication, standard components. Write the opinionated parts yourself: what to do with the email once it is read, what a good reading looks like, what the product will never say. The second list is short. It is also the product.

Try it below. Stack the product you would build, then make execution free.

I keep the Mafia game I am building honest the same way. Its rulebook is a single file that is the source of truth for the game's logic; the model and the code are runners for it. When the rules change, I change the file first. That file is the part nobody else can write, because it encodes what I think makes the game fair and fun. My harness that rewrites its own rules is the same idea one level up: the instructions are an asset that compounds, so they get versioned and maintained like code.

The handback point is the hardest thing to copy

A handback point is the moment in a product where automation stops and a person takes over to add judgment, and choosing it well is a durable advantage because it is hard.

Van Clief leans on Douglas Engelbart here, and the primary source holds up. In his October 1962 report, Augmenting Human Intellect, Engelbart warned that people imagine computers making one-pass improvements: the tool does the task, the task is gone. He called that picture relatively barren next to a regenerative one, where a better tool makes a more capable person who builds a better tool. Van Clief connects it to Steve Jobs's bicycle for the mind, which I wrote about in AI as a bicycle for the mind: the bicycle does not replace the rider, it makes the rider go further.

His most useful sentence for founders is near the end. Figuring out where in a chain of automations to hand the work back to a person is genuinely hard, and if it is hard to figure out, it is a moat. I would add that it is also where enterprise product leaders have quietly spent their careers. Approval steps, exception queues, the review screen before a payment goes out: those were always the product decisions that mattered. AI did not invent the handback. It just made every other decision cheap enough that the handback is now most of what is left.

In my own work the handback points are easy to name once I look for them. In Hexalated, a solver can prove a level is solvable, but whether it is fun is a judgment a person makes by playing it. In Ballistica, the harness measures a level; whether it ships is a design ruling. In Numeria, the reader chooses what to open next, and that choice is the experience. None of those is a feature a clone gets by copying my screens. This is also why I think product judgment gets more expensive as building gets cheap: the handback is where judgment lives.

Run your idea through the scarcity test

An idea worth building now is one whose value survives the runner becoming free: it carries your why, accumulates state, designs a handback, and reaches people you can reach without renting them.

Here is the scorecard I use before I spend a week on anything. Six axes, zero to four. Be harsh; the point is to find the weak side before a competitor does. I have loaded my own honest scoring of Numeria as an example, and it is not flattering on state and distribution. That is useful information, and it is part of why the business model decision comes before any payment backend.

What I would build this quarter

The practical response to cheap execution is to spend the saved time on the instructions, the state and the handback rather than on more features.

1. Write the rulebook before the code. One file that says what the product believes: goals, constraints, assumptions about the user, what it must never do. Version it. Review changes to it the way you review a schema migration.
2. Name the one record that only exists because of you. Not scraped data. Something your users create by using the product. Then show it back to them.
3. Draw the chain and circle the handback. Map every step from input to outcome, mark which ones are automated, and pick the single step where a person's judgment changes the result. Design that screen first.
4. Borrow every non-opinionated layer. Connectors, auth, components, hosting. If you are writing plumbing by hand, you are spending your scarcest hours on the cheapest layer.
5. Treat the runner as rented. Keep your instructions and state portable enough that a better or cheaper model is a configuration change, not a rewrite.

Van Clief closes on a quieter note than most AI videos: everything you sit on was built by someone, so look at whose work you are standing on and build a seat for the next person who needs one. As product advice it is better than it sounds. A seat is a place where a person fits. That is the thing to build.

The runner is cheap now. The why, the state and the handback are still yours to build.

FAQ

Short answers to the questions this argument raises most often.

Want help working out where your product's handback point should be? Let's talk.

Sources

The video supplies the argument; Engelbart's report is the primary source for the one-pass versus regenerative contrast.

1. Jake Van Clief, “What Do We Build Now That AI Can Do the Work?” (YouTube, October 21, 2026)
2. Douglas C. Engelbart, “Augmenting Human Intellect: A Conceptual Framework” (SRI, October 1962), Doug Engelbart Institute