The AI-SDLC Operating Manual
There is no shortage of advice telling enterprises to move faster with AI. What I found missing, both in my reading and in my consulting engagements, is practical guidance on how to do it safely: with specs, quality gates, measurement, and ground rules that regulated businesses cannot skip. These are the frameworks I use in real engagements, shared here openly. I would love to hear how they hold up against your experience.
Start with speed vs. trust
Every AI adoption journey I have observed eventually runs into the same tension: the speed the tools promise versus the trust the business requires. I find a gardening analogy useful for explaining it to executive teams.
🪴 Potted plants
Quick AI wins are like potted plants. They look impressive in a demo, they move around easily, and they photograph well. But the roots are shallow. When production pressure, compliance questions, or team turnover arrive, they wilt.
🌳 The rooted tree
Adoption that lasts grows a root system first: behavior specs, review gates, measurement, and ground rules that respect your compliance reality. It is slower to plant, and it compounds for years. Speed you cannot trust is not speed. It is rework on a delay.
The AI maturity ladder: five levels, L0 to L4
The names describe how a person works with AI, not which tool they have. That makes one scale work for every role: engineering, QA, product, documentation, ops. In discovery conversations, most teams place themselves at L3. When we look at the evidence together, most are at L1. The gap matters because you cannot buy your way up this ladder. Each level gives AI more autonomy, more autonomy demands more trust, and that trust has to be earned by putting a specific safeguard in place first. Buying more seats moves nobody from L2 to L4. Writing specs and wiring gates does. Where would you honestly place your teams?
- L0
Bystander
No AI at all, or ad-hoc chat on the side. No leverage, and more teams sit here than admit it.
Earned by: Nothing. This is the starting point.
- L1
Assisted
AI completes what you were already typing. Minutes saved.
Earned by: Approved tools and clear data boundaries: what code and data the AI may see
- L2
Conversational
You ask, AI drafts, explains, and reviews, one request at a time. Hours saved, but still human-driven at every step.
Earned by: Working agreements, and human review of everything the AI returns
- L3
Delegator
You hand over whole tasks. AI plans, executes, and self-checks; you review the result. Days saved, and cycle time visibly drops.
Earned by: Spec-driven development: behavior specs signed off before generation, acceptance criteria running as automated tests
- L4
Orchestrator
You direct multiple AI workers in parallel and own the outcomes. Team-level capacity from one person.
Earned by: Named human approval gates on every lane, per-station measurement, and release decisions made on evidence
The jump that matters commercially is L2 to L3. Below that line, AI saves minutes and hours, which is nice but invisible in the P&L. At L3 a person stops asking AI questions and starts delegating work to it. That is where cycle time visibly drops.
Spec-based development: write it once, it never stops working
AI has made code cheap to produce. That, in turn, has made specs expensive to skip. Ask a model to "preserve all existing functionality" without a spec, and the model decides for itself what that means, from whatever files it happens to see. That is where silent invention and conversion defects come from. Spec-based development closes that door: a precise behavior spec, written before generation, that then works for you at four different moments.
The contract
Behavior inventory, edge cases, and acceptance criteria drafted before a line of code is generated. A lead signs off: a named human gate.
The checklist
Every item in the spec becomes a test or parity check. Verification is derived from the spec, not re-invented by QA. Green to merge.
The arbiter
A defect report becomes a diff against the spec. Code wrong, or spec wrong? Either way, fixed at the source.
The record
The spec and its test suite outlive the project as living documentation of what the system actually does.
This closure is what changes the economics. Without it, AI output is fast to generate and slow to trust. With it, the checking is generated, not performed. And there is a flywheel: every defect that escapes goes back to improve the spec template.
The migration factory
Legacy migration is the best enterprise use case for AI I have worked on, for a simple reason: the old system is the specification. And a factory beats heroics. Repeatable stations and per-station metrics turn a multi-year slog into a production line you can manage.
A factory is not one-click automation. People hold three named control gates: spec sign-off before any code is generated, an edge review during verification, and a release approval made on evidence. Between the gates, the work is AI-assisted and instrumented. Agentic autonomy inside a station, human judgment at the gates.
The measurement ladder
If you cannot measure it, you bought a demo. Most AI dashboards I review measure the bottom rung and declare victory. The business case lives at the top, and climbing the ladder is what separates a tooling rollout from a transformation.
The full operating model: every role climbs the same ladder
An operating manual for the SDLC cannot stop at development. Requirements writing, quality, documentation, and operations climb the same five levels, and in my experience the organizations that get durable results move these functions up together, not engineering alone. Here is what each level looks like in a normal work week, role by role. L0 is omitted, since "not using AI" needs no example.
| Role | L1 Assisted | L2 Conversational | L3 Delegator | L4 Orchestrator |
|---|---|---|---|---|
| Requirements (Product / BA) | AI polishes PRD and story wording | Drafts user stories and acceptance criteria with AI | Working prototypes instead of mockups: requirements as working code | Requirement to prototype to validation pipeline run by agents; the PM steers |
| Development | Tab-completion for boilerplate and syntax | "Explain this legacy module"; AI-drafted refactors and unit tests | An agent takes a ticket to a multi-file change with tests, arriving as a PR to review | Parallel agents build, test, and review; humans at checkpoints |
| Quality (QA) | Autocomplete inside test scripts | AI generates test cases and edge cases from requirements | An agent builds and runs a regression suite from a code change | Standing agents watch coverage gaps, regressions, and bug triage on every build |
| Documentation | Grammar and phrasing help | AI drafts runbooks and onboarding docs from existing sources | Docs generated from the codebase and kept in sync by an agent | Doc agents refresh runbooks and release notes every release; human sign-off |
| Ops / DevOps | Autocomplete in scripts and configs | AI explains alerts and drafts playbooks | An agent triages an incident: correlates logs, proposes root cause | Agentic monitoring detects, diagnoses, and remediates, with approval gates |
Every cell stays reviewable by a human before anything ships. The level changes who does the drafting, not who owns the outcome.
Common questions
How should a medium or large enterprise roll out AI coding tools safely?
Not tool-first, system-first. Assess where each team sits on the maturity ladder, introduce specs and quality gates before expanding autonomy, and instrument measurement from day one. Speed without verification is rework on a delay.
What is spec-driven development in an AI context?
It means writing a precise behavior specification before generation, so AI output can be verified against a contract instead of eyeballed. Written once, the spec works at four moments: the contract before generation, the test checklist after, the arbiter when a field defect arrives, and the living record after delivery.
Can AI really accelerate legacy migrations?
Yes. Migrations are the best enterprise use case for AI I have worked on, because the legacy system itself is the specification. A factory pattern makes the work repeatable and measurable instead of heroic: stations for scope, specify, generate, verify, and release, with human sign-off gates at the spec, the verification, and the release.
How do you measure whether AI adoption is actually working?
Climb the ladder: cost, usage, quality, outcome. Most dashboards stop at cost and usage. The signal that matters is at the top: cycle time, throughput, and the trend in escaped defects on AI-assisted work.
What changes for AI adoption in regulated industries like healthcare or finance?
The ground rules come first: approved-tool boundaries, data-residency and PHI/PII controls, human accountability at every gate, and audit trails for AI-generated code. The maturity ladder still applies. The gates are simply non-negotiable.
Bring this to your organization
I work with engineering leaders as a consultant and fractional CTO to assess maturity, design the rollout, and hold the measurement seat. If your organization is starting this journey, or is stuck somewhere in the middle of it, I would love to compare notes.
Schedule A Free Consultation