Reimagining SDLC & Agent Economics
Restructuring the 5 SDLC phases with AI assistance, product opportunity scoring rubric, Capex vs Opex economics, and model routing strategies.
Reframe the delivery bottleneck
AI compresses implementation more than it compresses product judgment. Requirements, architecture, prioritization, and verification remain constrained by human decisions even when code can be generated quickly.
Traditional vs. AI-Driven SDLC
Same six phases, different bottlenecks and proportions.
Implementation
The longest phase; hand-written code.
Compresses to minutes–hours; the agent can self-correct mid-loop.
The traditional SDLC moves through requirements, design, implementation, testing, review, deployment, and maintenance as distinct phases. In the AI-driven version, implementation and feedback can happen continuously. A specification may produce a prototype in minutes, tests may run after every agent action, and failures can route directly back into another implementation attempt.
The PM implication is not simply a shorter timeline. It is a different allocation of effort:
- Requirements must state outcomes, boundaries, and edge cases precisely enough for an agent to act.
- Architecture remains a human trade-off because it includes business constraints and long-term consequences.
- Testing expands into evaluation of both the final output and the trajectory used to reach it.
- Review shifts toward assumptions, evidence, failure modes, and maintainability.
- Production feedback must improve specifications, context, tools, and eval cases.
When implementation becomes cheaper, unclear intent becomes more expensive. A team can generate the wrong thing much faster than before.
Specify every phase of the AI-driven SDLC
The phases have not disappeared; their work and evidence have changed. A technical PM should maintain one release contract that follows the feature from intent to production.
Trace the feedback agent across those phases. Requirements define “evidence-linked themes” and what counts as coverage. Architecture decides whether retrieval stays read-only and where source permissions are enforced. Implementation builds one bounded weekly workflow. Testing compares themes against a labelled set and inspects forbidden trajectories. Review checks assumptions and access changes; deployment starts with one product group and a disable switch. Maintenance adds newly observed vocabulary and failures to the taxonomy and eval set. The table below is the recap of that lifecycle, not six independent checklists.
| Phase | What AI changes | PM decision and artifact | Failure evidence and metric |
|---|---|---|---|
| Requirements and planning | Briefs can become user stories, edge cases, schemas, and interactive prototypes in minutes | Approve an intent spec with user outcome, constraints, assumptions, non-goals, examples, acceptance criteria, and open questions | The prototype looks useful but encodes an unapproved assumption; track clarification coverage and requirement defects found after implementation |
| Design and architecture | Agents can scaffold a chosen pattern consistently, but cannot own business trade-offs | Record an architecture decision for build vs. buy, consistency vs. availability, reversibility, data boundaries, and long-term owner | Generated modules are locally correct but create coupling or lock-in; track architecture exceptions and rework caused by missing decisions |
| Implementation | Multi-file changes and routine algorithms arrive quickly; human work shifts to direction and verification | Decompose work into bounded tasks with affected areas, allowed tools, invariants, and completion evidence | Large diffs hide hallucinated dependencies or scope creep; track first-pass acceptance, change failure rate, and review time rather than lines generated |
| Testing and QA | Agents can generate examples, edge cases, property-based tests, and run corrective loops | Maintain a test-and-eval plan covering deterministic outputs, non-deterministic quality, trajectory, adversarial cases, and regression gates | Final output passes while the agent skipped required checks or used a forbidden path; track task success and trajectory compliance separately |
| Code review and deployment | AI can perform first-pass review, summarize changes, monitor health, and trigger bounded rollback | Define a release evidence bundle: change summary, assumptions, test/eval results, security findings, rollout/rollback criteria, and human approver | Review volume rises faster than reviewer capacity or a false health signal rolls forward a bad release; track escaped defects, reviewer load, rollback precision, and time to detect |
| Maintenance and evolution | Agents can navigate legacy code, migrate frameworks, update deprecated APIs, and modernize tests | Keep a maintenance brief with invariants, migration slices, compatibility window, deprecation plan, and accountable service owner | A broad modernization silently changes behavior or expands technical debt; track regression rate, unsupported dependency count, recovery time, and maintenance cost per release |
Requirements should remain a conversation that produces both a specification and fast evidence, not a one-way document hand-off. Architecture stays human-owned because its trade-offs depend on organizational constraints and future strategy. Implementation speed is useful only when review and verification capacity scale with it.
Testing must evaluate both the output and the trajectory. Output eval asks whether the final artifact works. Trajectory eval asks whether the agent selected appropriate tools, respected required checks, and reached the result through an allowed path. A fluent success that bypassed security or verification is not a successful run.
Run quality as a flywheel:
- Evaluate representative tasks against an explicit rubric.
- Cluster failures by root cause rather than patching examples one by one.
- Change the responsible specification, context, tool, guardrail, or model route.
- Re-run the regression suite and compare both quality and cost.
- Sample production traffic for new cases and promote them into the eval set.
The release artifact is the evidence bundle, not the generated implementation alone.