On this page

Better Quality

The report shows the hours AI saved. It says nothing about the person downstream who fixes the result. Nobody counted the fixing, so nobody can say whether quality rose or fell.

Definition

Better quality is freed capacity spent on preventing errors and on handling the hard cases where they start, so that less work comes back.

Work comes back as a correction, a reopened case or a customer calling again. So the test sits where the work lands, not where it leaves. The first sign is a fall in rework, reopened cases or defects.

The recipient is whoever receives or uses the output of a step. The customer is the person or organization whose outcome the work serves. A better result for the recipient is not yet a better result for the customer. The corrections can stop while the customer still gets a wrong answer.

The recognition pattern

  • The hours in the report come from the people who got faster. Nobody asks the people who receive the work how much of it they had to fix.
  • Experienced people spend more of their week correcting work than they did before the AI arrived. That time looks like helping out, so nobody logs it.
  • The same kinds of case keep coming back, and each case gets fixed as if it were the first.

Why the hours saved do not show the rework

The saving is counted where the work leaves

The hours get recorded at the desk of the person who got faster. The correction comes later, somewhere else, and often in another budget. So the report is accurate about the hours and blind to what followed them.

Nearly 40% of AI time savings were reported lost to rework in a vendor survey (Workday, 2026). That figure counts double-checking, so read it as a signal of size, not a measurement of waste.

AI can move quality either way

The jump in code written faded two months after open-source projects adopted the Cursor AI coding tool. But static-analysis warnings, the automated flags that a code-checking tool raises, stayed about 30% higher. Code complexity stayed about 9% higher, after allowing for the larger codebases. As the warnings and complexity built up, later work slowed (He et al., 2026). These are warning signs in the code, not defects that reached a user.

AI suggestions made Alibaba support chats faster and raised customer ratings in a randomized experiment. But how often customers came back with the same issue within three days did not change on average. For the top fifth of agents, ratings fell and more customers came back (Ni et al., 2026, working paper).

In another randomized experiment, BCG consultants using GPT-4 did better on tasks within its abilities. But on one task outside them, consultants without AI were right about 85% of the time, and those with AI 60 to 71% of the time (Dell'Acqua et al., 2026).

In a Swedish breast-screening trial, AI sent most mammograms to one radiologist instead of two and helped with detection. Radiologists' mammogram-reading work fell by 44% in the interim analysis. In the final results, cancers found between screenings were not more common with AI: 1.55 per 1,000, against 1.76 without, a difference consistent with chance (Lång et al., 2023; Gommers et al., 2026). That is one AI system in one program.

These studies differ in the task, the workflow and who used the tool. Look at those three in your own work. Which way quality goes has to be counted, not assumed. By default, nobody counts it.

Most of the rework comes from a few places

Software projects spent about 40 to 50% of their effort on avoidable rework, according to an older compilation by experts. About 80% of that rework came from 20% of the defects (Boehm and Basili, 2001). If your work has the same shape, evenly spread prevention is thin. But aimed at the few places behind most of the rework, it can pay.

Prevention has no visible output

Nobody gets thanked for the correction that never had to happen. Prevention produces nothing to point at, so freed time goes to work that shows. Capacity to Improve explains where that time goes instead.

What it costs when rework goes uncounted

The organization is reporting a saving it may already have spent. Any plan built on that report may count hours the corrections have taken back.

Experienced people turn into a correction layer, and the work they were kept for has to wait.

Customers meet the errors nobody caught.

Boundaries and distinctions

Not all rework is waste. Boehm and Basili separate avoidable rework from unavoidable, and some checking is the job. Count what could have been prevented.

This page is not a guide to review. It says where to spend freed time. General guidance on reviewing AI output belongs to Who Is in the Loop?

The capacity gain from less rework is reasoned, not measured. Work that does not come back is not done twice, which should free capacity. We found no study that measures less rework freeing capacity in AI-assisted work.

The evidence is strongest in software and screening. In other knowledge work, we found no study that measures what AI errors cost the people who receive them.

Example

Take a constructed example, the insurer in Where Freed Capacity Goes. Its claims handlers use AI to summarize each file and to draft the decision letter. The quarterly report shows about 2,000 handler hours saved.

Reopened claims go from about 6 in 100 to about 9 in 100, because more decisions are wrong. Those claims land with senior adjusters, the recipients, who spend about a day a week correcting decisions. Claimants, the customers, call back about decisions they cannot follow. None of that is in the report. A letter looks finished when it leaves the handler, and the report counts it as done.

Two lanes. In the top lane, where the report counts, the work runs from the handler to the AI draft to the decision letter sent, and ends at 2,000 hours saved. A vertical line at that point reads: the report stops here. The bottom lane, where the work comes back, runs on past the line. Two separate routes branch from the letter sent: the reopened claim, leading to the senior adjuster’s correction, which is the recipient’s work; and the claimant’s call, which is the customer’s experience. The saving is recorded before either route begins.
A constructed example. The report ends when the letter goes out. The work continues.

The adjusters sort one month of reopened claims, and three claim types account for about two-thirds of them. The adjusters' corrections show why. In those three types, the AI's draft letter never applies the policy exclusion that the decision depends on, so the decision is wrong. The rest of the letter is in order, so it looks complete. Handlers then spend part of their freed time on those three types. Before a letter goes out, the handler checks it against a checklist built from those corrections. For the worst of the three, the AI stops drafting the final letter.

The change has succeeded if the share of claims reopened falls, and complaints and escalations do not rise. And a sample of claims nobody reopened must show that claimants got the right decision.

Applied test

  1. Pick one kind of output that AI now speeds up. Name its recipients and its customers.
  2. Ask the recipients how often it arrives usable, needing no correction or follow-up question.
  3. Have them sort what came back last month by whatever shows a pattern: kind of case, team or channel. Name the few groups behind most of it. Ask what would have kept the largest group from coming back.
  4. Spend freed time on prevention only where the errors can be prevented. Decide how much time, who protects it, which measure should fall, and by when.
  5. Track the share of processed work that comes back. Track one measure of where the rework may have gone instead, such as complaints or escalations. The share can fall just because the rework moved.
  6. Take a sample of finished work that did not come back, and check whether it was right for the customer.

If you cannot move freed time yourself, take the recipients' answers to whoever can.

Sources and lineage

Better Quality is part of Applied Enterprise AI, a body of work developed by Curtis Hibbs and Joshua Barnes. The page draws on:


Curtis Hibbs and Joshua Barnes are co-creators of Applied Enterprise AI and Applied End-to-End Flow, and co-authors of the Applied End-to-End Flow book series. Their work combines enterprise diagnosis, value-delivery mechanics, and practical intervention patterns across strategy, portfolios, value streams, and teams.