# Choose the first AI workflow worth changing

A practical way to find one costly delivery workflow, test whether AI belongs in it, and define a pilot without starting a transformation program.

## Start with the work, not the AI tool

A tool demo makes almost any task look promising. Real work is less polite. Requests arrive incomplete, context lives in several places, and somebody still has to decide whether the output is good enough.

Pick one recurring flow and trace it from trigger to accepted result. Write down who touches it, where it waits, what gets redone, and which judgment cannot be delegated. That map is more useful than a catalogue of AI features.

[See the control boundary for AI-assisted engineering](/problems/ai-engineering-control/)

## Build the shortlist from operational pain

Look at the last few weeks of delivery work. The right candidate usually leaves a visible trail rather than a vague complaint about productivity.

- People repeat the same transformation of information across tickets, code, tests, reviews, or release notes.
- A scarce reviewer spends time reconstructing context before making the real decision.
- Rework appears late because the expected result was never made explicit.
- The workflow has a named owner, a recognizable input, and an accepted output.

## Use a hard filter before you score anything

Reject a candidate if the team cannot inspect its inputs, agree on an acceptable result, or stop the experiment without disrupting a critical path. A weighted score cannot rescue a workflow with no boundary.

For the remaining candidates, compare decision value rather than theoretical automation. Which pilot would settle a real argument about cost, quality, or ownership? Put that one first.

1. Name the trigger and the person who accepts the result.
2. Choose a baseline the team can observe before changing the workflow.
3. Mark the judgments and data that must stay under human control.
4. Set a stop condition before anyone starts building.
5. Confirm that the team can run the comparison on real work.

## Avoid the impressive but useless first pilot

A broad assistant for everybody sounds strategic and produces muddy evidence. A toy task produces a tidy demo and says little about delivery. A workflow that depends on unavailable data stalls before the AI is the interesting part.

The first pilot should be narrow enough to inspect and ordinary enough to matter. Boring is fine. You are buying a decision, not a stage performance.

## Finish with a workflow brief

Keep the brief to one page. Record the current path, its visible cost, the proposed AI role, the human review point, the baseline, the comparison method, the stop condition, and the owner who will decide what happens next.

Now the next step is concrete: run the workflow on real delivery work and compare the result with the path the team uses today.

[Continue to the software-delivery pilot guide](/field-notes/pilot-ai-in-software-development/)

## Next step

[Turn the chosen workflow into a bounded software-delivery pilot.](/field-notes/pilot-ai-in-software-development/)