AI SDLC · 2 min read
What an AI SDLC actually looks like
Adding a coding assistant to an old process is not an AI SDLC. Here is the lifecycle we run instead, stage by stage.
By [Founder name] · NeoMonarch
Most teams that say they have "adopted AI" have bolted a coding assistant onto a process designed for humans typing every line. Velocity goes up for a sprint or two, then review queues swell, defects leak, and nobody can explain why a change was made. The tool changed. The lifecycle didn't.
An AI software development lifecycle — an AI SDLC — starts from a different premise: most code will be drafted by AI agents, so the lifecycle must be designed around directing, constraining and verifying them. Here is how ours works.
1. Frame: humans own the outcome
Every piece of work starts with a person deciding what "done" means: the business outcome, the constraints (security, compliance, budget, latency), and what must never break. This is the part of engineering that AI accelerates least and that matters most. A senior engineer owns it, not a prompt.
2. Specify: write it so a machine can check it
Requirements become specs an agent can build from and a harness can verify: interface contracts, data models, acceptance criteria written as tests, and explicit non-goals. A vague ticket produces confident, wrong code. A precise spec produces code you can reject automatically when it drifts.
3. Build: agents in parallel lanes
Specialised agents take scoped tasks — an API endpoint, a migration, a UI screen, a test suite — and work in parallel, each in its own branch or worktree. Each lane has a narrow context: the files it needs, the conventions it must follow, the commands it may run. Narrow context is what keeps quality high as the number of lanes grows.
4. Prove: the harness decides, not the vibe
Nothing merges because it "looks right". Every change runs through the regression harness: unit, integration, contract and end-to-end tests, plus static analysis, dependency and secret scanning. A human reviews what the harness can't judge — design, naming, risk — with the evidence already in front of them.
5. Ship and run: deployment is part of the lifecycle
Infrastructure is code, deploys are repeatable, and production is observable from day one. Agents help here too — drafting runbooks, triaging alerts, proposing fixes — but under the same rules: scoped access, reviewed changes, audited actions.
What changes for the team
- Engineers become directors and reviewers. The scarce skill is decomposing work well and judging output fast.
- Tests become the specification. If it isn't tested, the agent will eventually break it — so you test it.
- The process is the product. Prompts, agent definitions, conventions and harness configuration are versioned assets, improved every week.
Where to start
Don't start with more agents. Start with the harness: a fast, trustworthy regression suite and clear conventions. Then add one agent lane at a time, measure what it ships and what it breaks, and widen from there. That is the order we followed building our own products, and it is the order we follow with clients.