I've Been Doing SDLC for 25 Years. AI Didn't Kill It — It Made It More Useful.
TL;DR
I spent 25 years shipping planet-scale software — infrastructure and products used by over three billion people. Last weekend I built loopguard (soon to be open-sourced), a 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.
- When each phase persists explicit, addressable state (stable IDs, status fields, git-committed transitions, dependency graphs), an agent can pick up where a human left off — or vice versa — without a briefing.
- The bottleneck isn't generation. It's review. 26 bugs found in two code reviews, none catchable by self-review. That's where to invest.
- Per-milestone model routing (cheap model for boilerplate, frontier model for judgment) cut cost without cutting quality. The WBS was the router config.
- A SPEC with section numbers is the single highest-leverage artifact. It turns review from opinions into verifications. It turns spec drift from silent into visible.
The process isn't the past. It's the coordination layer that makes hybrid human-agent engineering scale.
The setup
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.
This post is what I did instead. And what I discovered: when you maintain explicit, addressable state at each phase of the SDLC, you can parallelize work across humans and agents in a way that pure vibe-coding can't. The process didn't slow me down. It became the coordination layer.
That's not forgetting the foundations. That's innovating on them.
The project, real quick
loopguard (soon to be open-sourced) 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.
from loopguard import Guard
guard = Guard(
max_retries=3,
escalation_model=ChatOpenAI(model="gpt-4"),
triggers=["test_failure", "repeated_error", "schema_invalid"],
)
@guard.protect
def agent_step(state):
return cheap_model.generate(state)
Small library. Real engineering: threat model, four test layers, OpenTelemetry hooks, prompt-injection sanitization, Pydantic config, fail-open behavior, PyPI release plan. 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.
The SDLC I actually used
This is the shape every well-run project I've been on has taken, from planet-scale storage to consumer apps:
- Problem — what's broken, who hurts, what does solving it cost
- PRD — what we're building and why
- SPEC — how it works, in enough detail that someone else could build it
- WBS — when each piece happens, what depends on what
- Issues — the WBS broken into executable units
- Implementation — code, against the SPEC
- Review — code checked against the SPEC and PRD
- Release — checkpoints, gates, go/no-go
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.
PROBLEM ──▶ PRD ──▶ SPEC ──▶ WBS ──▶ ISSUES ──▶ IMPLEMENT ──▶ REVIEW ──▶ RELEASE
(me) (hybrid) (hybrid) (hybrid) (hybrid) (agent) (hybrid) (me+agent)
Every doc state was hybrid: model drafts, I approve, commit records the transition. Implementation was agent-led with human checkpoint approval. Review was hybrid: agent finds, human triages. Release was mine.
The thing that made this not-chaotic: each state's output was persisted, addressable, and designed to be picked up by either a human or an agent. Not a Slack message. Not a doc in someone's head. A file in the repo, with a status field, with stable IDs, with a git commit marking when it was approved.
Key takeaway
AI in every state, human on every decision. The model drafts, you approve, the commit is the state transition. The repo is the project state — no external PM tool required.
The PRD: 765 lines, and why that's not excessive
At my old jobs, design docs ran 40 pages with appendices. 765 lines is a memo. But the length isn't the point. The structure is.
Stable IDs on everything. Every requirement is FR-1.1, every non-goal is NG3, every threat is T1, every open question is OQ-4. When the WBS says "implement FR-1.1, FR-1.2, FR-1.3," the agent doesn't interpret prose. It follows IDs into the SPEC, which expands them into pseudocode. When a review issue says "violates SPEC §2.2," there's no ambiguity.
In big-tech code reviews, the most common argument is "I think you should do X" vs. "I think Y is fine." Both are opinions. With a SPEC that has section numbers, the argument becomes "this doesn't match §2.2" — and that's not an opinion, it's a verification. IDs turn vibes into checks.
Explicit non-goals with a redirect table. Section 5.2 lists what loopguard will not do. Section 5.3 has a redirect table for feature requests that violate the non-goals:
| Expected request | Response | Redirect to |
|---|---|---|
| "Add pre-call model routing" | Out of scope — loopguard is reactive | TierForge, l6e |
| "Let the agent self-report confidence" | Out of scope — self-grading is unreliable | Use deterministic triggers |
This is what stops an agent from "helpfully" building a model router when you asked for a circuit breaker. Models want to please. A non-goals section is how you tell one no.
A status field and an approval commit. The PRD header says Status: Draft. When I was done:
d26a0d7 PRD approved — add perf benchmark methodology, dependencies policy,
naming & branding. Mark approved 2026-07-10.
That commit is the state transition. Draft → Approved. SPEC unblocked. No Jira ticket. No standup. The repo is the project state.
Key takeaway
Stable IDs + explicit non-goals + committed status transitions. IDs are the join keys between states. Non-goals are how you say no to an agent that wants to say yes. The commit log is your audit trail.
The SPEC: 1,243 lines, and why this is the one artifact you shouldn'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 FR-1.1 ("the library MUST detect repeated identical errors") and turns it into:
class FailureDetector:
"""Monitors GuardState steps and detects stuck patterns."""
def check(self, state: GuardState) -> Optional[TriggerResult]:
"""Run all enabled triggers. Returns the first trigger that fires."""
for trigger_name, trigger_config in self._trigger_configs.items():
if not trigger_config.enabled:
continue
result = self._check_trigger(trigger_name, trigger_config, state)
if result is not None:
return result
return None
Pseudocode. Data models. Trigger evaluation order. Pydantic config schema with constraints. Escalation flow as a numbered sequence. Threat-model mitigations mapped to requirements. Fail-open match statement.
It also resolves the PRD's open questions. Ten of them, OQ-1 through OQ-10, each with a decision and rationale:
OQ-1: Structured escalation prompt, not the informal "break the cycle" version.
OQ-7: Use LangGraph's nativeinterrupt()+Command(resume)when inside a graph.
Every OQ is a fork the PRD punted on and the SPEC nailed down. 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, I filed 26 issues — 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.
Key takeaway
The SPEC is the ground truth that makes review mechanical. Pseudocode, data models, resolved open questions. Without it, you're arguing opinions. With it, you're verifying against section numbers. Write it before you let an agent write code — same advice I've given about junior engineers for 25 years.
The WBS: a dependency graph, not a to-do list
1,134 lines. 27 milestones. S1–S15 implementation, M1–M10 go-public. Each milestone has:
- A dependency (
⚡ S2— S2 must be done first) - A model assignment (
🤖 LLM strategy: DeepSeek-V4-Flash — mechanical) - A task checklist with SPEC ID references
- A checkpoint table with concrete verification commands
### S3: Failure Detection ⚡ S2
🤖 LLM strategy: DeepSeek-V4-Flash — pattern matching logic is mechanical
#### Tasks
- [x] Trigger: repeated_error (FR-1.1) — compare error hash across last N steps
- [x] Trigger: test_failure (FR-1.2) — track test_results dict, detect oscillation
- [x] Trigger: schema_invalid (FR-1.3) — fire when False for N consecutive
- [x] Evaluation order per SPEC §3.3: custom → repeated_error → test_failure → schema_invalid
#### ▶ Checkpoint S3 ✓
| Check | How to verify | Result |
| All 4 triggers work | 47 unit tests pass | ✅ |
| Coverage ≥90% | pytest --cov-fail-under=90 | ✅ 99% |
Three things in there do serious work:
The dependency graph. Every milestone declares its dependencies. The WBS draws the full DAG and lists what can run in parallel:
Parallelizable: S6 (with S3-S4), S7-S8-S9 (with each other, after S5), S10 (with S7-S9), S12 (with S10-S11), S14 (with S13/S15)
That line is a multitasking license. S6 depends on S2, not S5. While an agent builds S5, another can build S6. No conflict — the dependency graph said so.
I've drawn these graphs on whiteboards my whole career. The innovation isn't the graph. It's that the graph is in the repo, next to the code, and an agent can read it.
Per-milestone model routing. Each milestone names its model:
| Model | Used for | Why |
|---|---|---|
| GLM 5.2 (strong) | PRD, SPEC, code review, prompt design, this post | Judgment work |
| DeepSeek-V4-Flash (cheap) | Scaffold, data models, detectors, decorator, integrations | Mechanical patterns |
| OMLX qwen2.5-coder:7b (local, free) | Cost logging, OTel, CLI, perf tests | Pure boilerplate |
Cascade routing applied to my own SDLC. The WBS is the router config. I'm the router. You can't do this if you're holding the whole project in one chat with one model. You need the work decomposed with complexity tags. That decomposition is the WBS.
Checkpoints as gates. A milestone isn't done when code compiles. It's done when the checkpoint table passes: tests green, ruff clean, mypy strict clean, coverage ≥90%. The checkbox state ([x] vs [ ]) is the persisted state of the milestone. Anyone — human or agent — reads the WBS and knows where the project is. No standup.
"Done" is a gate, not a feeling. I've been in too many ship rooms where someone said "I think it's done" and nobody could check. The checkpoint table makes it checkable.
Key takeaway
The WBS is three things: a dependency graph for parallelism, a router config for model selection, and a checkpoint ledger for state. Draw the DAG, name the model, gate the transition. Agents read it. Humans read it. Nobody needs a meeting.
GitHub issues: the WBS mirrored into an executable queue
Every WBS milestone became a GitHub issue with the same ID. S1 is #14. S3 is #16. The issue body is the WBS task list — same checklist, same checkpoint as acceptance criteria.
#16 S3: Failure Detection [implementation] CLOSED
Depends on: S2
WBS: docs/WBS.md#L156-L197
LLM strategy: DeepSeek-V4-Flash
Tasks: [the checklist]
Checkpoint: [the verification table]
Two views of the same state. The WBS is the human-readable plan. The issue tracker is the agent-executable queue. An agent picks up #16, reads the tasks, runs the checkpoint, commits feat: S3 Failure Detection — all 4 triggers. Commit closes the issue. WBS checkbox flips. Three representations, one state, in sync by convention.
When the issue body contains the spec reference and the checkpoint, the issue is self-contained. An agent doesn't need a briefing. It reads the issue and starts. That only works because the upstream states were written with stable IDs the issue can point to.
Key takeaway
Mirror the WBS into issues. Same IDs, same checklist, same checkpoint as acceptance criteria. The issue becomes self-contained — an agent can pick it up, execute it, verify it, and close it without a human in the loop until checkpoint approval.
Where review happened, and what it found
This is the part that matters most for anyone trying this at scale.
After the agent implemented S4 and S5, 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.
#42 BUG: Shared GuardState across all calls — no per-task isolation
File: guard.py:91-93
SPEC ref: §2.2 ("One GuardState per guarded call")
Impact: State from task A bleeds into task B. Triggers fire incorrectly.
#34 BUG: Thread safety — escalation_count += 1 is not atomic
SPEC ref: §9.3 (thread-safe requirement)
#45 SPEC DEVIATION: No internal retry loop — SPEC §7.1 for-loop removed
The agent shipped "one-call-one-step" instead of the spec's retry loop.
This was a BETTER design. I approved it and amended the SPEC.
#35 BUG: Fail-open logging uses CappedEvent (wrong event class) and
hardcodes fail_open_mode="raise_original" ignoring config
Issue #45 is the interesting one. 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 other 25 were bugs. Real ones. The kind that don't show up in a happy-path demo:
- 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.
Key takeaway
Review against the SPEC, not against taste. File issues with section citations, not chat messages. 26 bugs, zero style nits. A spec makes deviations visible — including the good ones you want to approve. Without one, you can't tell a bug from an improvement.
The multitasking this enables
Here's what actually happened during the build, because state was maintained at each phase:
| What I was doing | What an agent was doing | Why no conflict |
|---|---|---|
| Reviewing S4, filing #29–#41 | Implementing S5 (Guard decorator) | S5 depends on S4's interface, which the SPEC defines — not on S4's review output |
| Triaging S5 review issues #42–#54 | Drafting S6 tasks from the SPEC | S6 depends on S2, not S5. The dependency graph said so. |
| Editing the PRD for v0.2.0 scope | Implementing S3 unit tests | PRD edits don't touch the SPEC the agent is implementing against |
| Writing this blog post | An agent could be scaffolding the field study | S14 depends on S5/S7/S8, which are approved states |
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.
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.
Key takeaway
State replaces communication. When each phase's output is persisted, addressable, and self-contained, humans and agents work in parallel without briefing each other. The SPEC section is the briefing. The WBS dependency is the scheduling. The checkpoint is the gate. No standup required.
What worked
The SPEC was the single most useful artifact. Every review issue cited it. Every implementation agent read it. Every spec deviation was unambiguous. If you only take one thing: write a SPEC before you let an agent write code. I've been saying this about junior engineers for 25 years. Same advice.
Stable IDs made everything addressable.
FR-1.1,S3,OQ-7,#42. Review issues said "fixes §2.2 violation" instead of "the state thing is wrong." Agents implemented "FR-1.1" instead of "make it detect repeated errors." IDs are the API between humans and agents. The bugs that get fixed fast are the ones with a reproducible reference. The ones that linger are the ones described in adjectives.Checkpoints with real commands made "done" a boolean.
pytest --cov-fail-under=90,ruff check,mypy --strict. Not "looks good." A command that exits 0 or doesn't. Agents self-verify. Humans verify agents. No opinion.Per-milestone model routing cut cost without cutting quality. Boilerplate on a local 7B for free. Judgment on a frontier model. The WBS was the router config. Good engineering — match the tool to the task — applied to model selection.
Review issues as persisted state. Filing #29–#54 with SPEC citations turned review into a backlog an agent could grind through, not a conversation I had to have in real time. File ten issues, walk away, agent fixes them against the SPEC.
Key takeaway
What worked: SPEC as ground truth, IDs as the API, checkpoints as booleans, model routing per milestone, review issues as backlog. These are all old ideas. They work even better when one side of the process is an agent.
What 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.
State handoff format is fragile. Everything is markdown. IDs are enforced by convention, not schema. An agent wrote a commit that closed #42 and it worked — because I'd established the convention. But there's no compiler that fails if a SPEC section is referenced wrong. A structured intermediate (JSON sidecar with a schema, or even a linter for cross-references) would make handoffs robust enough for autonomous multi-agent orchestration, not just human-supervised.
Spec drift is silent. The agent shipped S5 with a design that deviated from SPEC §7.1. 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.
Checkpoints aren't auto-gated. The WBS says
▶ Checkpoint S3with a table, but nothing prevents proceeding if it failed. I enforced it by discipline. In a multi-agent setting, you need CI to block the transition — a real state machine, not a documented one. Big-tech CI gets this right with merge gates. AI-assisted dev needs the same.
Key takeaway
What hurt: review throughput (the real bottleneck), fragile markdown handoffs (convention not schema), silent spec drift (no automated check), unenforced checkpoints (discipline not CI). All four are fixable. None are fixed by a better model.
What I'd make better
Four things I'm building for the next project:
Automated spec-drift detection. Parse the SPEC's pseudocode, parse the implementation's AST, flag structural deviations. Even fuzzy — "SPEC §7.1 shows a for-loop; the implementation has no loop" — would have caught issue #45 in CI instead of in review. Highest-leverage improvement. At big tech, we had static analysis that checked code against design rules. Same idea, pointed at the SPEC.
A structured state schema alongside the markdown. A JSON sidecar:
{state: "SPEC", status: "approved", depends_on: ["PRD"], provides: ["FR-1.1"], open_questions: {"OQ-1": "resolved"}}. Markdown for humans. Schema for agents and CI. Handoffs become machine-checkable. An orchestrator can reason about the DAG without parsing prose.CI-enforced checkpoint gating. The checkpoint table should be a CI job. "Issue #16 cannot close unless
pytest tests/unit/test_detectors.pypasses with coverage ≥90%." GitHub required checks + issue-linked PRs get you most of the way. No state transition without its gate — for humans or agents.Agent self-review against the SPEC before PR. A review prompt: "Here is the SPEC. Here is the diff. List every SPEC section this diff might violate, with the section number." Run it before the human sees the PR. Doesn't replace human review — filters the easy stuff so I can focus on semantic bugs a spec-check can't catch. Like the fail-open event-class mistake, which was a meaning error, not a structure error.
Key takeaway
Four fixes, in priority order: spec-drift detection in CI, structured state schema, enforced checkpoint gates, agent self-review against SPEC. All four attack the same bottleneck — review throughput — by making the SPEC machine-enforceable instead of human-enforced.
What you can take from this
I've been doing this a long time. 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.
Make every state's output addressable. Stable IDs are how humans and agents point at the same thing. Without them, review is vibes. With them, review is "this violates §2.2" — and an agent can act on that.
Persist state transitions as git commits.
PRD approved,SPEC approved,S3 checkpoint passed. These are state flips. The commit log is your audit trail. I've inherited codebases where nobody could tell me whether a design doc was approved or abandoned. Commits don't have that ambiguity.Declare the dependency graph, then exploit it. If S6 only depends on S2, build S6 while reviewing S5. True for human teams, doubly true for human-agent teams — agents don't get bored context-switching. The teams that shipped fastest were the ones whose dependency graph was explicit.
Route models per task. The WBS's
🤖 LLM strategyline is where cascade routing meets project management. Cheap model for boilerplate. Strong model for judgment. Match the tool to the task.File review issues, don't chat them. An issue citing the SPEC section is resumable by any agent. A chat message is lost in scroll. I've seen too many review comments vanish.
The bottleneck is review. Budget for it. Build review aids — spec-check agents, diff-vs-spec linters — before you build generation aids. Everyone's optimizing generation. Nobody's optimizing review. That's the leverage.
Hybrid means stay in the loop on judgment. I co-wrote the PRD with the model but approved every section. I let the agent implement but reviewed every milestone. "AI-assisted" where the human is absent isn't engineering — it's outsourcing the decisions that matter. The stateful SDLC lets you be selectively present: deep in judgment, light in mechanical.
Key takeaway
Eight moves: SDLC as context, IDs as API, commits as state, dependency graph for parallelism, model routing per task, issues not chat, budget for review, stay in the loop on judgment. None of these are new. All of them work better when one side of the process is an agent. The foundations didn't become irrelevant — they became the coordination layer.
The bottom line
I didn't bring SDLC rigor into AI development because I forgot the foundations. I brought it because the foundations are what make AI development scale.
When you maintain explicit state at every phase — addressable, machine-consumable, gated, committed — you can have an agent implementing S5 in one window while you review S4 in another while a third agent drafts the next PRD. None of you blocked on each other, because the state is the coordination.
That's not waterfall. That's not vibe-coding. That's stateful hybrid engineering — the thing that works when the model can write the code but you still own the decisions.
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 — will be published when loopguard goes public. The structure is the point. Steal it.
References and further reading
Spec-Driven Development with AI: Get Started with a New Open-Source Toolkit — GitHub's own announcement of Spec Kit, the open-source tool that codified the Specify → Plan → Tasks → Implement workflow. The canonical industry statement that "vibe-coding" isn't enough and specs matter. My PRD → SPEC → WBS → Issues flow is the same shape, just with per-state model routing and committed state transitions added.
AI in the SDLC — IBM Think — IBM's overview of AI integration across every SDLC phase. Notes the shift to "AI-native development" and cautions against overreliance: "It remains a challenge for organizations to design workflows that capture the benefits of AI alongside the expertise and reasoning capabilities of seasoned human developers." This article is my answer to that challenge — the stateful SDLC is the workflow design.
SDLC AI Radar 2026 — LTM Research — Industry radar mapping AI's impact across the SDLC. Key framing: "The SDLC is undergoing its most fundamental restructuring since agile... Engineers are evolving from implementers to specifiers, verifiers, and orchestrators of intelligent systems." That's exactly what I experienced — I specified (PRD/SPEC), verified (review), and orchestrated (WBS model routing) while the agent implemented.
METR Randomized Controlled Trial on AI Coding Assistants — Randomized controlled trial showing experienced developers were ~19% slower on familiar tasks using AI tools, despite believing they were faster. The hidden cost: review and rework. This is the evidence behind my claim that the bottleneck is review, not generation. The stateful SDLC with SPEC-cited review issues is how you turn that review cost from a tax into a structured backlog.
Google DORA Report 2024 — Google's annual DevOps research report. The 2024 edition found that a 25% increase in AI adoption was associated with decreases in delivery throughput and stability for some teams, attributed to review burden and trust calibration. Same finding as METR, at org scale. The fix isn't less AI — it's better state management so review is fast and verifiable.
Spec-Driven Development: The Definitive 2026 Guide — BCMS — Comprehensive guide to SDD covering the three failure modes AI coding introduced: intent drift, context decay, and unverifiable output. My SPEC with stable IDs and section numbers directly addresses all three — IDs make intent explicit, the committed SPEC prevents context decay, and checkpoint tables make output verifiable.
Top comments (0)