A developer finishes a change before lunch. It then waits two days for review, needs another round of testing and sits behind a release approval. In that situation, faster typing would change only a small part of the journey.
This is an illustrative example, but it gives a useful starting point for an AI trial: follow the work from request to release. Find the delay or repeated effort you want to change before choosing a tool.
Follow one recent change
Pick a completed piece of work that people remember clearly. Trace how the request became a specification, code, a review, a test result and a release.
At each stage, separate time spent working from time spent waiting. A review might need twenty minutes of attention but spend a day in a queue. Those are different problems and call for different responses.
Ask the people involved what they had to find, repeat or clarify. Useful clues include a reviewer rebuilding context from several tickets, a tester asking which behaviour changed, or someone manually collecting release notes.
Match the experiment to the bottleneck
If reviewers spend time reconstructing the purpose of a change, test whether an AI-generated review brief helps. The brief could identify the requested behaviour, relevant files and available test evidence. A reviewer still needs to check whether that description is correct.
If documentation trails behind releases, try generating a draft from the actual change and the existing guide. Have the person responsible for the feature review it before publication. Measure how much editing the draft needs.
If the team spends time preparing repetitive test cases, explore whether AI can suggest cases from agreed acceptance criteria. Include unusual inputs and failure conditions. The useful question is whether the suggestions improve coverage without creating more maintenance work than they save.
These are candidate experiments, not claims that a particular product will deliver them well. The task, context and review process determine whether the output is useful.
Write a trial brief the team can challenge
A short brief should answer five questions:
- Which task are we changing, and who does it?
- What information can the tool access?
- What may it suggest, and what requires human approval?
- How will we compare time and quality with the current approach?
- What result would make us continue, change the approach or stop?
Keep the first trial within a defined repository or type of work. Agree permissions before supplying code or customer information. Retain the normal checks needed to accept a change.
Count the work after generation
A draft produced in thirty seconds can still take twenty minutes to correct. Include checking, editing and any later rework when assessing the experiment. Look at how the change affected the next person in the process too.
Choose one recent delivery task this week and draw its route through the team. The most useful AI opportunity may become obvious at the point where someone says, “I always have to do this bit again.”
For help deciding where AI fits in your delivery process, explore F3N’s Tech Consultancy / Fractional CTO support. We can review the workflow, challenge the assumptions and help your team choose a useful first change.