AI for Business

What Changed When Software Began Producing Drafts?

Conventional business software often made an established process easier to repeat: enter information, apply specified rules, produce a report. Generative systems introduced another possibility: produce language, code or analysis from an instruction and supplied context. That makes some previously awkward tasks easier to attempt. It also moves work into deciding whether the proposed answer fits the actual situation.

In a September 2026 Stanford interview, economist and Digital Economy Lab director Erik Brynjolfsson advised thinking about tasks rather than entire occupations: “Almost no job is fully automatable, while almost every job has tasks that AI can change.” This is an expert’s framing, not proof that any particular role is safe or dispensable.

A useful first question is therefore specific. Could AI help prepare a support response, compare supplied documents or draft a routine update? That is easier to investigate than asking whether a company should become AI-first. The person checking the output may still need customer knowledge, commercial judgment and permission to make the eventual commitment.

Where Has AI Improved Work, and What Was Measured?

In the final 2025 study by Erik Brynjolfsson, Danielle Li and Lindsey Raymond, data from 5,172 customer-support agents at one business showed a 15% average increase in issues resolved per hour after AI assistance became available. Less experienced workers benefited more. The system suggested responses; agents remained responsible and could change or ignore them. This supports a particular assisted workflow, not a promise of 15% savings across a company.

Shakked Noy and Whitney Zhang’s 2023 writing experiment involved 453 professionals. ChatGPT access reduced completion time by 40% and increased evaluator-rated quality by 18%. The assignments did not reproduce real company context or require the factual verification many actual assignments need. Noy, then an MIT economics PhD researcher, cautioned that benefits could be “lesser in the real world because you need to spend time fact-checking and writing the prompts.”

The final Jagged Technological Frontier paper, published in March 2026, reports an earlier GPT-4 experiment with 758 BCG consultants. Within the tested capability boundary, participants using GPT-4 completed 12.2% more tasks and finished them 25.1% quicker. On one separate managerial task outside that boundary, AI-assisted participants produced correct recommendations about 19 percentage points less often. A tool can help with one stage and undermine the next; the outside-boundary result concerns one task, not all analysis.

Why Can AI Make Experienced People Slower?

METR’s July 2025 experiment tested 16 experienced open-source developers on 246 issues in familiar, mature repositories. AI-allowed tasks took 19% longer. Developers nevertheless believed the tools had helped. This was a snapshot of early-2025 tools and a specific setting, not a finding about every programmer or current AI system.

The accompanying update matters. In its February 2026 follow-up, METR judged newer estimates unreliable because developers and tasks were increasingly selected into the experiment, while parallel agents complicated time measurement. Researchers considered larger benefits plausible but had weak evidence about their size. The older slowdown cannot be presented as today’s universal answer.

The practical lesson is about measurement. A fast succession of suggestions can feel productive while creating extra inspection or correction. Equally, a person may use an agent’s waiting time for other useful work. Record active human effort, elapsed time and accepted quality separately. None of these measures should automatically stand in for the others.

Measure the Cost of Accepted Work

My starting point is the accepted result. A draft is a useful intermediate step; the business receives value when the work is suitable for its purpose. Include the effort needed to explain the task, collect context, generate an answer, inspect it, correct it and place it into the actual workflow. Count abandoned attempts too.

Consider a hypothetical example, not a client case. A task previously needed 45 minutes of drafting and 15 minutes of review: 60 minutes in total. With AI, drafting takes 10 minutes and review takes 25: 35 minutes overall. The saving is 25 minutes before tool and integration costs. Generation improved sharply, but review became more demanding.

Now change the assumption: suppose the reviewer must reconstruct the research or rework the output. The apparent saving can disappear. An honest pilot makes that work visible rather than moving it into someone else’s unrecorded time. Ask the receiving colleague what changed for them, including the effort to explain and repair mistakes.

When Does Saved Time Become Business Value?

A saved hour is capacity. It becomes a financial saving only when a real cost changes. A salaried team might instead answer more customers, clear a backlog or improve its work. Those can be worthwhile outcomes, but they should be described accurately. Do not multiply every saved minute by an hourly salary and call the result additional cash.

Build a separate cost record for subscriptions or usage charges, integration, staff training and ongoing support. Include the time of the person maintaining instructions and reviewing exceptions. Where mistakes have consequences, track the cost of investigating and correcting them. A cheap model can still sit inside an expensive process.

Compare the intended benefit with the alternative use of the same resources. Could a clearer template, better source data or a simpler approval process solve the problem? AI should earn its place in that comparison. My view is that adoption becomes more defensible when the team can explain which bottleneck improves and what new responsibility it creates.

For a repeatable comparison, calculate cost per accepted outcome: all labour cost, tool charges and an appropriate allocation of implementation cost, divided by accepted outcomes. Include the cost of rejected attempts in the numerator. This keeps the acceptance decision visible and avoids declaring success simply because the system generated more drafts.

How to Test a Workflow Before Expanding It

Choose a recurring task with enough comparable examples to reveal more than a successful demonstration. Specify what the accepted result must contain, what would make it fail and who can judge it. Use approved information and decide in advance which actions the tool may perform. Keep the first experiment narrow enough to understand.

Compare cases with and without assistance where practical. Avoid assigning only the easiest examples to AI. Include routine work and awkward exceptions, and record the difficulty and experience of the person doing it. Where feasible, have quality assessed without revealing which method produced the work. A time saving is easier to interpret when the acceptance standard stays consistent. Where practical, random allocation of comparable cases strengthens the comparison; otherwise document how the groups differ.

Record active effort, elapsed time, accepted quality, failures, rework and operating costs. Ask participants what felt helpful, but compare their impressions with observed outcomes. Define what would justify expansion and what would make you stop. There is no universal pilot duration or return threshold: the task’s frequency, risk and available evidence determine what is credible.

Who Remains Responsible When AI Does More?

Responsibility should follow the decision, not disappear into the tool. Name who accepts factual claims, who approves a customer commitment and who authorizes an external action. Giving an assistant access to more systems changes what it can affect. The permissions needed to prepare a proposal may be different from those needed to send, publish or execute it.

Choose checks that address the actual failure. A reviewer needs the relevant source information and enough expertise and time to challenge the output. A ceremonial approval button does not establish that a result was examined. Define how uncertain cases are escalated, how actions can be traced and what the team does when the system is unavailable.

The related analysis of OpenAI’s incident reporting examines disclosure and accountability; it is not evidence that every AI deployment has the same security problem. Likewise, Microsoft’s reported employee exit programme does not prove that AI caused the departures or established the programme’s commercial success. Keep a company announcement separate from the causal explanation you would like it to demonstrate.

What Might Change Next, and How Should You Respond?

If tools become better at gathering context and handling exceptions, some review costs may fall. If they become capable of acting across more systems, the consequences of an unchecked mistake may grow. These are scenarios to examine, not a forecast that businesses will follow one inevitable path. More capable software does not remove the need to understand its operating conditions.

The useful future indicators are close to the work: does accepted quality improve, does review effort fall, are fewer exceptions escalated, and can the team maintain the process? Also examine whether the task mix changes. A team may attempt more ambitious work after adopting AI, making a simple before-and-after speed comparison misleading.

Revisit the pilot when the model, permissions, sources or workflow change materially. Preserve enough records to understand the difference. For a sector-specific comparison, the AI in Game Development guide examines production, creative control and player trust. The shared question is whether easier output becomes a better product or service that someone is willing to accept.

What to Investigate Next

• Accepted quality improves without disproportionate review or correction.
• The pattern of difficult cases or rejected outputs changes.
• Model, access permissions, input sources or integration costs change materially.
• Saved capacity is demonstrably used, rather than merely estimated.