The Oracle Tax
Bret Horsting's dispatcher thought experiment is the sharpest version of an argument I keep circling. Two people, one system. The dispatcher can't read a stack trace. The engineer can't spot an illegal shift. Agents collapse the engineer's side of that asymmetry: the code gets written. The billing rule still pays wrong.
The conclusion Brethorst draws is correct. Domain expertise is the moat. What he underweights is what the moat is made of.
What judgment actually is
The dispatcher's oracle isn't a mental model built from reading labor law. It's a thousand reconciled payrolls, a hundred edge cases caught after the fact, a decade of watching what happens when the system does the wrong thing and someone downstream has to fix it. The knowledge is tacit in the precise sense: it lives in pattern recognition trained on lived failures, not in propositions that could have been studied.
This matters because the obvious prescription -- "go develop domain expertise" -- implies a path that's mostly blocked. You can read actuarial tables for a year. You still won't have the calibration an actuary gets from watching their own predictions fail in real markets. The gap isn't content; it's repetition under consequence.
Anil Madhavapeddy's concern about LLM-generated code is a related point from a different angle. His framing: confidence masking quality. Code that looks correct and passes casual inspection while being subtly wrong. The aesthetic of correctness decoupled from actual correctness. Domain expertise is what lets you look at a billing rule and feel that something's off before you can articulate why. Without it, plausible output and correct output are indistinguishable.
The asymmetry Brethorst identifies, restated
Pre-agent, the engineer had a slow path into domain knowledge. Go work in healthcare billing for five years. Learn what "coordination of benefits" actually means when a claim touches it. It was slow, but the path existed. The dispatcher had no equivalent path into software competence -- you couldn't grind your way to being able to read a stack trace by doing more dispatch work.
Agents removed the engineer's barrier, not the dispatcher's. The bridge moved, not the moat. A generalist engineer with an agentic coding tool can ship working software without domain expertise, which makes the software faster and doesn't make it more correct. The dispatcher's judgment is still the thing that determines whether the output is right.
That's the situation. The moat got wider, not because domain expertise got more valuable in the abstract, but because the thing that was partly substituting for it -- engineering effort as a screen for obvious errors -- got cheaper and therefore more common. More output, same oracle density.
The compression problem
Here's what the "go learn a domain" advice skips: the timeline is not compressible.
You can accelerate exposure. Read more, simulate more, work in the domain faster. But the calibration that makes judgment reliable comes from being wrong and finding out, repeatedly, with enough delay between prediction and outcome that you actually update. An actuary who runs models and sees results in years builds differently than one who gets instant feedback. The delay is part of the training. It keeps you honest about uncertainty in a way that fast feedback loops don't.
This isn't an argument that expertise is impossible to build. It's an argument that the speed at which agents ship output has no corresponding speed at which the judgment to evaluate that output accumulates. The pipeline accelerated; the oracle didn't. Someone still has to own the gap, and they have to earn it the slow way.
The dispatcher knew since their first year on the job that something about a certain shift pattern looked wrong before they could explain why. That feeling is the product. It took time to develop and there's no shortcut through it.