An experiment proves possibility, not practice
One engineer finds a prompt that helps plan a change. Another builds a local agent for test generation. A third uses an AI assistant to review pull requests. Each experiment may be valuable, but the organization gains little if the method, context, and lesson remain personal.
Repeatable practice begins when the team can describe the workflow, run it on real work, inspect the evidence, and improve it after failure.
DORA’s 2025 AI Capabilities Model frames successful adoption as a combination of technical and cultural conditions—not a purchasing decision. Read the model.
A six-step operating loop
1. Map the current workflow
Start with how work actually moves today, not how the process document says it moves.
For one value stream, identify the request, context sources, handoffs, queues, approvals, checks, and final evidence. Include the informal steps senior people carry in their heads.
The map gives the team a baseline. Without it, an AI experiment may optimize one activity while making the full flow harder to control.
2. Choose one visible constraint
Select a workflow with clear inputs and outputs and enough repetition to learn from. Good candidates include ticket refinement, implementation planning, pull-request review, regression testing, or release readiness.
Avoid choosing the most ambitious autonomous workflow first. Choose the smallest workflow that can produce a meaningful team-level lesson.
3. Define the operating boundary
Specify:
- approved context sources;
- the task the AI may perform;
- output format and acceptance criteria;
- required evidence;
- risks that require human review;
- the person accountable for the result.
This is the difference between “try the tool” and “run the workflow.”
4. Run it on real work
A demo is useful for learning the interface. It is not enough to reveal the organizational constraints.
Run the workflow on a real, bounded task. Keep the scope small enough that the team can observe the full path and intervene safely.
Record where the system lacked context, where the output was difficult to verify, and where the human handoff became unclear.
5. Review the whole outcome
Do not judge the workflow only by generation speed. Review:
- elapsed time and queue time;
- amount of rework;
- quality of the evidence;
- reviewer confidence;
- defects or missed requirements;
- cognitive burden on the people supervising the work.
The 2025 Stack Overflow Developer Survey shows why this matters: many developers report low trust in AI accuracy and frustration with outputs that are nearly—but not fully—correct. See the survey.
6. Improve and standardize
Turn the lesson into shared material:
- update the context;
- add or refine acceptance criteria;
- create a reusable prompt or skill;
- add an automated check;
- clarify the approval boundary;
- document a failure pattern;
- decide whether the workflow is ready to expand.
Then run it again.
The artifacts that make practice portable
A repeatable AI-SDLC workflow does not need a huge governance program. It needs enough visible structure that another team member can understand and run it.
Useful artifacts include:
- a value-stream or workflow map;
- approved context and source inventory;
- prompt and skill library;
- guardrail and approval checklist;
- acceptance criteria and evidence template;
- ownership model;
- experiment and adoption backlog.
These are working materials, not compliance theatre. If an artifact does not improve the next run, simplify it.
Two ways to start
A private AI-SDLC workshop is a focused way to map one constraint, build working setups on the team’s stack, and leave with a first operating pattern and adoption plan.
Adoption support fits teams that need to carry the loop across more than one workflow and build the habit of reviewing and improving it over time.
In both cases, the capability should remain with the team.