I have observability all over my AI coding stack. Every model call routes through a gateway that traces and logs every prompt, every token, every retry, every backup-and-try-again. I’ve built tooling on top of that to correlate Claude CLI sessions, reviewer agent sessions, and token usage with merged PRs — how many tokens went in, how many turns it took, how often I had to reset and start over. I describe myself as “annoyingly nosy” about this stuff. I don’t want a single token to hit a model without me seeing it.
Going back through my last ten projects, one signal has been impossible to ignore.
When I work in a domain I don’t know cold, I burn 10 to 15 times the tokens and run 5 to 10 times the review cycles I’d burn on something familiar.
That’s the dummy’s tax. That’s the bill the AI hands you for not knowing your shit. Nobody mentions it in the magical AI demos. The demos always feature someone shipping a SaaS in an afternoon, smiling like they just discovered fire.
I want to talk about why this tax exists, because once you see it, you can’t un-see it — and the moment you understand what’s happening, you can start refusing to pay it.
Where the Tax Comes From
The trap is upstream of the code. It starts at the spec.
You sit down with an idea you’re excited about. You don’t fully know the language. You don’t know the framework. You know roughly what you want the thing to do but not how it ought to be built. You open Opus, you open GPT, you start the dance. You iterate on the spec. You iterate on the plan. You and the model and another model and a different persona all agree it is gold. We’ve developed gold.
Then you build it.
And almost immediately you start deviating from your own spec. A library you picked behaves differently than you assumed. A pattern you committed to in section three contradicts a constraint you didn’t realize existed in section seven. You learn something. You go back. You revise. You learn something else. You revise again.
This is normal. Every project does some of this. But on projects where I don’t know the domain, the deviation isn’t a course correction — it’s a structural rebuild. The plan changes, the spec changes, the architecture changes, and three days in, you have something that doesn’t really resemble the document you started with.
Why It Compounds
When you write a spec for a domain you don’t know, you can only be specific about the parts you understand. The rest, you describe vaguely, because you literally cannot describe them precisely — you don’t have the vocabulary. So the model does what transformer models do. It fills in the blanks with the median answer. The middle of the road. The most likely next-token continuation, weighted by everything it has ever seen.
That, by itself, is not the problem. The problem is that those middle-of-the-road decisions become load-bearing. They get cited later in the spec. They get woven into the plan. They influence library choices, architecture, tests, naming. By the time you start writing actual code, the median is everywhere — and any flaw in any of those gap-filled decisions compounds outward through everything that referenced it.
The spec isn’t wrong. It just isn’t yours. It’s the model’s best guess at what someone like you, building something like this, probably wanted. That is a different document than the one you needed.
Jim Gaffigan has a bit where he describes ordering at restaurants: “I never know what I want, but I’m extremely confident about it the second I order.” That’s the LLM gap-fill in a nutshell. Decisive, plausible, and not actually based on anything. And once it’s on the menu, every other section of the spec orders around it.
How to Stop Paying
I’ve been combating this with the most boring intervention in the world: I learn the thing.
When I’m reviewing my own spec — my own spec, that I supposedly authored — and I hit something I don’t fully understand, I stop. I read the docs. I read the source. I write a one-page summary in Logseq in my own words. Then I go back into the spec and rewrite that section with what I now know. I do not let the model fill in the blank a second time.
This feels slow. It is, in fact, the opposite of slow. A two-hour learning detour up front routinely saves me a week of review-cycle thrash on the back end. The token bill — the actual one, in dollars — drops by an order of magnitude.
The signal is loud now: the human still matters. Not as the typist. Not even as the architect, exactly. As the person whose job it is to make sure the model is filling in around you, not instead of you.
That’s the only part of this that doesn’t scale. And it’s the part that decides whether the rest of it works at all.