# Same tool, same office: one person is running it, the other is being run.

> AI applications · 2026-09-17 · HTML 版（正本）：https://voidvector.tech/insights/who-overrules-the-model/
> 語言：en · 來源：voidvector（虛空向量有限公司）

The conversation has changed subject twice — first who uses AI, then how to use it well. Neither question separates anyone anymore. What still does is position: are you the one who decides what counts as right, or the one moving the model's output to the next box?

Open your chat history from this past week and scroll back. Find one time you sent the model's output back — asked for a rewrite, or gave up and did it yourself. If ten minutes of scrolling turns up nothing, that probably isn't a week of unusually good output. It more likely means you've stopped judging and started receiving.

The conversation around AI has changed subject twice. First it was who uses it, back when using it at all still told you something about a person. Then it was how to use it well — prompts, tool chains, workflow design. Both questions have lost their edge: everyone has the tools, and one search returns a page of technique. What still sorts people is position. In the workflow you're part of, are you the one whose call settles it, or the one who moves the model's output along to the next box? Put in blunter terms, that's the difference between owning the thing and working for it.

## Two people, the same tool, entirely different positions

The counterintuitive part is that fluency has nothing to do with it. Two people can run the same model, type nearly the same things, and ship at the same rate, while one of them is directing and the other is being directed. The difference isn't in the operating. It's in where the answers to three questions live: who defines what good looks like, who can send it back when it isn't, and whose name is on it when something goes wrong.

Standard, veto, consequence. Hold all three and the tool stays a tool no matter how strong it gets. Lose any one of them and however fluent you are, you're the fastest-moving segment of somebody else's assembly line.

*(圖：Figure 1: one workflow, two positions. On the top lane a person sets the standard first, which gives them something to send the work back against, and ships it under their own name. The bottom lane is missing the first box — which is why the third one can't hold either.)*

## The standard is what goes first, and it goes quietly

Nobody wakes up and decides to stop judging. It happens in an order, and the first box is the one that disappears without a sound: you stop writing down what passes before you see the output.

Setting a standard upfront is annoying work. You have to think through who this is for, what it has to accomplish, and which mistakes in it would actually cost something. Skip that step and the deadline still gets met, because the model delivers first and you react afterwards. But skipping it leaves you with exactly one yardstick — the output itself. All you can do is look at it and ask whether anything is obviously wrong.

And nothing obviously wrong is the thing these systems are best at producing. They rarely hand you something visibly broken. What comes back is well-formatted, confident, complete in its details, with one or two of those details filled in from plausibility rather than from the source. Without a standard set in advance, work like that sails through with no friction at all.

## A veto you never use stops being a veto

The second box goes slower and more completely. Saying no is a capability, not a button. You need to be able to see that something is wrong before you have anything to refuse, and that ability comes from having done the work yourself, often enough to have been burned by it.

Which sets up an uncomfortable loop. The less you do by hand, the harder it gets to judge what the model did by hand. The harder it is to judge, the more you accept. The more you accept, the less you do by hand. Automation bias has been studied in human factors research for decades — people given an automated recommendation lean systematically toward trusting it, and miss the errors it didn't flag. It isn't a new disease that arrived with AI. What's new is that it has reached the jobs we assumed were made of judgment.

*(圖：Figure 2: the veto only travels one direction (illustrative, not measured data). Each step down costs you some of the ability to judge the next one — and each step, taken on its own, is a perfectly sensible way to save time.)*

## Inside a company this is a process design, not a character flaw

At company scale, those individual habits get amplified or absorbed by how the work is organized, and most organizations amplify them. Three designs do most of the damage, and all three will look familiar.

The first is measuring an AI rollout by volume — proposals drafted, articles produced, lines of code shipped. Volume is the easiest thing to count, so volume becomes the goal, while review never gets budgeted as work at all; it's just something people are expected to fit in. The second is writing “AI drafts, a human signs off” into the process diagram and treating the risk as handled. The third is letting refusal cost more than acceptance: sending something back means another cycle, another meeting, an explanation of why you weren't satisfied, while approving it takes one click. Put those three together and the gate won't hold no matter how conscientious everyone is.

We ran the same arithmetic in our piece on self-writing knowledge bases: when the output curve and the review curve don't grow together, the gap between them is content that goes live unread. That piece was about a knowledge base. This one is about people. The mechanism is identical.

## Three questions you can test right now

None of this needs tooling. First, the standard: before you see the output, can you write three lines describing what passes and what doesn't? If you can't, what you're about to do isn't review — it's proofreading.

Second, the record: what did you send back last week, and how much effort did it take? If the answer is nothing, and you can't describe what the send-back path even looks like, then that gate exists on the diagram and nowhere else.

Third, the name: when this goes out and causes a problem, who answers for it? If the first answer anyone reaches for is “the AI produced it,” the position has already changed hands. Nobody has announced it yet.

## None of this is an argument for using it less

Reading the above as a case for cutting back gets it exactly backwards. People who barely use AI can be just as thoroughly run by something else — a template, last quarter's version, the way everyone around here does it. This has never been about volume. It's about whether the standard stays on your side of the table.

In fact, holding the standard is what earns you the right to use AI hard. When you know what good looks like, you can let it generate ten versions, because you can pick among ten and say why you picked that one. A tool's ceiling is the judgment of the person using it. That was true long before any of this; what's different now is that the tools finally got strong enough to make outsourcing your judgment feel like a reasonable trade.

The model isn't going to seize anything. It will keep handing over work that looks acceptable, right up until the day you can't be bothered to look. Until then, the person running it and the person being run by it use the same tools and sit in the same office. The difference is whether anyone actually read the thing before it went out, and whether that person had the standing to say no.