Skip to content
Pocket Grove
Developer blog

The AI Software Development Lifecycle (SDLC), Simply Explained

Published · 7 min read

By · Pocket Grove

Original research brief: . Sources reviewed: .

Quick answer: The AI software development lifecycle (SDLC) is the normal flow of plan, design, build, test, review, document and deploy, with an AI agent doing the first draft at each step. OpenAI frames it as delegate, review, own: you delegate first-pass work to the agent, engineers review it, and humans keep the big decisions. Anthropic adds: give the agent a check it can run.

If you have used an AI coding tool for more than a week, you have probably noticed it is brilliant at some jobs and oddly careless at others. The trick is knowing which is which. Both OpenAI and Anthropic have now published guidance on this. This post squeezes it into one page.

This is the hub of our "AI dev, in plain English" series. Each later post goes deeper on one idea.

What is the AI software development lifecycle?

The software development lifecycle (SDLC) is just the name for the stages a piece of software goes through: deciding what to build, designing it, writing it, testing it, reviewing it, documenting it, then shipping and looking after it.

Adding AI does not remove any stage. What changes is who does the first pass.

OpenAI's guide, Building an AI-Native Engineering Team, uses a simple three-word pattern for every phase:

  • Delegate: hand the first-pass work to the agent.
  • Review: an engineer checks it.
  • Own: some decisions stay with people, full stop.

Anthropic's Best practices for Claude Code approaches it from the tool side. Its core advice is to tell the agent what it cannot see, give it a check to run, and enforce the rules that cannot have exceptions with something stronger than a prompt.

Put those together and you get a workable model for the whole lifecycle.

What does AI do at each phase, and what do humans own?

Here is OpenAI's phase-by-phase view, paraphrased, with the human column kept deliberately blunt.

Phase What the agent does well What a human reviews What a human owns
Plan Reads the spec, maps it to the code, flags gaps, drafts estimates Findings and sizing Priorities and product direction
Design Scaffolds projects, writes boilerplate, turns mock-ups into components Conventions, accessibility, integration Design system, UX patterns, architecture
Build First implementation of well-specified features, refactors, tests Design choices, performance, security, migration risk New abstractions, cross-cutting changes, long-term maintainability
Test Proposes cases, writes first-pass tests Shortcuts and stubbed-out tests Coverage against the spec, adversarial edge cases
Review First code review, often several rounds before a person looks Architectural fit, whether requirements are met What ships to production
Document Summaries, input/output notes, dependency lists, PR summaries Service overviews, API docs, runbooks Doc strategy, external and safety-critical content
Deploy and maintain Reads logs, spots anomalies, finds suspect commits, proposes hotfixes Diagnostics and fixes Critical or novel incident calls

Source: OpenAI, Building an AI-Native Engineering Team.

Notice the pattern. The agent is strongest where the task is well defined. The human column grows wherever the job involves taste, risk, or a decision that is hard to undo.

Phase by phase: the practical version

1. Plan

Agents are good at turning a vague request into a list of questions. Anthropic suggests asking Claude to interview you until it could write the spec, then save it to a file such as SPEC.md. It then recommends starting a fresh session to build from that spec, so the build begins with a clean context and a written definition of done.

What you still own: deciding whether the feature is worth building at all.

2. Design

OpenAI's guide has agents scaffolding projects and turning designs into components. Anthropic's write-up How Anthropic teams use Claude Code describes teams mapping error states and logic flows with Claude during design, to catch problems before coding starts.

What you still own: the architecture. If an agent invents a new abstraction, that is a human decision.

3. Build

This is where agents shine, provided they have context. Anthropic recommends a short project instruction file (CLAUDE.md) holding only what the agent cannot work out from the code: the exact test commands, misleading corners of the codebase, and decisions made outside the repo. Its memory guide suggests keeping that file under 200 lines. We wrote more on that in Stop putting everything in CLAUDE.md.

Repeatable team procedures, like how you cut a release, belong in a skill: a saved procedure the agent loads only when needed.

4. Test

Both companies land on the same idea. OpenAI's guide suggests writing tests in a separate session from the implementation, and warns reviewers to look out for stubbed or shortcut tests. Anthropic's guidance is to give the agent a check to run (a test file, a build's exit code, a linter) and ask it to keep going until it passes. Anthropic's teams also describe working test-first: pseudocode, then tests, then code.

What you still own: thinking like an attacker about edge cases.

5. Review

OpenAI describes agents doing the first review pass, sometimes several times, before a person sees the pull request. Anthropic recommends review by "someone who didn't write the code": its /code-review command reviews the diff in a fresh subagent that never saw your conversation, so it is not swayed by the reasoning that produced the change.

What you still own: the final yes. Agents can approve code style; only a person should approve what reaches users.

6. Document

Agents write good first drafts of summaries and change notes. Anthropic's teams describe using Claude to condense scattered docs into troubleshooting runbooks. OpenAI's guide asks humans to review the important ones (service overviews, API docs, runbooks) and to own anything external or safety-critical.

7. Deploy and maintain

OpenAI has agents parsing logs, surfacing anomalies and proposing hotfixes, with engineers approving the fix. On the tool side, Anthropic's best-practices page lists actions its auto mode treats as risky by default, including production deploys and migrations and force pushes over other people's work. For anything that must never happen, it recommends deterministic controls such as permission rules, hooks and the sandbox, rather than a polite line in a prompt.

What do Anthropic and OpenAI agree on?

Reading both sets of guidance side by side, five shared ideas stand out:

  1. Context beats cleverness. Tell the agent what is not in the code. Keep instruction files short.
  2. Give it a way to check itself. Tests, builds and linters turn "I think it's done" into "it passes".
  3. Separate the writer from the reviewer. A fresh session or subagent catches what the author missed.
  4. Enforce hard rules with tools, not prompts. Permissions, sandboxes and hooks are reliable in a way instructions are not.
  5. Humans own irreversible decisions. Architecture, releases and incident calls stay with people.

What we do at Pocket Grove

In our studio, Cong Le builds and maintains around 53 iOS and Android apps with Claude Code and Codex. Our version of this lifecycle is fairly plain:

  • One shared instruction file (AGENTS.md, with CLAUDE.md as a symlink to it) so both tools read the same rules.
  • A TASKS.md per app as the plan the agent works through.
  • Skills for repeatable jobs like screenshots and store preparation, and subagents for wide searches or independent work.
  • Headless tests the agent can run itself.
  • A human approval gate before anything goes to the App Store or Google Play. The agent prepares; a person submits.

That last point is the one we would keep if we had to drop everything else.

Read the series

  1. The AI SDLC, simply explained (you are here)
  2. Claude Code best practices in plain English
  3. Building effective agents, simplified
  4. OpenAI's guide to building agents, simplified
  5. AGENTS.md vs CLAUDE.md
  6. Codex vs Claude Code: how each company says to work with it
  7. Context engineering explained
  8. AI evals for beginners

Sources

Frequently asked questions

What is the AI software development lifecycle?
It is the usual software development lifecycle (plan, design, build, test, review, document, deploy and maintain) with an AI coding agent doing first-pass work at each phase. People still review that work and own the decisions that matter.
Which phases should a human never hand over to AI?
OpenAI's guide keeps product direction and prioritisation, architecture and new abstractions, what ships to production, and critical incident decisions with people. AI drafts; humans decide.
Should the same AI session write the code and the tests?
OpenAI's guide suggests writing tests in a separate session from the implementation, and Anthropic recommends a reviewer that never saw the conversation that produced the code. A fresh context is less likely to repeat the author's blind spots.
What is the single most useful thing to give an AI coding agent?
A check it can run, such as a test command, build or linter. Both Anthropic and OpenAI say agents do better work when they can confirm it themselves, and that a clear definition of done prevents half-finished results.

Apps from the studio

All apps

These practices come from shipping Pocket Grove's active apps. If you came here looking for something to install, start with one of these.

Related guides