When production is cheap, decide what to stop making

Before a team uses AI to produce more work, I want it to decide what it will stop making and who will answer for what remains. Cheaper drafting gives the team an opportunity to reconsider the work it commissions. Increasing output needs its own justification, including the capacity to check the result.

If drafts arrive faster than they can be checked, a team can accumulate unfinished work while reporting a rise in production. The effect on total effort has to be assessed across the workflow, including any time saved in review.

I would settle the following decisions before a trial:

Decision	What to settle
Stop	Which output or existing step can end, and who can authorise that change
Automate	Which remaining task has a checkable result, and where exceptions go
Review	Who answers for the result, what they check and how much time is available
Measure	The baseline, intended outcome and review point for the whole workflow

This sequence is my proposal for making an adoption decision. It has not been evaluated as a method. A task removed at the first step needs neither automation nor a reviewer. The work retained then determines which checks are needed, and those checks help define the scope of a trial.

The answers can also require an earlier decision to be revisited. If a result cannot be checked within the time available, the proposed task may need to be narrowed before the team tries to produce it faster.

Start with the work you can stop

Take a hypothetical team considering AI to produce a weekly marketing report. The current report repeats figures from a dashboard and adds commentary for a planning meeting. The proposal is to reduce the time spent preparing it.

Before deciding which tool could write the report, I would establish what the meeting needs from it. The team might be able to use the dashboard directly and retain only a short explanation of changes that require a decision. It might find that the full report serves a purpose the dashboard cannot meet. Either answer changes the work worth automating.

The decision needs an owner with authority to end the old output. Otherwise, a trial can leave the original report in place while adding a generated version that someone must also check. The adoption plan should state what will end if the trial succeeds, and who will make that change.

I cover the content-specific judgement in deciding what a page must achieve before publishing it. Here, the team decides whether the task still needs to be done in its existing form before making it faster.

Removal should not become a quota. A team with an unmet reader need may have good reason to produce more. It should still make an explicit decision about the work being retained, with enough review capacity for the proposed increase.

Define a result that can be checked

Once the team knows which work remains, it can choose the part to automate. A proposal to automate the whole report leaves too much unspecified.

Checking whether a table matches approved figures is a different task from checking an explanation of why enquiries fell. The figures have a reference against which they can be compared. An explanation needs evidence for the relationship it asserts. A fluent paragraph does not supply that evidence.

For the reporting team, extracting and formatting approved figures could be one bounded task. Drafting commentary could be another, with a reviewer responsible for checking its explanations. The team should decide what happens when a figure has no source or an explanation cannot be verified. That output might be withheld, narrowed to what the evidence supports, or sent to someone with the knowledge to resolve it.

The broader automation boundary in marketing operations is useful here: repetitive work is a stronger candidate when its rules are clear and the result can be checked. Work that looks repetitive may still depend on exceptions that require judgement.

Lisanne Bainbridge described a related problem in her 1983 paper ‘Ironies of Automation’. Automation can leave people handling abnormal conditions while reducing their opportunities to practise the skills those conditions require. Her subject was industrial process control, with aviation examples. Applying that caution to content work is an analogy, rather than evidence of the same effect in a marketing team.

For this adoption decision, I would ask whether the person receiving an exception will have the information and skill to resolve it. Routing a difficult case to a person is useful only if the arrangement gives them a reasonable chance of dealing with it.

Assign review before setting volume

The reviewer needs to know what they are accepting responsibility for. In the report example, comparing figures with the source and judging an explanation of a change may require different knowledge. Someone who can approve the layout may be unable to verify either.

I would name the person who can accept the completed report, specify any specialist checks they need, and reserve time for the work. Automated checks can assist them. Responsibility still needs to be clear when a check fails or the evidence leaves a claim unresolved.

There is some research on how this judgement changes with generative AI. In a 2025 CHI study, Hao-Ping Lee and colleagues surveyed 319 knowledge workers and collected 936 examples of AI use. Their accounts described thinking directed towards checking information, integrating generated responses and overseeing the task. Participants generally reported less effort across the thinking activities studied.

These were self-reports from regular users, including people describing marketing work. The study did not measure a team's review capacity or establish that total workload increased. It supports examining what checking remains; the recommendation to name an accountable person is mine.

The practical consequence for adoption is to agree the review arrangement before promising a volume of output. If the person checking the report has insufficient time, the team needs to reduce the scope, change the review arrangement or limit the trial.

The detailed decisions about AI review capacity and who can approve particular claims belong in the team's existing rules. The adoption decision needs to establish that those arrangements can support the proposed work.

Set the test before the trial

The team should define a useful result and record a baseline before changing the workflow. For the hypothetical report, that could mean reducing the total staff time needed for an accurate report used in the planning meeting. The team would need evidence about both preparation time and the report's use.

Timing only the drafting step would miss time spent correcting text, checking figures and resolving exceptions. Record the work through to acceptance. Separately, note which decisions the meeting used the report to inform. That record can help assess its purpose, although use alone cannot establish that the report improved the decisions.

Perceived savings deserve a check. In METR's July 2025 study, 16 experienced open-source developers completed 246 tasks in repositories they knew well. Tasks assigned to allow AI took an estimated 19% longer, while participants later estimated that AI had reduced their time by 20%. The study covered tools used between February and June 2025.

That is a dated example of perceived improvement differing from recorded completion time. In a February 2026 follow-up, METR judged its newer estimates unreliable because of selection and measurement problems, and considered larger productivity gains likely. Neither study predicts the result for a team producing marketing reports.

For a local trial, choose a review point and record what would justify continuing, changing or ending the arrangement. Compare work of similar scope and include the time of everyone involved in producing and checking it. A before-and-after comparison can inform the decision, but changes in workload or staffing may limit what can be attributed to the tool.

At that review, return to the first decision as well. If the trial justifies adopting the new process, confirm that the agreed old output or step has ended. Where there is too little comparable work to decide, keep the trial limited and record the missing evidence and next review date.

I would be comfortable with a trial that ended with less automation than the team first proposed. It may be worth keeping the help with figures and formatting while leaving someone to write the explanation. The report itself should still be open to question.