Pilot AI on one real software delivery task

Use a live task with ordinary stakes

Run the pilot on work the team would do anyway: a bounded code change, test repair, migration slice, review task, or documentation update tied to delivery. Keep final acceptance with the normal owner.

Do not start with a showcase task written to flatter the tool. The pilot should meet the awkward context, incomplete inputs, and review pressure that shape daily engineering work.

Freeze the boundary before the first run

Write down the current workflow and the changed workflow side by side. Name what AI will do, what it may read, who reviews its work, and what stays out of scope.

Choose a baseline the team can collect without theatre. Waiting time, reviewer effort, rework, escaped defects, or acceptance on the first review may fit. Use only measures the workflow can actually support.

• A fixed task class and owner
• The same acceptance standard for the current and AI-assisted paths
• A versioned instruction and context package
• Named data, security, and human-review limits
• A stop condition for quality, risk, or operational disruption

Inspect the wider AI engineering control model

Run the workflow and keep the awkward evidence

Record prompts or instructions, relevant context, model and tool versions, reviewer changes, failures, retries, exceptions, and the accepted result. Keep the rejected attempts too. They often explain more than the clean final output.

Do not change three parts of the delivery system at once. If the workflow, model, team shape, and acceptance rule all move together, the pilot cannot tell you which change mattered.

Review the operating effect, not the demo

Compare the two paths. Did work wait less? Did reviewers spend their time on judgment rather than reconstruction? Did rework move earlier, disappear, or merely change shape? Note where the AI-assisted path created a new queue or control burden.

A mixed result is useful. It may support a narrower AI role, better context, a different review boundary, or a stop. Hiding the exceptions only postpones that decision.

End with a scale, revise, or stop decision

Name the next owner and the next boundary. If the effect holds and the controls are affordable, expand one dimension at a time. If evidence is weak, revise the workflow and rerun the comparison. If the cost moves elsewhere or the risk is unacceptable, stop.

When the workflow is worth changing but the team needs an external operator to define and run the intervention, the Activation Sprint is the existing delivery offer for that work.

See how the Activation Sprint works