People often say this as if it were self-evident:
— AI can be an excellent executor, but judgment about the result must stay with a human!
It sounds confident and tidy. And every time I hear it, the same question surfaces: why, exactly, must?
Not «is it convenient?» — not «is it what we're used to?» — not «does it feel uncomfortable to let go?» — but this specific, unconditional “must”. What practical reason makes this obligation necessary? In many cases, it may be an untested assumption rather than a conclusion from practice.
What the «must» is actually protecting
A more precise question is what stands behind the word. When someone says judgment must stay with them, they rarely mean a technical constraint. More often the question is: why can't you, don't you know how to, or won't you offload this part to an LLM?
Three different answers, and none of them are comfortable. «Can't» means you haven't figured out how it's done. «Don't know how» — the same thing, stated more honestly. «Won't» — this raises a different issue, because behind «won't» is usually where incentives and role protection may be involved.
Yes, delegating judgment can be a nontrivial task. It may require explicit criteria, test cases, and review loops. But the persistence of the resistance — that's not about difficulty. Some difficult problems are worth formalizing when the payoff is high enough. Persistence is what happens when someone doesn't want to solve it, because the solution takes away something pleasant.
Model-as-a-judge — not frontier science, it's a vendor course
There is already a standard pattern for this, because «judgment can't be delegated» collapses against a simple fact: LLM evaluation pipelines often use the pattern called “model as a judge”.
Model as a judge — when a second model evaluates the output of the first. One model generates, the other judges. The exact «judgment about the result» that was just declared sacred human prerogative — moved into a separate, documented evaluation step, when the criteria are explicit enough.
This is not limited to research labs. Major AI vendors describe this pattern in their educational materials. It is used in production systems, especially for tasks with checkable criteria, by teams treating evaluation as an engineering problem. While some are explaining why only humans can judge, others have already automated the judging and moved on.
Where delegation is easier and where it remains hard
Honest about the boundaries, otherwise the argument becomes overstated.
Yes, technically there are nuances. They depend on what exactly you're sending to judgment.
- Code quality assessment — there are many mature tools. Linters, tests, coverage metrics, static analysis, benchmarks, a second model on review. Many aspects of code quality can be checked automatically.
- Generated image quality assessment — this one takes work. Taste, composition, «works / doesn't work» — hard to formalize, and it's more honest to admit that than to pretend everything is equally simple.
But between these two extremes many tasks fall between these cases. A range of intermediate cases already trivially implementable in any business. Text, reports, structured data, support responses, decision drafts — many recurring business tasks where evaluation can often be delegated if the acceptance criteria are explicit.
A more useful boundary is this: it exists, but it moves. It doesn't run between «human» and «machine.» It runs between «already formalized the criterion» and «haven't formalized it yet.» As tooling improves, more criteria become practical to formalize.
So, about that chair
The stronger claim is about incentives.
Asserting that a human simply must keep judgment to themselves is often too broad. Not because humans shouldn't make decisions — of course they will. But «must» in its universal, unconditional form is no longer about the work. It can function as a way to preserve authority without specifying which part truly requires human judgment.
The issue is this. «Judgment can't be delegated» isn't an observation about the nature of AI. It's a convenient default assumption for someone who noticed that execution was taken from them, and is rushing to stake out at least one function they are reluctant to delegate. Judgment got assigned as the last line of defense not because it can't be handed off — but because it is harder to formalize and therefore easier to defend as exclusively human.
How to test whether judgment can be delegated
The practical test is straightforward.
Stop asking whether a human must judge. Ask something else: what exact evaluation criterion am I holding in my head right now — and can I pull it out? If you can articulate what «a good result» looks like in your task — you can start turning it into an evaluation procedure. Then you can choose an implementation: a second model, checks, reference examples, or metrics.
What genuinely needs a human: setting the criterion itself, catching the case that doesn't fit, and deciding when the criterion needs to change. This remains a substantial responsibility. That's the actual level of judgment someone gets paid for. But it's specific work against a moving boundary — not a universal rule that applies regardless of task type.
The difference between the two positions is the difference between the person who pushes the boundary of what's delegable and the person who sits on their side of it explaining why it can't be pushed. One approach expands what can be delegated; the other treats the current boundary as fixed.
When someone says «judgment must stay human,» ask the real question: is this a task-specific requirement, or an assumption that has not been tested?