In 2023, two economics PhD students at MIT ran a simple test. They gave 453 mid-level professionals — marketers, grant writers, consultants, data analysts, HR staff, and managers — access to ChatGPT and asked each of them to complete two writing tasks tied to their actual jobs. Half the group used the tool; the other half didn't.
The result, published in the journal Science by Shakked Noy and Whitney Zhang, was clear: people with access to AI finished the task 40% faster, and their final text scored 18% higher on quality. The people who did worst without help gained the most — the effect narrowed the gap between stronger and weaker performers, not just the average.
The most useful explanation for anyone deciding on AI at work isn't "AI writes better." It's this: it gets the person off the blank page. Editing a paragraph that already exists is a different job — and a cheaper one — than producing the first version from nothing. But that advantage depends on a condition that rarely makes the headline: review has to stay cheap once the volume of drafts goes up.
The ready-made draft changes the problem
The effect Noy and Zhang measured has a name in behavioral research: starting from something that already exists takes less cognitive effort than creating from nothing. The person stops deciding "what to write" and starts deciding "what's wrong here" — a narrower task, faster to finish.
That's why the gain showed up strongest for people with the least practice writing that kind of text. A junior analyst with no template for opening a report freezes on the first sentence; with a draft on screen, they already know what to do — cut what doesn't fit, adjust the tone, fill in what's missing.
The problem is that this reasoning stops at the draft. It says nothing about what happens next — when the person has to confirm whether what's on screen is actually true, whether the numbers add up, whether a claim about an internal process is the current version or an outdated one. That step has an unglamorous name and a very practical consequence: when it's expensive, the draft's advantage disappears.
When review costs more than it should
In 2025, METR — an organization that measures the real-world effect of AI tools on coding tasks — tested exactly this second half of the equation. Sixteen experienced developers, each working on open-source projects they already knew well, were assigned real issues randomly split between "AI allowed" and "no AI." In total, 246 tasks, each averaging about two hours.
The result flipped the expectation: the developers took 19% longer using AI than without it. Before the study, they expected to be 24% faster. After finishing — having lived through the actual slowdown — they still believed they had been 20% faster. Perceived speed and measured speed pointed in opposite directions, and nobody in the study noticed on their own.
The "State of Code" survey, from code-quality company Sonar, with 1,149 developers in 2026, shows the mechanism behind that result. 96% of respondents don't fully trust that AI-generated code is correct. Even so, only 48% say they always review it before approving it. And 61% agree with the statement "AI often produces code that looks correct but isn't reliable" — exactly the kind of error that's hardest to catch in a quick review, because it doesn't look like one.
61% of developers agree that AI "often produces code that looks correct but isn't reliable."
The most telling number in the report is another one: 38% say reviewing AI-generated code takes more effort than reviewing a human colleague's code. Only 27% say the opposite. That's not about AI writing worse code — it's about missing context. When a colleague writes something, you know who they are, what they usually get right, and where they tend to slip. With an AI answer that carries no visible origin, every review starts from zero.
What has to be in place
The fix isn't reviewing less, or reviewing more — it's making review cheaper. That depends on concrete mechanisms, not on the team trying harder:
Approved knowledge with sources. When an answer can cite where it came from — which document, which version, approved by whom — reviewing stops being "reconstruct from scratch" and becomes "check the source." That's the difference between investigating a loose claim and confirming a reference.
Two-step review and approval for what's critical. Not every piece of content needs the same scrutiny before becoming official AI knowledge — but what's critical (policy, process, a number that goes external) should pass through the person who writes it and, separately, the person who approves it, with exceptions logged.
An audit trail of who decided what. When an answer raises a question, the answer can't be "ask whoever remembers." There needs to be a record of when that content went in, who approved it, and what changed since.
Access scoped to each person's role. The narrower what each person and each agent can see, the smaller the universe of things anyone needs to review "just in case."
Reusing what's already been reviewed. A response template that's already been through approval once shouldn't require the same full review from the next person who uses it — it should inherit the trust of whoever already checked it.
That's how Skyller was designed: answers that can cite the source they used, two-step approval for what's critical, and a trail of who decided what — so reviewing means checking, not rebuilding.
From individual gain to team gain
When review is cheap, the ready-made-draft effect stops being individual and becomes collective. The person who figured out the right way to answer a recurring vendor question shouldn't have to keep that to themselves — the template can be reused by anyone authorized, without each person redoing the same review.
That's where the math changes: a company doesn't need to reinvent every process. An environment that already ships with more than 170 ready-made policy and process templates saves exactly the first review — the most expensive one, because there's nothing ready to check against yet.
The opposite is also true, and it's what the METR and Sonar numbers show: without that kind of structure, each person reviews their own way, with no idea whether the colleague next to them solved the same problem yesterday. The time that should have been saved on writing gets spent again, individually, on checking.
A starting checklist
Before buying another text- or code-generation tool, it's worth measuring where review is actually costing time:
- Measure how much time the team already spends checking what AI produces. If nobody can answer, that's a sign nobody is measuring — and what isn't measured tends to grow unnoticed.
- Ask where the last critical answer someone used came from. If the answer is "not sure, it just looked right," the problem isn't the AI — it's the missing traceable origin.
- Separate, for what's critical, who writes from who approves. Two people in different roles catch more errors than one person reviewing their own draft twice.
- Pick one process that repeats every month and solve it once. Once approved, it should be available to whoever needs it next — without repeating the full review.
- Treat the trail of who approved what as part of the process, not an extra. It's what turns a question into a minutes-long audit instead of a days-long investigation.
