AI SDLC implementation
From individual AI tools to a shared team process. Build it on your own codebase, with our support.
- 3–4-month pilot
- 5 workshops
- Weekly support
Price on request · Model access is paid separately · excl. VAT and applicable taxes
Your process. Your team. Your AI harness.
Programme
Five workshops establish the process. Weekly support helps the team keep improving it until the final review.
Audience
Product, analysis, engineering and QA work together. Architecture, security and DevOps join from the first workshop.
What your team keeps
Rules, context, agents and checks in your repository, with internal owners who can develop the process after the pilot.
Your pilot, step by step
- 01
Prepare
1–2 weeks
Agree the scope, connect agents and take starting measurements.
- 02
Build together
5 × 4-hour workshops
Set up the process and run three real tasks.
- 03
Make it routine
1 hour each week
Your team delivers; we help improve the harness.
- 04
Review the result
2-hour final review
Compare results and decide what comes next.
3–4 months overall. We agree the calendar with your team.
What we build together
AI SDLC defines the roles of people and AI, the sequence of work and how results are checked. Its technical foundation is an AI harness: project context, specifications, agents and rules in your repository. Participants set up and test the process themselves so they can maintain and improve it afterwards.
A shared specification
Product, analysis, engineering and QA agree what must be known before changing code and how to check and approve the result.
Architecture, security and DevOps
These roles join every workshop. Their requirements become part of the harness and are checked on each task.
Rules in your repository
Agents and rules are stored in Markdown. Use them with Claude, Codex or OpenCode and adapt them when changing models.
The five workshops and ongoing support
Five four-hour workshops
Work in person with the team on its code and tasks. Between meetings, we read the repository materials and prepare the next workshop. Short explanations are introduced as the work calls for them.
1. Current and target process
Follow how tasks move through the team, where AI is already used and what gets in the way. Build a shared view in Miro and design the target process, including ownership at handoffs. Short explanations of AI development support the practical work.
Output: A process map, identified problems and an agreed way of working.
2. Specifications and agents
Agree a specification format for product, analysis, engineering and QA. Map the agents and describe their responsibilities. Participants build an initial AI harness in their own repository.
Output: A specification format, an agent map and the first version of the AI harness.
3. Three real tasks
Take three backlog tasks through specification, code, checks and pull request. While an agent works on one task, the team starts another or reviews the previous result. Record human interventions for review. Finish outstanding work before workshop four.
Output: Three tasks taken through the new process, with errors and initial metrics to compare against the baseline.
4. Review errors and improve the process
Run a postmortem: where did the agent go wrong, which context or rule was missing, and why did a check miss the defect? Update specifications, rules and agents. Agree required quality checks and owners for improvements.
Output: Changes to the AI harness based on the tasks, and a procedure for reviewing future errors.
5. Quality and the working agreement
Review testing of the AI harness, support duties and metrics. Assign maintenance responsibilities. Each participant confirms the working agreement: how to follow AI SDLC, check results and update shared rules.
Output: A team working agreement and named owners for maintaining the AI harness.
Weekly one-hour support as the team takes over
After the workshops, meet the internal owner each week until the final review. Review metrics, agent errors and changes to the AI harness, answer questions and agree the next improvements.
Between meetings, we follow the team’s work through its repository, help when problems arise and answer urgent questions. The team continues delivering its own tasks through the new process.
A two-hour final review
About two months after the workshops, compare results with the starting measurements. Review which practices have become part of daily work, revise the working agreement and decide whether to expand the pilot or change the plan.
What your team needs to start
Prepare one to two weeks before the start
We hold two or three setup interviews and record baseline metrics from the task tracker. Agree participants with the sponsor, including architecture and security. You arrange access; we help connect the agents. Participants need working access by the first workshop.
Four kinds of access
- AI models for every participant.
- The pilot repositories in GitHub or GitLab.
- The pilot projects in your task tracker.
- The relevant documentation in Confluence or another wiki.
Your company purchases model access for participants separately.
What the team keeps
- The AI harness: context, specification format, agents and rules.
- Experience running agents, checking results and improving the setup independently.
- A shared process map and a working agreement with responsibilities.
- Three real tasks taken through the process, and initial metrics compared with the baseline.
A sponsor, team time and internal owners
A leadership sponsor protects the team’s time for the pilot. Choose 1–3 people to own and develop the AI harness, including experienced colleagues the team trusts. Product, analysis, engineering and QA work together; architecture, security and DevOps join from the first workshop. A product owner defines business requirements and accepts results.
Start with one bounded area
Choose a project of moderate complexity and a defined area of code with an owner. Consider risk and how often it changes. Everyone who changes that area follows the new process. Keep existing roles and expand as the team gains reusable specifications, rules and experience.
A 3–4-month pilot
Allow one to two weeks for preparation, followed by five in-person four-hour workshops, typically one per week. Weekly support continues after the workshops until the final review. We agree the calendar, participants and scope during preparation. Price on request; model access is paid separately.
How agents work, and how people stay in control
From requirements to acceptance
Each stage passes the task’s specification, decisions and checks to the next. People approve requirements, the technical plan and release; agents perform the work within those boundaries.
Requirements
An agent gathers context from the task, code and documentation, and asks questions. The analyst or product owner approves the requirements and acceptance criteria.
Design and plan
An agent proposes the technical design and work plan. An engineer checks the design before implementation begins.
Code and tests
Agents implement the specification and run checks. Engineers remain responsible for the code and its integration.
Independent review
A separate agent checks the change against the specification and project rules. People resolve disputed findings and review higher-risk changes.
Acceptance and release
Agents prepare test cases and check neighbouring functionality. People decide whether the result is ready to release.
Turn errors into rules and checks
Trace each error to its cause: incorrect code, an incomplete specification, a missing test or a missing operational signal. Update the relevant part of the harness so future work is checked for the same failure. The team owns these improvements in its repository.
Build security into the process
Agree permitted models and data boundaries with security before work starts, including local models where required. Keep secrets out of agent context, check new dependencies and record agent actions. Changes involving access, payments, personal data or migrations receive security review. Work can stay within your own environment.
Measure the result before expanding
Agree success criteria and take starting measurements before the pilot. Compare the same measures at the final review; the results guide the next step.
Flow
Time from idea to production, including waiting between stages.
Autonomy
The share of changes completed without human intervention, and why agents hand work back to people.
Quality
Rework after review, defects found by users and releases that need to be reversed. Check adherence to architecture and code standards.
Cost per change
Model usage plus people’s time for each completed change.
Talk through your engineering workflow
Discuss AI SDLC implementation with your team.
Tell us about your delivery workflow and stack. We can discuss whether the programme fits your codebase and team.
Related training
All training options
Compare nine training and implementation programmes for leaders, employees, product and engineering teams.
Compare training optionsVibe Coding
Build a small work tool with AI in one day; optional mentoring is arranged separately.
Explore Vibe CodingAI SDLC for leaders
Design your team’s process, roles, knowledge, infrastructure and implementation roadmap over two days.
Explore leadership training