You Can’t Proofread a Prompt

Two decades ago the web learned that website copy can’t live in the codebase. Someone needed a headline changed, the change needed an engineer, the engineer was mid-sprint, and ninety seconds of work took eleven days. That lesson sold a generation of content management systems, and the workflow it produced is one of the few properly solved problems in our field: an owner, a review step, a preview, a publish button.

Now the same organizations are shipping AI features and reaching for that workflow to manage prompts. It half works, and the half that fails is the half that keeps you out of trouble.

What you actually ship

When you publish a page, you ship the output. The thing you approved in preview is the thing every reader receives, character for character, until someone changes it. Review works by reading, because reading is a complete simulation of what will happen.

When you publish a prompt, you ship an instruction. What the reader receives is generated later, by a system you don’t fully control, in response to an input you’ve never seen. You approved a cause. They receive an effect.

	A page	A prompt
What you ship	The output	An instruction
How you review it	Read it	Run it
Same input twice	Same result	Varies by design
Can change with no deploy	No	Yes

Most of what’s difficult about prompt governance falls out of that table.

Why the same prompt gives different answers

Worth understanding precisely, because most governance mistakes come from assuming one of these away.

Sampling. At any temperature above zero the model deliberately varies its word choice. Different outputs from identical inputs is intended behavior.

Temperature zero isn’t reproducible either. The model’s math is exact run to run; what varies is which other requests the provider happens to process alongside yours. That grouping changes the order the same numbers get added in, the order can shift a result by a rounding error, and once in a while that rounding error changes a word - and one changed word changes everything after it.

This is solvable. Researchers at Thinking Machines demonstrated the mechanism and the fix, and serving frameworks have started shipping it. It is not solved on a hosted API, where you don’t control how requests are grouped. Pinning temperature narrows the variance. It doesn’t buy you reproducibility.

The context isn’t fixed. In a retrieval system the prompt is one input and the retrieved material is another. Add a document, rebuild the search index, change how source material is sliced for retrieval, and the same question assembles different context and produces a different answer. No one touched the prompt.

The model moves underneath you. Providers update model versions. Behavior changes on their schedule, with no deploy on your side and no change you can read.

The input space is unbounded. A page has one rendering. A prompt faces every question anyone will ever type, in languages you didn’t plan for, including from people actively trying to break it.

What that breaks

Point a review process built for deterministic publishing at this, and four things fail quietly.

Preview is impossible. You can read the change you made. You can’t read the result, because the result doesn’t exist yet and won’t be the same twice when it does.

One successful test proves very little. You changed the wording, tried it, the answer looked good. That’s one sample from a distribution. The real question is how often it’s good across many runs, and that is a measurement.

Regression is silent. A change that improves the common case can degrade the rare one. In deterministic publishing, editing paragraph four cannot damage paragraph nine. Here it can, and nothing tells you.

You can’t list who was affected. Every bug ships consequences you can’t recall, and a pricing error charges real cards. The difference is the accounting afterwards. With deterministic code you can replay the broken path and know exactly what every affected user saw. With a prompt, every affected output was different and none of them can be reconstructed, so if you didn’t log them at the time, they’re gone.

What replaces proofreading

The content world’s answer is workflow: an owner, a review step, a publish gate. That part transfers cleanly and is worth having, because the person who should decide what the product says is usually not the person who can currently change it.

The part that doesn’t transfer is the safety model. Reading is a complete review of a page and a partial review of a prompt, so something has to sit where proofreading sat. That something is an evaluation gate: real cases with expected behavior, run on every change, publish blocked on the result.

It is simpler to start than it sounds. Twenty to fifty representative cases will catch the obvious regressions, including the ones that worry you most: the edge case, the hostile user, the question the system should decline. Expect that number to grow. A suite defending a system that talks to the public ends up in the hundreds, and it grows every time something gets through.

Run each case more than once. A single pass tells you the change can produce a good answer, which is less proof than it looks on a system that answers differently each time.

The person best placed to write those cases is the same domain expert asking for edit access. The clinician knows which questions must never get a confident answer. That knowledge is the eval set, and right now it lives in their head, unwritten, which is the real reason no one can safely hand them the prompt.

Then two things content never needed. Log what the system actually said, so “why did it answer that way” has an answer that isn’t a guess. And pin your model version, so behavior changing underneath you becomes an event you chose rather than one you discover.

The honest cost: the platform is a purchase, the cases are a practice. They need updating every time the product’s judgment changes. If you won’t build them, leave the prompts in the repo where an engineer at least has to read the change. Slow beats unguarded.

When this is worth doing

Two separate things are in play here and it helps to keep them apart. The ownership problem, where the person who understands the domain can’t change the words, is what makes you want a workflow at all. Nondeterminism is what decides whether that workflow is safe to give them. You need an answer to both, and they arrive on different schedules.

Plenty of teams should skip it. One engineer who owns both the domain judgment and the code, a handful of prompts, a file in the repo: that’s the right answer, and it covers most internal tooling and most early products.

It starts earning its cost at one point: when the person who should decide the wording isn’t the person who can change it.

It stops being optional when any of these are also true:

• The output reaches people you don’t employ. Customers, patients, students, applicants.
• You’d have to answer “why did it say that?” To a regulator, a journalist, a general counsel, or a parent.
• You have more prompts than you can hold in your head. Dead ones accumulate, no one deletes them, and eventually someone edits one that isn’t wired to anything.

One limit worth naming: none of this protects data your retrieval layer already handed the model. That’s scoping and access control, and prompt review is the wrong instrument for it.

What this looks like on a live build

We have a product in flight now whose whole value rests on a refusal. It exists to help someone develop their own thinking, and it will not do the work for them. Everything about whether it is worth anything sits on that line, and the line lives entirely in the prompts.

Which means a prompt change there is a change to what the product is for. So the prompts are versioned, observable artifacts rather than configuration, and the boundary is written down as cases and tested on every change. A change that would let the system cross the line fails before anyone sees it. When someone asks why it responded to a particular person the way it did, there is an answer.

None of that is fancy engineering. It is a workflow, a test suite, and a log. Most teams shipping AI features have none of the three.

The short version

A page is a promise you can keep by reading it. A prompt is a promise about behavior you haven’t observed yet, made to users you haven’t met, by a system that will answer differently tomorrow.

Take the workflow from content governance, because the ownership problem is real and we’ve been living it for two decades. Then replace proofreading with measurement, because the thing you approve is no longer the thing being delivered.