Vince Aaron GenodipaWhen a team first adopts an AI coding assistant, output goes up overnight. A few weeks later the questions start. Why was it built this way? Who decided we don't need rate limiting? Was this tested against the real flow, or just the happy path? The code arrived faster than the reasoning behind it, and nobody can audit reasoning that was never written down.
I hit this problem at a healthcare information company, where "move fast and break things" isn't an option. The answer wasn't less AI. It was more structure around it. Here's what worked.
1. The spec comes before the code
Most bad AI-generated code is a faithful answer to a vague question. So the very first stage turns the Jira ticket into a full requirements spec, using an adaptive clarification step that asks only what's actually missing, such as edge cases, acceptance criteria and constraints. Everything downstream is generated against the spec, not against a one-line ticket title.
If the spec is wrong, you've lost an hour. If the code is wrong, you've lost a sprint.
2. Every stage leaves an artifact
"The AI did it" is not an audit trail. Each stage writes a file a human can open:
- Requirements spec and effort estimate
- Architecture decision records (ADRs) grounded in the existing codebase
- A STRIDE-lite threat and abuse model
- Tests, including Playwright end-to-end coverage
- An observability checklist and feature-flag config
- QC reports where every claim links to evidence
Six months later, when someone asks why a decision was made, the answer is in the ticket.
3. Humans own the gates
AI proposes; engineers decide. The pipeline pauses at three approval gates:
- After requirements: is this the right thing to build?
- After architecture and threat modeling: is this the right way to build it?
- Before release: is the evidence good enough to ship?
Gates go where a wrong decision is expensive to undo, not on every step. Too many gates and people rubber-stamp them. Too few and you're back to trusting vibes.
4. Release is blocked until the evidence exists
The single most effective rule: a final QC stage checks that every required artifact exists and is consistent, and if anything is missing, release is blocked. No threat model? Blocked. E2E tests missing for a new flow? Blocked. It turns "we should have documented that" into something the pipeline enforces, not something people remember.
5. Make every release reversible
Even good process ships the occasional bad change. The pipeline enforces logging, metrics and tracing on new code paths and wires a GrowthBook kill switch, so a misbehaving feature can be turned off in seconds without a redeploy.
Don't forget the lite path
A typo fix shouldn't need an ADR. A lightweight path for small fixes keeps the full pipeline for work that deserves it, which is what keeps engineers from routing around the process.
Where to start
You don't need all fifteen skills on day one. Start with three:
- Generate a spec from every ticket before code, and keep it in the repo.
- Require one artifact per stage you already have, such as tests and a short decision record.
- Add one blocking check at release for missing artifacts.
Then add gates and stages where your team actually gets burned. The full nine-stage version, with all fifteen skills and an interactive demo, is in the AI SDLC case study.