The Inversion, Part II: Commodify the Toil, Not the Craft

In Part I I argued that computing has run one way for seventy years when the idea bends to the machine and that Forge inverts it: you declare what you want, the stack materializes to fit, then dissolves. Let’s dive where some of the real value can be materialized.

A while ago a friend pointed me to the essay The Failed Commodification of Technical Work, and if you build infrastructure for a living you should read it before you read me. The thesis is simple: we keep trying to turn technical work into a McDonald’s franchise where interchangeable people producing good-enough output at a reproducible rate, and we keep failing. All the vendors of enterprise software were trying and still try to do this. Buy the new super-duper drag-and-drop tool and fire the people who write SQL (or Python or C++) ! Funnily, nobody tries to replace Excel, but that’s a different story. Except, as Ludic points out, the tool is still connecting to Postgres; it’s just writing the SQL for you behind a licensed layer you now have to pay for and can’t remove. You didn’t eliminate the complexity. You hid it, rented it, and added a new dependency on the people who understand the tool’s quirks.

Inversion pitch could so easily be that pitch. “Declare your intent and the stack builds itself” is one bad paragraph away from “buy the increased-throughput widget and all the story points will be done on time.” So let me try to explain here what’s different, and, more importantly what isn’t.

Two types of commodification

There are two completely different things hiding under that one word, and Ludic’s essay is really about the gap between them.

The first is real commodification: McDonald’s almost never fails to hand you fries of approximately the right quality within five minutes, anywhere on Earth. That is a genuine super-achievement, and the reason it works is very unglamorous - there is a standard, and there is measurement against the standard. The output is enforced and checkable, so it can be made reproducible by people who don’t have to be brilliant.

The second is commodification theater, which is most enterprise software and now AI hype output as we’ll see later: a layer that promises reproducible delivery, hides the hard part behind an interface, and is declared a success good enough “since no one can really check.” The fries are reliably good because someone can check them against a standard. The enterprise rollout is “successful” precisely because no one can deterministically do it.

So the hinge between theater and the real thing is not abstraction. It’s verification. McDonald’s commodified fries because fries can be measured. The drag-and-drop SQL tool is theater because nothing about the result is held to a checkable standard and it just relocates the work and bills you for the move.

This matters for our inversion principle because it tells you the one question to ask of anything claiming to commodify technical work: does it hide the complexity, or does it generate a result you can verify and own?

Inversion generates and verifies; it does not hide

This is the actual difference, and it’s mechanical, not rhetorical.

A failed commodification tool is a static abstraction, some kind of a fixed, human-authored layer that’s identical for every customer and adapts to none of them. It sits on top of the real system and obscures it. The SQL is still there; you just can’t see it, and you’ve signed a license to not see it.

Backend synthesis under the inversion does the opposite of hiding. It takes a declarative description of your actual target and generates the artifact to fit it. Then runs that artifact through a correctness gate before anything executes, differential-testing it against a reference. The generated AI kernel is the fries; the correctness gate is the thermometer Ludic’s mentor imported to graph the heat distribution in his oven. It is the thing the enterprise tool never had: a standard, and a measurement against it. Output you can check is output you can commodify.

And the artifact is yours. It isn’t a licensed layer you’re now married to; it’s a content-addressed, inspectable thing regenerated from a description you control. Ludic says that eight times out of ten he wants to pay a vendor to remove abstractions from his codebase, not add them. Inversion is on his side of that trade: the durable asset is the description and the generator, and the output is disposable and regenerable rather than permanent and rented. Remove it whenever you like; you can always synthesize it again.

That’s how inversion far advances the commodification of technical work. It supplies the missing ingredient - deterministic verification that separates real reproducibility from theater, and it removes complexity instead of hiding it. But “far advances” is not the same as “solves,” and the reason why is the most important part of Ludic’s essay.

What cannot be commodified, and why inversion shouldn’t pretend otherwise

Ludic’s deepest point is that a great deal of valuable technical work comes from somewhere that does not reduce to a process and connected with the human engineer, be it taste, judgment, the strange fact that every programmer has walked away from a problem and had the answer arrive in the shower. He invokes Rich Hickey’s Hammock-Driven Development, the workflow of feeding your subconscious a hard problem and praying the morning delivers. He points at his own uncle, who designs chips that go into iPhones, and notes that for all the industrialized testing and mass production around him, if that one man gets sick the release can actually slip.

He is completely right, and inversion does nothing to change it. Here is the line, as cleanly as I can draw it: what can be commodified is exactly what can be checked, and the vital spark is precisely the thing with no reference to check against.

There is no differential test for whether you chose the right experiment. No correctness gate for architectural taste, for knowing which of a hundred possible features is the one that matters, for the judgment that a result is interesting rather than merely correct. You cannot diff a hunch against a reference, because the reference is the thing the hunch is trying to invent. That work is uncheckable in principle, which is the same reason it can’t be commodified and the same reason it’s worth so much.

So inversion does not commodify the craftsperson. It commodifies the toil that currently steals the craftsperson’s hours - the porting, the glue code, the environment wrangling, the per-chip kernel rewriting, the integration plumbing. That is the widget work, and Ludic explicitly says he’d be glad to see it go. The promise of inversion is not “replace the engineer.” It’s “stop making the engineer spend three weeks making the model run on the new chip, so they can spend those three weeks on the part only they can do.” Commodify the toil, protect the craft.

The agentic harness is about to repeat the whole mistake

This is where it stops being abstract, because the industry is, right now, running Ludic’s failed experiment again at enormous speed and scale and calling it agentic AI.

The pitch is identical to the one he mocks, just with a newer logo: replace your expensive engineers with agents that generate the code for you. And it fails the same way, for the same reason. The agent emits code the way the drag-and-drop tool emits SQL; the complexity isn’t removed, it’s hidden behind a chat box; you’ve acquired a new opaque dependency; and the output is accepted because… ta-daaa - no one can really check. Most agentic harnesses today are commodification theater with a language model where the licensed abstraction used to be.

And agents make the checking problem worse, not better, in one specific way: they generate at a volume and speed no human can review. The enterprise tool at least produced output slowly enough that, in principle, a person could audit it. An agent will hand you ten thousand lines before lunch. A human-review bottleneck cannot scale to that throughput, which means “a senior engineer will check the agent’s work” is not a plan, it’s the exact “good enough, no one can check” failure, now running at machine speed.

So if you want to build an agentic harness that isn’t theater, the inversion principles are not optional; they’re the only thing that makes it work:

The harness has to verify, not just generate.

The correctness gate, tests, type checks, differential checks, constraint validation - has to live inside the harness as a hard boundary between what the agent proposes and what actually runs, because human review doesn’t scale to agent output. This is the separation we propose - non-deterministic planning, deterministic execution applied to software itself: the agent is allowed to be a creative, fallible proposer precisely because nothing it proposes reaches reality without passing a check. That boundary is what converts agent output from “good enough since no one looked” into something genuinely commodifiable, the same way the thermometer converts a hot kitchen into McDonald’s.

The harness has to produce owned, regenerable artifacts, not ephemeral transcripts. If the durable output of your agent is a chat log, you’ve built a slot machine: you depend on re-prompting and the value evaporates between sessions. The durable asset should be a verified, content-addressed artifact and the spec that regenerates it, so the work compounds instead of vanishing, and so you can throw the agent away and keep what it made.

The harness has to fit the task, not force every task through one frozen configuration. Today you contort your work to the agent’s context window and its fixed tool list. The inversion is to materialize the right tools, context, and agents for the specific problem and dissolve them after, so the harness adapting to the work rather than the work bending to the harness.

And the harness has to route the uncheckable decisions back to a human (or to some advanced symbolic system in the future), with the context to make them well. The point of automating the verifiable toil is to concentrate human attention on the part that has no correctness gate, i.e., what to build, whether it’s any good, rather than to pretend that part doesn’t exist. A harness that tries to commodify judgment is building the BurgerMaster 5000 for taste, and it will produce exactly what that implies.

The critical version

Ludic ends his essay by saying something braver than most people in this industry will: that he would genuinely welcome real commodification of this work, even at the cost of his own career, because some of these things are important and we can’t do them well yet. I believe that’s the right spirit, and I think the inversion is a real step toward earning it, not because it’s a clever new layer to sell an oblivious executive, but because it adds the one thing the failed tools never had, a way to check the result, and because it’s explicit about the line that check cannot cross.

Commodify the toil. Verify what can be verified. Hand the rest, with both hands, back to the person staring at the ceiling at 3 AM waiting for the answer to arrive. That’s the most a stack should claim. And if done right, it’s a great deal more than the industry has managed so far.