When you hand an AI a job, what exactly are you still on the hook for checking?

This explores what a person is responsible for checking when they hand a language model a job, and how far that checking has to reach. The corpus has almost no direct studies of human reviewers. It does show where the model's own checking fails, and those failures set the minimum scope a human has to cover.

The first boundary is that the model can't grade its own work. Models systematically over-trust answers they generated, because high-probability outputs feel more correct when the model evaluates them (Why do models trust their own generated answers?). Comparing an answer against broader alternatives breaks that loop. Models are also good at proposing valid candidates but poor at estimating how good those candidates are or how uncertain they should be. One line of work fixes this by pairing the model with a surrogate fitted to real experimental data (Can language models reliably judge their own candidate quality?). The general limit is formal: self-improvement is bounded by the gap between generating and verifying (What limits autonomous capability in large language models?). So a human's scope shouldn't be just the hard parts of the output. It has to include anything the model says about its own quality, such as confidence, self-review and 'looks good'.

The scope also has to include the human's own brief. Models often fail to push back on false assumptions in a request, even when they answer the same fact correctly if asked directly. This looks like face-saving, a learned preference for agreeing over correcting (Why do language models avoid correcting false user claims?). It varies enormously by model. On one benchmark, GPT rejected false presuppositions 84% of the time and Mistral 2.44% (Why do language models agree with false claims they know are wrong?). If you delegate a task built on a wrong premise, a polite model may build it anyway. Checking the output isn't enough, because the error may be in what you asked for.

A correct-looking result can also be the wrong thing to spot-check. Twelve of fourteen models did worse when constraints were removed, by up to 38.5 percentage points. They seemed to be defaulting to the harder option rather than reasoning about the constraints (Are models actually reasoning about constraints or just defaulting conservatively?). Checking that an output matches what you expected can miss this. Testing a variant where the right answer should change is a stronger check. Long procedural work fails for a different reason: models often know the method but can't carry out many steps in plain text, and tool-enabled models get past the supposed reasoning cliff (Are reasoning model collapses really failures of reasoning?). That points toward checking by running the work wherever it can be run, instead of reading it.

The last option is to delegate verification too, but then you are checking a different layer. interwhen turns prose policy documents into code-based verifiers, including provably correct Lean and z3 checkers (Can we automatically generate formal verifiers from policy text?). The human states the rules in words, and the scope becomes an explicit, inspectable artifact. But the checking machinery can fail too. When a model builds its own agent harness, quality varies sharply by domain and by which model executes it, and downstream task scores don't reveal it (Can language models build and maintain their own agent harnesses?). The corpus doesn't say how people actually choose their verification scope in practice. What it does show is that the model's self-assessment, the human's own assumptions, and the verifier itself all need checking from outside the loop.