i've been doing sdlc for 25 years. ai didn't kill it. it made it the coordination layer.
I've been shipping software for 25 years. design docs reviewed by thirty engineers before a line of code. spec reviews where someone meaner than me tore apart my threat model. change-management boards. SOX. on-call rotations where a bad 2am deploy meant someone's flight was missed.
so when people say "AI killed the SDLC," I flinch.
not because I'm precious about process. because I've seen what happens when you skip it at scale. the outage postmortem where nobody can find the design doc. the service with 200 endpoints and no contract because "we'll document it later." the migration that failed because two teams read the same requirement differently and nobody wrote down which reading was correct.
AI didn't fix that. AI made it worse — because now you can generate the appearance of rigor (a README, some tests, a docstring) without the substance (a decision, a contract, a traceable requirement). the model writes fluent prose. it doesn't write decisions.
last weekend I built loopguard, an open-source circuit-breaker library for LLM agent loops, using the same SDLC I'd use at any big-tech job: PRD, SPEC, WBS, issues, implementation, review, release. but I put AI agents inside every state.
here's what I learned: the SDLC didn't survive AI by dying. it survived by becoming the state machine that lets humans and agents multitask in parallel.
the setup
the project: loopguard detects when an AI agent is stuck in a loop — same test failing, same error repeating, bad JSON three times in a row — and escalates to a stronger model before the token bill spirals. drop-in decorator. LangGraph, CrewAI, or raw Python.
small library. real engineering: threat model, four test layers, OpenTelemetry hooks, prompt-injection sanitization, Pydantic config, fail-open behavior. 27 milestones. 54 GitHub issues. built over a weekend with a hybrid process.
the interesting part isn't the library. it's how it was built.
I used the same 8-state SDLC every well-run project I've been on has taken: problem, PRD, SPEC, WBS, issues, implementation, review, release. the difference from my old jobs: AI sat in every state. not as an observer. as a participant. I co-wrote the PRD with a model. the model drafted SPEC sections; I redlined. the model proposed the WBS; I approved. models implemented milestones. a model did first-pass code review; I triaged.
what stayed mine — completely, non-negotiably — were the decisions. what's in scope. what's a non-goal. which open question gets which answer. whether a deviation is a bug or an improvement. that's engineering judgment. the model is fast at everything except that, and that's the only thing that matters.
the spec is the one artifact you can't skip
if the PRD is the contract with the user, the SPEC is the contract with the implementer — and the reviewer, and future you. this is the document I see skipped most often in AI-assisted dev, and it's the one whose absence causes the most damage.
the SPEC takes a requirement like "the library MUST detect repeated identical errors" and turns it into pseudocode, data models, trigger evaluation order, Pydantic config schema with constraints, escalation flow as a numbered sequence. it also resolves the PRD's open questions — ten of them, each with a decision and rationale.
without that, the implementing agent makes those calls silently. you find out in review — or in production.
the SPEC is the document the agent is graded against. when the agent drifts — and it will — you don't argue aesthetics. you say "§2.2 says one GuardState per call; your implementation uses a shared one. fix it or amend the spec." ten seconds. the conversation without a spec is ten minutes and ends in "let me think about it."
I've had both conversations thousands of times. the ones with a spec resolve. the ones without fester.
26 bugs in two code reviews — and that's the point
after the agent implemented two milestones, I did a code review the way I've done thousands: read the diff, check against the spec, look for the failure modes I've learned to expect. I filed 26 issues. not one was a style preference. every one cited a SPEC section.
shared mutable state across tasks — the classic distributed-systems bug I've seen in a hundred codebases. non-atomic increments under concurrency. wrong event type for a log record. hardcoded values ignoring configuration. cost tracking that always reported zero because nobody extracted token usage from the model response.
these aren't "the model is dumb" bugs. these are the bugs any engineer makes moving fast without a contract check. the model is a very fast, very prolific junior engineer. you review its work the same way you review a junior's: against the spec, for the failure modes you've learned to anticipate.
one issue was interesting: the agent deviated from the spec, but the deviation was an improvement. I approved it and amended the SPEC. that's the thing about having a spec: it makes deviations visible. without a spec, the agent just does what it does and you can't tell a good deviation from a bug. with a spec, both show up as a diff from expected — and you decide which is which.
the multitasking this enables
here's what actually happened during the build, because state was maintained at each phase: I was reviewing one milestone while an agent built the next while I edited a doc for the release after that. not because I'm clever. because the state was explicit and addressable, so nobody was blocked.
the SPEC section is the briefing. the WBS dependency is the scheduling. the checkpoint is the gate. no standup required.
state is what makes parallelism safe. I've known this for distributed systems my whole career — you can't parallelize work without shared state that's consistent and addressable. same thing applies to human-agent teams. if the intermediate state lives in a chat log or someone's memory, you're sequential no matter how fast the model is. if it lives in a file with IDs and a status field and a git commit, you can have three things in flight.
at planet scale, this is how you ship. you don't have everyone in one room. you have contracts between teams, and each team works against the contract. the SDLC states are those contracts. AI doesn't change the need for contracts — it makes them more valuable, because now one side of the contract can be an agent.
what hurt
I'm not going to pretend this was all smooth. here's what actually hurt:
review overhead was real. 26 issues from two reviews. every one correct and valuable. but triaging, prioritizing, and verifying fixes was a meaningful chunk of my time. if you think "I'll let the agent self-review," you'll miss the bugs I found — shared state across tasks, non-atomic increments, wrong event classes. those aren't syntax errors. they're design errors. the model doesn't catch them because it doesn't hold the whole system in its head the way a reviewer with 25 years of scars does.
the bottleneck is human review throughput, not agent generation throughput. everyone's optimizing generation. nobody's optimizing review. that's the leverage. at big tech, I watched review become the constraint over and over as generation got faster. the same thing is happening with AI, just faster.
the METR randomized controlled trial showed experienced developers were ~19% slower on familiar tasks using AI tools, despite believing they were faster. the hidden cost: review and rework. the Google DORA report found the same thing at org scale. the fix isn't less AI — it's better state management so review is fast and verifiable.
spec drift is silent. the agent shipped a milestone with a design that deviated from the spec. good deviation — I approved it. but I only caught it because I read the PR. no automated check says "the code's control flow matches the SPEC's pseudocode." I want a spec-vs-code diff tool. until that exists, drift detection is a human job, and it doesn't scale.
what I'd tell you
the foundations — write down what you're building before you build it, review against the contract, gate your releases — are not obsolete. they're the thing that makes AI-assisted development engineering instead of gambling.
the SDLC is the context the model needs. a PRD/SPEC/WBS isn't bureaucracy. it's the prompt you write once for the whole project instead of re-explaining in every chat. I've onboarded hundreds of engineers. the ones with a spec ramped in days. the ones without ramped in weeks. the model is the same — just faster.
the traditional SDLC didn't survive AI by dying. it survived by becoming the state machine that lets humans and agents work in parallel on the same project without talking to each other.
I've been doing this for 25 years. this is the most fun I've had. not because the work changed — because the leverage did.
the full artifacts — PRD, SPEC, WBS, 54 issues with SPEC-cited review findings — are in the loopguard repo. the structure is the point. steal it.
discussion
I want to hear from teams doing AI-assisted development at scale, not solo experiments:
is the SPEC still the hardest artifact to get teams to write? I've watched engineers skip it for 25 years — AI makes the skip more expensive, not less. are your teams writing specs before agent implementation, or skipping straight to code? what's the friction?
where is your review bottleneck? the METR and DORA data both say AI slows experienced devs due to review burden. is that matching what you see? are you building review tooling (spec-check agents, diff-vs-spec linters) or accepting the review tax?
per-milestone model routing — is anyone doing this formally? I put the model assignment in the WBS. it worked. but I'm one person. does this hold up when a team of 10 is hitting the same WBS? who owns the routing decisions?
checkpoints as CI gates — who's enforced this? I enforced checkpoints by discipline. in a team setting, you need CI to block transitions. has anyone wired GitHub required checks to WBS milestone completion? I want to steal that pattern.
if you're building AI-assisted dev workflows with real process behind them — not vibe-coding, not blindly trusting the model — drop a comment with what's working and what's hurting. especially what's hurting.
Top comments (1)
Great...Don't you have any intention of working together to achieve something great?
Let's discuss for the future...