In March, Cursor described training its coding model on how people respond to its suggestions (Cursor, 2026). One of the measures it reports has a plain name: agent edit persists in codebase. Read literally, it says the edit stayed in the codebase. It does not say the edit was correct, or that anyone read it closely.
An approval records that a person accepted an AI suggestion. On its own, it does not show whether they read it closely. When a dataset files that approval as a verified human label, a model can end up graded on answers it helped write.
Adapted from When Human Approval Becomes Data by Hyungyu Lee, on the CUBIG Tech Blog (November 2026).
Key takeaways
- In AI-assisted labeling, unless the label’s origin is stored, a person who keeps a suggested label leaves the same record as a person who reached that label alone.
- In a pre-registered ACL study, GPT-4 scored 0.47 against labels made without suggestions and 0.79 against labels made with its own suggestions on screen.
- As a training target, an approval records acceptance, not correctness. Stored as ground truth, the errors it let through can hide inside the measurement.
- A field recording how each label was made, plus a small slice relabeled without suggestions, gives a rough estimate of how far approved labels lean.
What is AI-assisted labeling?
AI-assisted labeling is a workflow in which a model proposes labels and people accept, correct or reject them. Labeling services can let a model label the items it is confident about and route the rest to people, and they offer separate jobs in which people verify existing labels. The approved labels often become training data, ground truth for an evaluation set, or both.
For the reviewer, the choice is lopsided. Correcting a label takes a decision and a few keystrokes. Leaving it can take neither, and a reviewer working through a queue faces that choice again and again.
How AI-assisted labeling can inflate evaluation scores
When a model’s suggestions shape its own answer key, the measurement becomes circular. A pre-registered experiment in the Findings of ACL tested this (Schroeder et al., 2025). Crowd annotators labeled passages from conversations, some on their own and some with a language model’s suggested labels in view, and the annotators who saw suggestions relied on them heavily.
Scored against the key built without suggestions, GPT-4 reached a weighted F1 of 0.47. Scored against the key built with GPT-4’s own suggestions on screen, it reached 0.79. The model had not changed. The answer key had moved toward it.
The authors are careful about scope: subjective tasks with more than one defensible answer, done by crowd workers. On such tasks, the gap shows how far a key can lean, not that the higher score is wrong. A 2016 study of grammatical annotation, a far more rule-bound task, found the same lean, with a parser looking better than it was once annotators anchored on its suggestions (Berzak et al., 2016). The lean favors the model behind the suggestions, so it can also tilt a choice between candidate models scored on the same key.
Why a human approval does not show who decided
An approval does not show whether the person would have reached the same answer alone. In a randomized trial in NEJM AI, 44 physicians who had just completed AI literacy training worked through case vignettes with ChatGPT suggestions. The group shown suggestions with deliberate errors scored 14 percentage points lower in diagnostic accuracy than the group shown correct ones (Qazi et al., 2026). They were free to reject what they saw, and they knew what to watch for.
Asking people later may not settle it either. In a Science study of choice blindness, people often failed to notice being handed the option they had not chosen, and explained why they had picked it (Johansson et al., 2005). At work, the volume adds up: Anthropic reported that Claude Code users approve nearly all permission prompts and called the pattern approval fatigue (Anthropic, 2026).
Training target or ground truth: where an approval goes
Where an approval is filed decides where its failures show. As a training target, the objective is plainly acceptance, not correctness. As a label in an answer key, it borrows the authority of human judgment that other checks rely on.
| Where the approval is filed | What it is called | What it actually records | Where its failures show |
|---|---|---|---|
| Training target | Acceptance, kept edit, accepted suggestion | A person accepted the suggestion | In model behavior the team can watch and correct, as when a reward invites overly cautious or sycophantic answers |
| Ground truth in an answer key | Human label, verified label | Often the same fact, stored as a human judgment | Inside the measurement, as a higher score that looks like success |
Approved data still has uses. Generated data filtered by a reasonable verifier can keep a model trained on it from degrading, and approvals can play that role to the extent they actually select for quality. An answer key is different, because errors let through by approval come back as a higher score that looks like success.
What a labeled dataset should record about each label
During review, a label’s origin can be recorded fairly completely. Amazon’s labeling service marks whether each label came from a person or from automated labeling, and its review jobs keep the original label beside the reviewed one (AWS, output data). The hard part is carrying that record into the table used for training or grading. The common dataset card template records how labels were made for the whole dataset, not for each label (Hugging Face, dataset cards).
The original piece proposes two modest steps: a field that records how each label was made, and a slice of the data set aside for relabeling.
- Record how each label was made, and keep that record. Use three values: made by a person who saw no suggestion, by a person who saw a model’s suggestion, or by a model. For the middle value, name the model and version and whether the person kept or changed the suggestion. Carry the field from the review tool into the training and evaluation tables, so a label a reviewer merely left untouched is not copied into a column called
verified. - Set aside a small random slice and relabel it without suggestions. For datasets used to measure or choose a model, have labelers like the originals, shown no suggestions, relabel the slice with the same guidelines. Then score each candidate model against both label sets.
Read the result as a rough estimate. The independent labels can be wrong too: new labelers’ slips and honest disagreement can widen the gap, while off-screen help from a similar model can narrow it. A value saying no suggestion was shown describes the tool, not the person, and neither step proves that a given approval was a real judgment. Together they let a team see the lean on its own data instead of assuming it away.
Why label origin matters for AI-ready data
AI-ready data is data a team has checked for a specific task under conditions it can repeat. A label’s origin is one of those conditions. The same F1 score means different things against an independent key and against a key the model helped write.
Syntitan’s Ready for Model compares a model before and after data preparation on the same evaluation records, and each prepared result is kept as a Version. Teams that want to run that kind of fixed comparison on their own table can try Syntitan Ready for Model. Which labels in the evaluation records came from approved suggestions is still a fact the team has to record.
Nobody undid it is a fact worth keeping. Somebody checked it is a different fact, and a dataset should be able to tell the two apart.
