Adoption and Productivity

AI becomes economically real only when it changes work. A benchmark score is an input to adoption, not the adoption result. The result is the net value left after time saved, quality improved, review added, errors corrected, integrations built, and people trained. This chapter is the bridge between model economics and organizational economics: it asks when capability becomes productivity.

Capability is not ROI

The minimal adoption equation is:

$$\text{net value} = B(\text{time saved}, \text{quality lift}) - C_\text{model} - C_\text{review} - C_\text{integration} - \mathbb{E}[p_\text{error} \times L_\text{error}].$$

The first term is what the demo shows. The rest is what the deployment pays. Model cost is the visible one: it arrives as an API bill. Review cost is harder to see, since it shows up as senior time. Integration cost stays out of sight entirely, buried in the systems that need identity, logging, permissioning, data access, evals, and rollback. Error cost is the tail risk: the moment a fluent answer is wrong in a place where wrong is expensive.

Use the sliders below as the practical equation. A tool can save time and still destroy value if the review and rework tail is large enough; conversely a modest model can be profitable if it works inside a tight, well-reviewed workflow.

The jagged frontier

The best empirical frame is the "jagged technology frontier." Dell'Acqua and coauthors studied 758 consultants and found that GPT-4 access improved performance inside the frontier: workers completed 12.2 percent more tasks, completed them 25.1 percent faster, and improved quality. On a task outside the frontier, AI users were 19 percent less likely to produce correct solutions (Dell'Acqua et al. 2023). The result does not reduce to AI being good or bad. Adjacent tasks can sit on opposite sides of the capability boundary while looking similar to the user.

This matters because organizations rarely deploy AI to isolated benchmark tasks. They deploy it to workflows with mixed difficulty: a support agent answers common questions, then hits a rare account edge case; a developer writes a helper, then must preserve a project convention; an analyst drafts a memo, then must reason about a one-off contract clause. The value of AI is high where the model's competence and the reviewer's competence overlap. It falls where the model is plausible but the reviewer cannot cheaply tell whether it is right.

What the evidence says

The strongest adoption results are in bounded workflows with quick feedback. In a study of 5,172 customer-support agents, a conversational assistant raised issues resolved per hour by 15 percent on average, with the largest gains for less experienced workers (Brynjolfsson et al. 2023). The setting had several favorable properties: the task was repetitive but varied, answers could be checked against customer responses, and the system embedded assistance inside the work surface rather than asking employees to invent a new process.

Broader knowledge-work experiments are more mixed. A six-month randomized field experiment with 6,000 workers found that AI access mainly changed work that one person could change alone: users spent three fewer hours a week on email, while meeting time did not significantly move (Dillon et al. 2025). The result is important because meetings are a coordination artifact. A tool can help one person draft faster without changing the organizational routines that create meetings.

Software development shows the boundary sharply. In a randomized controlled trial (RCT) on experienced open-source developers working in mature projects, early-2025 AI tools slowed completion time by 19 percent, even though developers expected and later believed they had sped up (Becker et al. 2025). That does not imply coding assistance is unprofitable in general. It says productivity depends on project familiarity, review burden, codebase constraints, and task shape. A fresh script and a mature project are different economic objects.

Large-scale usage data from 2025 and 2026 points the same way: Anthropic's Economic Index, built from millions of anonymized conversations, finds use concentrated in a narrow band of well-defined occupational tasks (Anthropic 2025), and OpenAI's GDPval, which grades model output against real work deliverables from 44 occupations, finds models closest to expert quality on bounded, reviewable work products (Patwardhan et al. 2025). The heterogeneity remains; the data now shows where the value concentrates.

Adoption architecture

Treat adoption as a system design problem:

• Task inventory. Split work into task classes, not job titles. Label each by frequency, error cost, reviewability, and data sensitivity.
• Workflow placement. Put AI where the worker already acts. A separate chat window adds context transfer and hides provenance.
• Review design. Decide what must be checked before output leaves the boundary. The review step is not a tax after the fact; it is part of the product.
• Measurement. Measure cycle time, quality, rework, escalation, and worker trust. Do not measure only generated tokens or prompt count.
• Change management. Budget for training, policy, procurement, and rewritten routines. The model may be instant; organizational adoption is not.

The adoption test

Before buying a platform or building an internal model, run a controlled pilot at the task level. Randomize access where possible, and preserve a baseline. Count the review time and the rework. Separate novice users from experts. Track whether the process itself changes, or whether people only draft the same work faster. The pilot should end with a task map, not a general sentiment score.

Capability is becoming cheap. Change remains expensive. The organizations that capture value will not be the ones that put a model everywhere first; they will be the ones that find where the model changes the work without moving risk into a place no one can see.

Further reading