The prompt tax

I watched an engineer on a platform team build a prompt chain that turned a week's worth of flaky-test failures into a ranked list of quarantine candidates.

Six steps. Pull the CI logs, cluster by failure signature, cross-reference against the file's blame history, draft a one-line summary, assign a confidence score, post it to the team channel.

An hour of somebody manually scrolling through Datadog on Monday morning became eight minutes. A real win, and he was right to be proud of it.

Eight months later he was still the one running it. Manually, every Monday, between standup and his first meeting.

If he was on vacation, the list didn't get posted and nobody quarantined anything that week. If he left the team, the chain would survive about a month before the assumptions baked into step three started producing wrong output nobody would catch. The blame-history lookup expected a git log format that had already changed once, silently, and he'd patched it without telling anyone. Nobody else understood what step three was supposed to be doing.

The value is real. The mechanism holds it inside one person's Monday morning.

What the tax actually is

Call this the prompt tax: the recurring cost of operating an AI workflow, as distinct from the cost of building it. It isn't the model. It isn't the one afternoon spent getting the chain right. It's the price paid every single cycle, in time, attention, and organisational fragility, for as long as a human has to sit in the loop and translate.

Most teams can name two line items in that tax. There are six.

Translation. Someone takes a real, messy situation and turns it into language a model can act on. That's actual cognitive work, holding the mess in your head while you strip most of the mess out of the sentence, and the person doing it gets faster over time without the work ever going away.

Review. The model produces something. A human reads it, catches what's wrong, catches what's technically correct and somehow off anyway, corrects it or reruns it. This step is not optional. Nobody who's run one of these workflows for more than a month skips it, whatever the status update says.

Handoff. The output has to move from the tool that made it into the tool that needs it. A Slack post, a Jira ticket, a config file. Fifteen seconds here, twenty there, and it adds up to real hours across a team in a quarter, plus a steady trickle of small errors, because every paste is a chance to put the right thing in the wrong place.

Remembering to run it. If the workflow depends on a person remembering to kick it off, the cost of remembering doesn't show up on anyone's timesheet. It shows up as the low hum of cognitive load the owner is carrying from Sunday night through Monday morning, every week, whether or not anyone else knows it's happening.

Expert dependency. The chain works because the one person who built it knows which steps need a close look this week and which can run on autopilot, and that knowledge was never written down, because writing it down felt like overhead at the time. Hand it to a colleague cold and they get a materially worse result, for reasons neither of them can fully articulate.

Decay. This is the cost that shows up last and hurts most. The person who ran it moves teams. The chain rots, not all at once, but step by step, as the environment it assumed quietly stops matching the environment that exists. Nobody notices for a while, because the workflow keeps producing output. It's just gradually wrong output. By the time someone calls it dead, it's been functionally dead for a quarter.

Most teams price the first two. The other four get paid by the same person who's paying the first two, which is exactly why nobody notices the total until that person goes on parental leave or takes a new job.

Why templates don't fix it

The obvious next move, and the one I'd have recommended two years ago, is to build a shared library of prompt templates: parameterised, version-controlled, reusable across the team. It's not a bad idea. It's an incomplete one, and the gap between those two things is worth being precise about.

A template makes each cycle faster. It doesn't remove a single step. Someone still has to fetch the template, fill in the variables, send it, read the output, and move the result somewhere. The tax rate per transaction drops. The number of transactions doesn't, and in practice it tends to climb, because a cheaper workflow gets used more. A team I'd call a well-run one can build a library of forty-plus templates, watch individual cycle time drop by more than half, and still be paying roughly the same total hours a year later, because volume absorbed the savings. A faster horse is still a horse.

The alternative isn't a better prompt. It's an intent document the system reads directly, doing the translation once instead of every Monday. That's a different argument, made in full elsewhere on this site: the short version is that a prompt-based workflow has a low upfront cost and a flat, permanent recurring one, while an intent-based workflow has a real upfront cost and a recurring cost that's mostly maintenance. Over six weeks the prompt-based version looks cheaper. Over two years it almost never is, and most teams never make the switch precisely because they're optimising for the six-week window without noticing that's what they're doing.

What the number is for

The calculator below won't tell you whether a workflow is worth running. Plenty of low-volume ones clearly are; the tax on something run twice a month is small enough that formalising it would cost more than it saves. What it gives you is a real number for both sides of a comparison you're currently making on vibes: what you're actually paying to operate this thing every year, against what it would cost to write the intent down once and let the system carry it from there.

Most teams have never run this math on a single workflow they operate weekly. Pick one. Price it.