Which generative AI use cases actually work?

The generative AI use cases that work share three traits: being wrong is cheap, checking is fast, and volume is high. Text drafting, code drafting, summarisation, field extraction, classification and triage meet all three. Where one is missing, the pilot tends to stay a pilot, however convincing the demo was.

That is a claim about the shape of the task, not about the industry. The same company has cases that pay off and cases that don’t, and the difference is rarely the model. It’s worth reading alongside the list of where LLMs should not be used, which is shorter and more useful than it sounds.

The two most common starting points are also the best documented: customer support, where the queue and the review step already exist, and content at scale, where the gain is immediate and the trap is shipping without a checking step.

The matrix that decides

Two axes explain most of the wins and most of the failures.

The vertical axis is what being wrong costs. A bad headline suggestion costs a scroll. A wrong legal opinion costs a lawsuit. Between the extremes lies a wide band where an error costs a few minutes of review, and nearly everything that works lives there.

The horizontal axis is what a hit is worth. That isn’t the same as volume: a meeting summary is worth little per unit and a lot in aggregate, while an opinion is worth a great deal per unit and happens a few times a month.

The top-right quadrant is where generative AI pays off today without argument: cheap errors, high value. Code drafting, meeting summaries, ticket triage. The bottom-right quadrant is what produces the bad headlines: high value, expensive errors. It isn’t off limits, but it requires somebody to check before the output counts, and that somebody needs allocated time rather than goodwill.

A trap sits in the bottom-left quadrant, which looks harmless. Record correction and tax classification carry expensive errors and low value per unit. It is the worst place to start: the effort of building and maintaining is never recovered, and the first error consumes the credibility of the whole project.

What the evidence shows

It’s worth separating what was measured in experiments from what gets repeated in slide decks.

A pre-registered 2023 experiment assigned occupation-specific, incentivised mid-level professional writing tasks to 453 college-educated professionals, exposing half of them to an assistant. Average time fell 40% and rated output quality rose 18%. Inequality between workers decreased: lower-performing participants gained the most¹.

A field study of 5,172 customer-support agents, published in 2025, measured a 15% increase in issues resolved per hour, with wide heterogeneity. Less experienced agents improved both speed and quality; the most experienced saw small speed gains and small quality declines. Gains were largest on moderately rare problems, where the human agent has less practice and the system still has adequate data².

A controlled experiment with developers, also from 2023, asked participants to implement an HTTP server in JavaScript as fast as possible. The group with an assistant finished 55.8% faster³. It is a short, well-specified task, and the number does not carry over to maintaining a large system.

The work that sized the whole thing up, from 2023, scored US occupations by alignment with LLM capabilities. Around 80% of the workforce would have at least 10% of their tasks affected, and around 19% at least half. With access to the model alone, roughly 15% of tasks could be done significantly faster at the same quality; with software built on top of the model, that share rises to between 47% and 56%⁴.

That last contrast is the most useful finding here. The difference between 15% and 50% isn’t in the model, it’s in what was built around it.

Two honest caveats about these numbers. All of them come from relatively short, well-bounded tasks with an assessable result at the end; none measures a six-month project. And the models involved are from 2023, far weaker than 2026 ones, which pushes gains upward in any replication. What ages well in this work isn’t the magnitude, it’s the shape: bigger gains for people with less practice, smaller or negative gains for people who were already very good at the task, and an enormous gap between the bare model and the model inside a system.

The five families

Support is the most common starting point because the queue already exists and somebody already reviews. Chatbots, ticket triage and retrieval-backed technical support are variations on the same structure: understand the request, find what answers it, write.

Content is where the gain shows up fastest and where the quality decline takes longest to notice. Generation at scale, translation and summarisation work well per item and degrade in aggregate once nobody reads the output.

Data is the most underrated family. Field extraction from documents, classification and database cleanup are tasks with a verifiable answer, high volume and contained error cost, which is exactly the profile that pays off. It makes for a dull demo and a good result.

An example of the shape: pulling issuer, amount, due date and cost centre out of invoices that arrive in forty different layouts. Checking is structured, the extracted amounts can be summed and compared against the document total, and a rejected field goes back to a human queue instead of becoming a ledger entry. It’s the task where generative AI solved what fifteen years of template rules didn’t, and almost nobody talks about it.

Code has the strongest experimental evidence for short tasks and the weakest for maintenance. Drafting, review and migration behave differently, and migration depends most on automated tests already existing.

Decisions is the family that demands the most care. Personalised recommendation and queue prioritisation put the model’s output directly in front of the user with no human step. This is where the matrix in figure 1 has to be consulted before any code gets written.

The pattern behind the cases that work

Errors are cheap. A wrong output is discarded, corrected or ignored with no consequence outside the process. A bad draft becomes a rewritten draft.

Checking is fast. This is the condition that most separates pilots from production, and the one most often forgotten. Verifying has to be cheaper than producing from scratch, and it isn’t always. Checking whether a meeting summary is correct means reading the full transcript, which sometimes costs more than writing the summary. Cases with structured verification, such as field extraction with format validation and a check against the source document, are far easier to operate than free-text cases.

Volume is high. If the task happens ten times a month, the effort of building, evaluating and maintaining is never recovered. A production system carries ongoing maintenance cost, and volume is what pays for it.

The three hold together. High volume without fast checking produces errors at scale, which is the worst possible combination. Cheap errors and fast checking without volume make a good experiment and a bad project.

Where it doesn’t work

A single answer with consequences. A 2024 study measured legal hallucination by asking specific, verifiable questions about randomly selected US federal cases. The hallucination rate ran from 58% for the strongest model tested to 88% for the weakest. The models also frequently failed to correct a false legal premise embedded in the question, and could not always predict when they were hallucinating⁵. The numbers are from 2024 and have improved since; the shape of the risk has not.

A domain rule that must always hold. A 2024 benchmark put agents with tools and a policy document in conversation with simulated users. The best of the time solved under 50% of tasks, and the rate of succeeding on all eight attempts at the same task fell below 25% in the retail domain⁶. If your rule cannot fail once in eight, it cannot rest on reading alone.

Low volume with an expensive build. The case where the demo delights and the maths doesn’t work. Fifteen occurrences a month do not sustain a system with evaluation, monitoring and somebody on call.

Tasks where the human baseline is already near perfect. If the current operation errs 0.5% of the time, a system that errs 4% is a regression, even though 96% looks like a good number on its own.

Cases where nobody defined what a good output is. The most common failure and the least technical one. Without a written criterion up front, evaluation becomes a matter of taste and the project never finishes.

When the maths works out

Order-of-magnitude numbers, with assumptions on the table. An extraction task over a four-page document costs around 6,000 input tokens and 500 output tokens. At a thousand documents a month, that is a small infrastructure cost next to the salary of a person doing the same work, and it looks like the case is closed.

What usually isn’t in the calculation is everything else. The build takes two to eight weeks of somebody’s time. The evaluation set has to exist and be maintained. Human review keeps consuming time, less of it but not zero. And every model change or document format change means running the evaluation again.

The rule of thumb that survives: add inference cost, the review cost that remains, and about a sixth of a person per month for maintenance. If the number is still comfortably below the baseline, the case works. If it lands close, it doesn’t, because the estimate will err on the high side.

How to pick the first case

1. Look for a queue that already exists. Where there’s a queue there’s volume, a measured baseline, and somebody who already reviews. All three conditions get easier to satisfy at once.
2. Write the criterion for a good output before writing the prompt. One page, with examples of accepted and rejected output.
3. Measure the human baseline first. Time per item, rework rate, error rate. Without those three numbers there is no comparison afterwards.
4. Start with the simplest path. A well-written prompt solves more cases than people expect, and prompt engineering is the stage with the highest return before any architecture.
5. Put checking in the design, not in the pitch. Who checks, how much time they have, what happens when they reject.
6. Run alongside the current process for a few weeks. Replacing nothing, comparing output against output. It is the only cheap way to find what the demo hid.

Step 3 is the one almost nobody does and the one that decides whether you can defend the result six months later.

Footnotes

1. Noy and Zhang (2023) measured, in a pre-registered experiment with 453 professionals, a 40% drop in average time and an 18% rise in rated quality on professional writing tasks, with inequality between participants falling. ↩

2. Brynjolfsson, Li and Raymond (2025) followed 5,172 support agents and measured 15% more issues resolved per hour, with the gain concentrated among less experienced agents and a small quality decline among the most experienced. ↩

3. Peng et al. (2023) ran a controlled experiment in which the group with an assistant completed an HTTP server implementation 55.8% faster than the control group. ↩

4. Eloundou et al. (2023) estimated that around 80% of the US workforce would have at least 10% of their tasks affected by LLMs and around 19% at least half, with the share of accelerated tasks jumping from 15% to 47–56% once software built on the model is counted. ↩

5. Dahl et al. (2024) measured legal hallucination rates between 58% and 88% on verifiable questions about randomly drawn federal cases, and found the models frequently fail to correct a user’s false premise. ↩

6. Yao et al. (2024) measured under 50% success and under 25% success across all eight attempts at the same task in the retail domain, with agents following written domain policies. ↩