AI in the SDLC · Half-day briefing or two-day team workshop
Adopt AI across your delivery without merging code nobody understands.
For an engineering team and its tech leads putting AI into the SDLC (the software development life cycle: idea to shipped, tested code) and wanting to keep control of what comes out.
- Half-day or 2 daysBriefing or hands-on
- Your codebaseAnd your real workflow
- PrivateYour team, not a public room
- 70% practiceIn the two-day format
Register interest What the two days cover ↓
The workshop
- 1 Map your lifecycle How your team delivers today, and where AI has already arrived
- 2 Where AI fits Phase by phase: what it drafts, what it must never decide
- 3 Build the gates Design and merge review as your team will actually run them
- 4 Practice on real changes The five phases on your own code, hitting both gates
- 5 Policy and adoption Usage policy, risk register, 90-day plan
Your codebase and your workflow, all the way through
Ends in an adopted method: agreed · written down · scheduled
Half-day briefing: parts one, two, and five, without the hands-on build. Two days: all five, run on your own code.
Why this is different
The failure it is built to prevent
Speed is not the hard part. The failure is quieter: code gets merged that nobody fully understands, review thins out, and architecture drifts. You get speed this year and a black box the next.
Two gates that never get automated
Everything else in the method can take help from AI. These two cannot.
- 1FrameWhat is actually being asked for, and what would make it the wrong thing to build.
- 2DesignApproach and trade-offs written down before code exists. AI drafts options; the team chooses.
- Human gateDesign reviewA human signs off the approach. Nothing is generated against a design nobody has read.
- 3BuildImplementation with assistance, inside limits your team sets: what it may touch, and what it may not.
- 4ValidateTests, checks, and the security questions generated code raises. The team decides what passing means.
- Human gateMerge reviewSomeone who understands the change approves it. This is the gate teams quietly drop first.
- 5Ship & learnDeploy, watch what happens, and feed it back into how the next thing gets framed.
AI can accelerate every phase. It never owns a gate.
Where AI belongs in the lifecycle, and where it doesn't
It belongs in drafting: candidate designs, first-pass implementation, test generation, migration mechanics, documentation from code that already exists, and the tedious parts of review that are genuinely mechanical.
It does not belong anywhere the answer depends on knowing what this system is for. Deciding a design is right. Deciding a change is safe to merge. Deciding what a failing test means. Deciding that a shortcut is acceptable this once. Those are the places where someone has to be willing to be wrong and carry it, and that willingness is what the gates protect.
The two days are largely spent on the boundary between those two lists, because that is where teams actually get into trouble.
You can automate the making. You can partially automate the checking. You cannot automate the willingness to be wrong and bear the cost.
Your team leaves with
A delivery method your team runs
Five phases and two human gates, adapted in the room to how your team already works rather than imposed on it.
The controls around it
An AI-usage policy, a risk register, and prompt-template cards, written by your team during the workshop.
A 90-day adoption plan
What changes in week one, what waits, who owns each step, and how you'll know whether it's working.
The implementation option. If you want the method wired into your tooling rather than written down, we set up the GitHub side too: board, issue templates, validation checks, and agent automation inside your limits. Quoted separately.
How it’s taught
Real changes, not exercises. Your team works the phases on changes it would have made anyway.
Roughly 70% practice. Both gates get hit for real, in the review culture you actually have.
Led by
Samir Joshi
Systems architect, engineer, and former software engineering faculty member. Three decades building and leading production systems across India, the US, and Europe, including senior roles at Mastercard and Nokia/HERE, and long-term engagements for Fidelity and Pearson. His work now focuses on the architecture and judgement required to put AI systems into dependable production.
Attend
Two-day team workshop
Private · Your codebase · Online, in person, or hybrid
The main format, run on your team's real code and its real delivery workflow, under a mutually agreed NDA. About 70% practice.
Half-day executive briefing
Private · Leadership and tech leads
Frame, risks, and plan, without the hands-on build. The right size when leadership needs to agree a position before the team commits two days.
Register your interest and we’ll send the details, including price, with no commitment.
Before you commit
Why private, and not a public workshop?
Because the thing being changed is a team and its delivery process, not an individual. The method has to land on your repository, your review culture, and your release cadence, and a room assembled from six companies has six of each. A public cohort would have to teach the method in the abstract, which is the version that does not survive the first real change.
Our Agentic AI workshop runs as a public workshop, because there the unit of work is one person’s project and a mixed room is an advantage.
Our team already uses AI tools. Is this too late?
It is usually the better moment. Teams that have not started yet are working from opinions; teams already using AI have real evidence about what their tools do well, where review is thinning, and which changes are getting harder to reason about. The risk register and the usage policy come out sharper when they are written against what has already happened rather than what might.
If adoption is uneven across the team, bring that. The gap between the enthusiastic and the sceptical is usually where the useful conversation is.
This runs on our real code. What about confidentiality?
Private workshops run under a mutually agreed NDA, not ours as a take-it-or-leave-it. Your codebase and internal architecture are in scope, nobody from another company is in the room, and proprietary code never leaves your control: bring-your-own-key or local models throughout, on your own accounts.
Bring your codebase and your worries. Both are welcome.
Tell us where your team is with AI today and we'll suggest the smallest format that helps.
Register interestWant the briefing first? Get more details