The AI-Native SDLC

The lifecycle begins not with a feature request but with signal ingestion. AI agents continuously scan customer feedback, support tickets, competitor launches, market reports, and internal usage analytics to surface problems worth solving.

The Discovery Agent synthesises these signals into structured problem hypotheses - each with severity score, addressable market size, and alignment to product vision. It generates "problem briefs" that a human product lead reviews and greenlights.

In a living product, this phase never stops. It runs as a background daemon, constantly feeding the backlog with prioritised, evidence-backed problem statements. New feature ideas, customer pain points, and market shifts all flow through this funnel.

The approved problem brief feeds into the PRD Architect, which generates a comprehensive product requirements document - not a vague wish list, but an engineering-ready blueprint.

The PRD covers: user personas, jobs-to-be-done, functional requirements, non-functional requirements (performance, security, accessibility), success metrics, and rollout strategy.

For a living product, the PRD Agent understands the existing product context. It reads the current codebase, existing specs, and feature graph to ensure new requirements are additive and compatible. It flags conflicts with existing features and suggests migration paths.

This is the keystone phase of AI-native development. The technical spec is not documentation - it's the executable contract that all downstream agents code against, test against, and validate against.

The spec includes: precise API schemas (OpenAPI), database migration scripts, component interface definitions, state machine diagrams, error taxonomy, performance budgets, and acceptance criteria written as machine-parseable assertions.

Critically, specs now include executable examples alongside schemas: canonical business scenarios, exception paths, migration cases, and explicit "never-do-this" boundaries that act as guardrails for downstream coding agents. Constraints like "never mutate this table directly" or "never call this API without a feature flag" are first-class spec content, not tribal knowledge. This makes the spec an operational contract, not a document artefact.

For brownfield products, spec writing depends on deep understanding of the existing system. The Domain Cartographer builds a living map of modules, business entities, configuration variants, and legacy touchpoints before any new spec is written. This is the bridge between "AI understands requirements" and "AI understands the shape of the existing product."

In a living product, specs are versioned and diff-aware. When a feature evolves, the Spec Agent generates a spec delta showing exactly what changed, what is backwards-compatible, and what requires migration. The spec becomes the living contract between product intent and code reality.

Spec-driven development means: no code gets written until the spec passes validation. No test gets generated without referencing the spec. No demo gets built that does not trace back to spec assertions. Drift between code and spec triggers automated alerts.

With a locked spec, the Architecture Agent designs the system topology. It selects patterns (microservices vs monolith, event-driven vs request-response), defines infrastructure requirements, and produces deployment architecture diagrams.

Critically, it reads the existing architecture and designs for integration, not greenfield. For a living product adding a new feature module, it identifies where the new service fits, which existing services need interface changes, and what infrastructure needs provisioning.

The output is an Architecture Decision Record (ADR) with rationale, alternatives considered, and trade-offs - all generated by AI, reviewed by a human architect.

This is where spec-driven development pays off. Coding agents receive the spec as their instruction set - not vague requirements, but precise schemas, interfaces, and acceptance criteria. The agents generate production code that conforms to the spec, follows existing codebase conventions, and includes inline documentation.

Specialised agents handle different domains: the Frontend Agent builds UI components with design system compliance, the API Agent implements endpoints matching OpenAPI schemas exactly, and the Data Agent writes migrations and query layers. Each agent operates within its bounded context.

For living products, agents understand the existing code graph. They don't generate isolated code - they integrate into the existing module structure, respect import conventions, extend existing test patterns, and follow established naming conventions.

Every PR triggers a multi-agent review pipeline. The Review Sentinel checks code quality, patterns, and conventions. The Spec Drift Detector compares implementation against the technical spec - any deviation triggers a review flag with the specific spec clause being violated.

This isn't just linting. Agents evaluate semantic correctness: does this API handler actually implement the spec's error taxonomy? Does this component respect the state machine defined in the spec? Are the performance budgets being met?

Human engineers review the AI's review, resolve edge cases, and approve. The loop tightens over time as the agents learn codebase conventions and reduce false positives.

Tests are not written after implementation - they're generated from the spec before code exists. The acceptance criteria in the spec are machine-parseable assertions that the Test Forge converts into unit tests, integration tests, and end-to-end scenarios.

The Chaos Agent goes further: it generates adversarial test cases designed to break the system. Invalid inputs, race conditions, malformed payloads, extreme load patterns. It thinks like an attacker, not a user.

For living products, regression suites grow automatically. Every new feature adds tests; every bug fix adds a regression test. The test suite becomes a living safety net that AI agents maintain alongside the code.

Critically, this phase now tests both the software artefact and the agent workflow that produced it. The Evaluation and Replay Harness turns past bugs, support tickets, and production incidents into reusable evaluation datasets. It replays agent workflows against known-good outcomes to detect regressions in agent behaviour, not just code behaviour. This is one of the most important maturity signals in an AI-native operating model.

Security is not a phase you bolt on at the end - it runs continuously from spec onwards. But this dedicated phase is the final deep scan before code enters staging.

The Security Guardian performs STRIDE threat modelling against the architecture, SAST/DAST scanning against the codebase, dependency vulnerability analysis, and secrets detection. For AI-powered features, it also checks for prompt injection vulnerabilities and model output safety.

The Compliance Agent validates against relevant frameworks (SOC2, GDPR, HIPAA, ISO 27001) based on the product's compliance profile. It generates audit-ready evidence and control documentation.

Beyond the phase-level gate, security governance now operates at the tool and action level. Shell commands, environment changes, and destructive actions are subject to explicit approval policies. Guardrails validate in real-time, and human review pauses the run before risky actions proceed. This is a fundamentally stronger control model than a single late-stage sign-off: every agent in every phase that touches sensitive resources operates within declared permission boundaries.

Before release, AI agents generate demo environments and stakeholder walkthroughs. The Demo Builder creates interactive previews with realistic sample data, guided tours highlighting new functionality, and before/after comparisons for iterative improvements.

The Staging Deployer provisions ephemeral environments per feature branch. Each PR gets its own staging URL with synthetic data, accessible to stakeholders for UAT without touching production.

For living products, demos include migration previews - showing existing users what will change, what's new, and what's been improved. This feeds directly into changelog and release communications.

Documentation is not written separately - it's derived from the spec, code, and tests. The Doc Weaver generates user-facing docs, developer guides, API references, and architecture overviews by reading the actual implementation.

For living products, docs are automatically updated when code changes. Every merged PR triggers a doc refresh - new endpoints appear in API docs, changed behaviour updates user guides, and deprecated features get sunset notices.

The system produces multiple doc types: end-user help (in-product and external), developer API docs, internal architecture docs, and onboarding guides for new team members.

The Release Captain orchestrates the entire release process: generating semantic version numbers, compiling changelogs, creating release notes for different audiences (technical, end-user, executive), and executing the deployment pipeline.

Release notes are not vague - they're generated from the spec delta + commit history + demo assets. Each change links back to the original problem brief, creating full traceability from customer need to shipped feature.

For living products, the Release Captain manages feature flags, progressive rollouts, and canary deployments. It monitors health metrics post-deploy and can trigger automatic rollback if anomalies are detected.

The lifecycle is a loop, not a line. Post-release, the Production Watcher monitors error rates, performance metrics, usage patterns, and user feedback. It detects anomalies, classifies issues, and routes them back to the appropriate phase.

A performance regression routes to Phase 7 (Testing). A spec deviation in production routes to Phase 3 (Spec). A new customer need routes to Phase 1 (Ideation). The system is self-healing and self-evolving.

The Feedback Loop Agent synthesises qualitative and quantitative signals into improvement proposals - closing the circle by generating new problem briefs that feed Phase 01. The product never stops evolving.