The AI-Native SDLC: What AI Does and What Humans Decide

The AI-native SDLC is not the old lifecycle with AI doing the coding. It is all twelve stages, from idea to the learning loop, re-examined for what AI now does well and what must stay under explicit human control. Name a human decision point at every AI-assisted stage, gate AI changes with an evaluation in CI, and give every gate an owner on day one.

Consider an illustrative scenario, not a specific company: a team gave every engineer an AI coding assistant and measured pull requests per week. The number went up. So did the number of reverted merges, because nobody had changed the review process, the CI gates, or who was accountable for a bug that an agent wrote and a human clicked "approve" on. The lifecycle didn't get faster in a way that mattered. It got faster in the one place that had no new controls.

The AI-native SDLC is not "the old SDLC, but the coding part is done by AI." It's every stage (idea, requirements, architecture, coding, testing, review, security, CI/CD, deploy, observability, incident response, and the learning loop back to idea) re-examined for what AI now does well, what actually changes as a result, and what has to stay under explicit human control regardless of how good the tooling gets.

1. Idea

Without AI: ideas come from customer interviews, support tickets, roadmap debates. They're slow to surface, faster to validate once written down.

With AI: an assistant can summarize support tickets, cluster feature requests, and draft a first-pass problem statement from a pile of unstructured feedback in minutes instead of a week of manual triage.

What stays human-controlled: prioritization. AI can surface patterns in feedback; it should not decide what the business invests in next. Treat AI-generated idea summaries as input to a discussion, not a ranked backlog.

2. Requirements

Without AI: a product manager and a tech lead iterate on a doc, often losing edge cases until QA finds them later.

With AI: an assistant drafts acceptance criteria, flags ambiguous requirements ("what happens if the user has zero items in cart?"), and generates a first pass at edge cases from a plain-language spec.

What stays human-controlled: the definition of done, and any requirement involving legal, compliance, or safety tradeoffs. An AI-suggested edge case list is a helpful checklist, not a substitute for a domain expert's judgment about what "correct" means for a regulated workflow.

3. Architecture

Without AI: architecture decisions are made in a design doc, reviewed in a meeting, sometimes not revisited until something breaks.

With AI: an assistant can enumerate tradeoffs for a given design question, generate sequence diagrams from a description, and check a proposed design against known anti-patterns.

What stays human-controlled: the decision itself, and specifically anything with security, data residency or cost-at-scale implications. Architecture decision records should still name a human owner, even when an AI tool helped draft the tradeoff table.

4. Coding

Without AI: engineers write code line by line, referencing docs and existing code by hand.

With AI: a coding agent can take a well-scoped ticket and produce a draft implementation, including tests, following existing repo conventions. See Inside the AI-Augmented Developer Workflow for a full walkthrough of this in practice. This is the stage most people mean when they say "AI-native development," but it's one stage of twelve.

What stays human-controlled: scoping the ticket precisely enough that the agent has a bounded, checkable target, and reviewing the diff before it merges. An agent that writes code nobody reads is not a productivity gain, it's a liability with a delay timer.

5. Testing

Without AI: engineers write unit tests alongside code, often under time pressure, often incompletely.

With AI: an assistant can generate test cases from a function signature and docstring, including edge cases a rushed engineer might skip, and can point out untested branches.

What stays human-controlled: deciding what correctness means for the domain. Generated tests are only as good as their assertions: a test that exercises a function without asserting the right behavior gives false confidence. A human still has to check that the tests would actually fail if the logic were wrong.

6. Review

Without AI: a human reviewer reads the whole diff, checking style, correctness and design fit. It's slow, and quality varies by reviewer.

With AI: an AI review pass can flag likely bugs, missing null checks, inconsistent naming, and deviations from repo conventions before a human ever opens the PR, cutting the human reviewer's job down to the things that actually need judgment.

What stays human-controlled: approval. An AI review comment is a suggestion; only a human approval should unblock a merge, and that approval should mean the reviewer actually read the change, not that they clicked through an AI-generated summary.

7. Security

Without AI: security review happens late, often as a gate right before release, creating a bottleneck.

With AI: static analysis and AI-assisted vulnerability scanning can run on every commit, catching injection risks, secrets in code, and insecure defaults immediately rather than at a release gate. This includes AI-specific risks like unvalidated tool arguments reaching an MCP server, or a prompt template that concatenates untrusted input directly into a system prompt.

What stays human-controlled: the decision to accept residual risk. A scanner can flag a finding; a human security owner decides whether it blocks release, and that decision needs to be logged, not just dismissed by whoever is annoyed at the failing check.

8. CI/CD

Without AI: CI runs tests and linters; a green build means "the tests I thought to write passed."

With AI: CI can add an evaluation gate: for any change touching a prompt, a retrieval config, or a model version, a fixed evaluation set runs and the pipeline blocks on regression. See the evaluation pipeline pattern and LLM evaluation fundamentals for production.

# .github/workflows/ai-eval-gate.yml (excerpt)
jobs:
  eval-gate:
    if: contains(github.event.pull_request.changed_files, 'prompts/') || contains(github.event.pull_request.changed_files, 'retrieval/')
    steps:
      - run: python run_eval_suite.py --set regression_v3 --baseline main
      - name: fail on regression
        run: |
          python compare_eval_scores.py \
            --threshold-claim-support 0.90 \
            --threshold-refusal-accuracy 0.95 \
            --fail-on-regression

What stays human-controlled: setting the thresholds, and deciding what belongs in the regression set. A gate with no owner drifts until it blocks nothing.

9. Deploy

Without AI: deploys are gated by tests and a manual approval, often for the whole application at once.

With AI: progressive rollout by cohort, with automatic rollback triggered by a quality or cost metric crossing a threshold (not just an error rate), lets a change reach 5% of traffic before it reaches everyone.

What stays human-controlled: the decision to proceed past the canary stage, and, always, the ability to roll back manually regardless of what the automated rollback logic says.

10. Observability

Without AI: dashboards show latency, error rate, and infra health.

With AI: tracing extends into the model layer: retrieved context, assembled prompts, tool calls, token cost, and drift indicators, per the observability layer in the Enterprise AI Engineering Blueprint.

What stays human-controlled: defining what "normal" means for your system, and who gets paged. AI can flag anomalies; it should not silently auto-remediate a production incident without a human in the loop, at least until that specific remediation has an established track record.

11. Incident response

Without AI: an on-call engineer greps logs and reconstructs the timeline by hand.

With AI: an assistant can summarize a trace, correlate a spike in bad answers with a recent prompt or model change, and draft a timeline for the postmortem.

What stays human-controlled: the decision of what caused the incident and what fixes it. AI-assisted correlation is a hypothesis generator, not a verdict. Treat its summary as a starting point for the human investigation, not the postmortem's conclusion.

12. Learning loop

Without AI: postmortem findings go into a doc that may or may not change future requirements.

With AI: patterns across incidents and evaluation failures can be surfaced automatically and routed back into the requirements and testing stages, closing the loop back to stage 1.

What stays human-controlled: deciding which lessons generalize. Not every incident implies a new guardrail; some are one-offs, and treating every failure as a new permanent rule is how policy engines become unmaintainable.

What is an AI-native SDLC? A software development lifecycle in which every stage, from idea to incident response and the learning loop, is re-examined for what AI now does well and what must stay under explicit human control. It is not the old lifecycle with AI writing the code.

Which SDLC stages should stay human-controlled? Every stage keeps a human decision: prioritisation, the definition of done, the final architecture decision, ticket scoping and diff review, correctness definition for tests, merge approval, residual risk acceptance, gate thresholds, canary go or no-go, root cause determination and which lessons generalise.

Why does adding coding agents sometimes increase reverted merges? When speed rises in one stage and nobody changes the review process, CI gates or accountability, defects reach production faster. The lifecycle gets faster only in the place that has no new controls.

What is an AI evaluation gate in CI? A step that runs a fixed evaluation set when a change touches prompts, retrieval configuration or the model version, and blocks the pipeline on regression compared with the baseline.

Who should own the evaluation gate thresholds? A named human, from day one. A gate with no owner drifts until it blocks nothing.

Should AI auto-remediate production incidents? Not until that specific remediation has an established track record. AI is a hypothesis generator for incident response, and a human decides the cause and the fix.

• Every SDLC stage that uses AI has a named human decision point, documented, not implicit
• Coding-agent output goes through the same review gate as human-written code: no silent auto-merge
• An evaluation gate exists in CI for any change touching prompts, retrieval config, or model versions
• Security scanning runs continuously, not only at a pre-release gate
• Deploys are progressive with an explicit rollback trigger and a human canary go/no-go
• Incident postmortems distinguish AI-assisted hypothesis generation from human-verified root cause
• The learning loop has an owner who decides which incidents become permanent policy changes

• The Enterprise AI Engineering Blueprint (Part 1 of this series)
• Inside the AI-Augmented Developer Workflow (Part 3)
• Enterprise AI Guardrails (Part 4)
• The 90-Day Enterprise AI Adoption Playbook (Part 5)
• LLM evaluation fundamentals for production
• Evaluation pipeline pattern