Anthropic's AI SDLC vs AWS AI-DLC vs Cursor pstack vs my workflow

Four serious answers now exist to the question I have been answering for myself on every side project: what does building software look like once an AI agent writes most of the code? Anthropic published The AI-native SDLC playbook as an Anthropic Academy course. AWS published the AI-Driven Development Lifecycle (AI-DLC) method and an open-source implementation of it. Cursor published pstack, the skills that poteto — a React core team member who has worked at Meta, Netflix and Cursor — uses every day to ship there. And I have my own, projects-workflow-ai, the pipeline behind how I ship software.

I wanted to know where mine agrees with the other three, where it is thinner, and where it is deliberately simpler. So this post lines the four up stage by stage, maps the Claude Code and Kiro features that fit each step, and then runs one real feature through all four.

TL;DR

1. Anthropic, AWS and I replace the linear SDLC with a loop of written artifacts: each stage writes a file to the repository, and the next stage starts by reading it. Human attention concentrates at the gates between them.
2. Cursor's pstack is the dissent. It is not a lifecycle but a rigor engine: one entry point, /poteto-mode, routes each task to one of 23 playbooks and applies 24 engineering principles. It ships no planning skills on purpose — "the best spec is code" — and spends its effort on design exploration, multi-model review and proving the change works on the real app.
3. Anthropic's AI-native SDLC playbook is six stages — plan, design, build, test, deploy, maintain — written for an engineering organization with product owners, code owners and a platform team. Its signature moves are intent.md, plan mode, hooks as approval gates and evals in CI.
4. AWS AI-DLC organizes work into phases — Inception, Construction and Operation, with Ideation in front in the current implementation — around a mob: a small team that validates the AI's questions and proposals live. Work is cut into units and delivered in bolts of hours to days.
5. My workflow is the solo version of the artifact loop: issue → gated Kiro-style spec → implementation on a branch → staging → main. Agents open pull requests; I merge them. From the other three I am taking a plan step, evals for my skills, a production signal, and pstack's independent verifier.

The four, in a paragraph each

Anthropic: the AI-native SDLC playbook. Anthropic's course (14 short lessons, with a long-form companion article) starts from one observation: when code is no longer the bottleneck, the bottleneck moves to the stages on either side of build — planning, review and deployment — which still run at human speed. Its answer is a set of modular "plays", each ending with a committed artifact: intent.md, spec.md, plan.md, the diff and its tests, the reviewed PR, and the incident record. An accepted artifact triggers the next gate, and a breached control band in production writes the next intent.md.

AWS: AI-DLC. The AWS method paper (Raja SP, 2025) frames the lifecycle as three phases. In Inception, AI turns business intent into requirements, stories and units through mob elaboration. In Construction, AI proposes the architecture, domain model, code and tests through mob construction. In Operation, AI applies the accumulated context to infrastructure and deployments with team oversight. The open-source awslabs/aidlc-workflows turns that into an installable harness, /aidlc, that runs in Claude Code, Kiro and other agents: five phases, 33 stages, a deterministic engine, an approval gate after every stage, and an audit trail of every decision. Its philosophy is "small mob, broad agents".

Cursor: pstack. pstack is a plugin of skills, not a process document. Its author's goal is the opposite of maximum output: "pstack helps you write less, but higher quality code," and that rigor is what makes running many agents in parallel safe. You type /poteto-mode with a goal and a way to check it; the mode matches a playbook (feature, bug fix, refactoring, perf, prototype, shipping and 17 more), copies its steps into a todo list, and calls skills as the steps need them — /how and /why to understand, /architect to settle types and module shape, /arena for parallel attempts, /interrogate to have other models try to break the diff. Work is split by model strength: code to a fast code model, the hardest changes and judgment to a strong reasoning model. It runs in Cursor and installs in Claude Code as a plugin.

My workflow. projects-workflow-ai is the source of truth I bootstrap every side project from. A problem becomes GitHub issues (/problem-to-issues). Each issue becomes a Kiro-style spec — requirements, design, tasks, with an approval gate between each — that lands as a pull request into staging (/spec-from-issue). A fresh session implements the tasks on a feature branch and opens a second pull request (/implement-tasks). GitHub Actions moves the issue on the project board when I merge: In Progress when its spec lands, Done when every task box is checked on staging. A deliberate release PR promotes staging to main after a preflight that reproduces the production build. It is the same loop I run with clients as a forward deployed engineer.

Where the stages line up

Read across the rows and three of the columns agree closely. Anthropic, AWS and I all separate framing the problem from specifying the solution, and all three insist on a written plan the agent cannot skip before it writes code. Anthropic enforces that with Claude Code's plan mode, which blocks edits until a person accepts the plan. AWS does it with design stages per unit. I do it with tasks.md, which /implement-tasks must read in full — with requirements and design — before touching a file.

pstack breaks the pattern in the specify row, and on purpose. Its README says it plainly: "i don't believe in planning. the best spec is code." What it does instead is make the code earn its shape before it is written. Any code starts by naming its data shape; code that crosses a function boundary goes through /architect; a fork you could settle by running something becomes a throwaway prototype rather than a question to a human. The plan exists, but as a todo list copied from the playbook, not as a document someone approves.

The other differences are in the size of each row:

• Framing. Anthropic's intent.md is a separate, human-readable document that a non-engineer can write with Claude and commit through a GitHub connector. AWS's Ideation phase goes further: market research, feasibility, scope, team formation and rough mockups. pstack frames by understanding the code first — /how walks a subsystem, /why digs through the history of a decision, /in-your-own-words plays your goal back before work starts. Mine collapses framing into the issue itself, because the person framing the problem and the person building it are the same person.
• Specifying. Anthropic, AWS and I write requirements before design. AWS adds user stories, personas, a domain model and contract design between units. I write requirements in EARS form (WHEN … THEN the system SHALL …), the format Kiro specs use.
• Operating. Anthropic and AWS run agents against production signals and write findings back into the front of the loop. pstack ships a dormant automation pack, benny, that triages issue reports from Slack and then reproduces and fixes confirmed bugs with real UI evidence — but it runs on Cursor automations only. My loop closes earliest: /test-manual builds an exploratory QA suite against the real UI, and its failures become new issues. Nothing watches production for me yet.

The artifact chain

Anthropic's playbook puts it best: "the chain of commits is also the audit trail." An agent's chat history is gone the next morning. A file in the repository is not, and the next agent — or the next person — can read it.

Each approach leaves a different trail. AWS keeps a state file (aidlc-state.md) plus an audit trail of every gate and decision, so a run can stop and resume across sessions and people. Anthropic makes each artifact a trigger: a merged intent.md can start the spec pass non-interactively, a merged PR starts the pipeline. Mine makes each merge a status change, derived by GitHub Actions from what has been merged into staging.

pstack's trail is the most code-shaped. Instead of documents ahead of the code, it leaves small ordered commits, each one a future PR, stacked so the sequence proves itself to a reviewer; a decision log you can commit when the stakes need an auditable record (/show-me-your-work); a project verification skill with a feature map, so "it works" is something you rerun rather than believe (/create-verification-skill); and, after a long task, an edit to the skills themselves (/reflect). Its principle build the lever says why: the tool that does or proves the work is the artifact a reviewer can rerun.

One rule of mine I did not find in any of the three, and would defend: a feature has one spec for its whole life. When a later issue changes an existing feature, /spec-from-issue amends that spec in place and appends a ## Issue #N task section, instead of creating a second spec that contradicts the first.

Who approves what

Anthropic phrases the governing rule as "the agent may act up to the production gate and cannot pass it." AWS and I agree. pstack draws the line in a different place:

• Anthropic names roles — originator, product owner, engineer, code owner, release manager, service owner — and preserves separation of duties: the agent that wrote the code has no way to approve it. A Claude Code PreToolUse hook can block or ask, pausing a deploy command until a named person approves.
• AWS puts a team at the gate. Every stage ends with an approval, and three verification gates sit at the phase boundaries. Mob elaboration replaces backlog grooming: the AI asks, the team answers in the room.
• Cursor's pstack keeps separation of duties but hands most gates to other agents. Its principle never block on the human says: proceed on reversible work, present the result, and let the human course-correct. It always pauses for irreversible writes — force-pushes to shared branches, deploys, data deletion, messages to customers. Before a stack lands, its shipping playbook requires a PASS verdict from an agent that did not write the code and ran the change as a user would; green CI and an approving bot review do not count. Its autopilot playbooks can drive PRs all the way to merged.
• Mine has seven gates and one person. The three spec gates use AskUserQuestion (approve or revise), and the three merges are pull requests I review on GitHub. "The user merges PRs; agents open them" is written into the steering every agent loads.

The comparison at a glance

Aspect	Anthropic AI-native SDLC	AWS AI-DLC	Cursor pstack	My workflow
Written for	Engineering orgs with platform and security leads	Teams of 3–5 per feature, often on AWS	Engineers running many agents in parallel	One engineer, many small projects
Unit of work	An intent, then a spec	A unit of work, in bolts	A task routed to a playbook, a stack of small PRs	A GitHub issue, one spec section
Written spec	intent.md → spec.md → plan.md	requirements, stories, units, NFR design	None by default; data shape and types first	EARS requirements → design → tasks
Gates	Six, by role; hooks can enforce	One per stage, plus three phase gates	Agent verdicts; humans for irreversible actions	Seven, all mine
Verification	Feedback loop per change, evals in CI	Build and test stage, CI stage	Prove it on the real app; multi-model review	All local: build, lint, tests, E2E, preflight
Who merges	A code owner	The team	Agents may, after an independent verdict	Only me
Closes the loop from	Production control bands	Operation feedback to Ideation	Slack reports (Cursor only), /reflect	QA findings to new issues
Tooling	Claude Code native	Claude Code, Kiro and more	Cursor, or Claude Code as a plugin	Kiro for specs, Claude Code for building

Claude Code and Kiro, stage by stage

None of these approaches requires one tool, but each was shaped by one. Anthropic's playbook is written around Claude Code. AWS ships AI-DLC as a harness for several agents, including Claude Code (/aidlc …) and Kiro (the aidlc agent in the IDE's agent picker). Cursor's pstack is written for Cursor and installs in Claude Code with /plugin marketplace add cursor/plugins and /plugin install pstack@cursor-plugins; there it is /pstack:poteto-mode, and a Claude Code adapter maps Cursor's tool names to Claude Code's. The Cursor-only parts — automations, Bugbot, cloud agents — are skipped. There is no Kiro adapter. Mine splits the work: Kiro, because its spec mode is requirements → design → tasks, and Claude Code, because its skills, subagents and MCP tooling are where I build and verify.

This is the feature map I would use for each stage, whichever approach you follow:

Stage	Claude Code	Kiro	pstack skill
Frame	Skills for a repeatable interview (/problem-to-issues); MCP for GitHub	A spec session started from the issue; manual steering with #name	/how, /why, /recall, /in-your-own-words
Specify	Org skills for standards; the same pass run with claude -p when intent.md merges	Requirements-first specs in EARS; powers for domain context	/architect; the prototype playbook to settle a fork by running it
Plan	Plan mode, which blocks edits until the plan is accepted	design.md and tasks.md; Supervised mode	The playbook's todo list and throughput checkpoint; the multi-phase plan playbook
Build	CLAUDE.md / AGENTS.md, subagents, worktrees, auto mode	Task-by-task execution; Autopilot plus an auto-approve steering file	The feature playbook, /tdd, /arena, /swarm
Verify	Hooks; a browser through MCP; /code-review and /security-review	Hooks on file save; a Workflows repeat loop of implement → verify → review	/interrogate, /no-comments, /create-verification-skill, /blast-radius
Release	Code Review with a REVIEW.md; GitHub Actions; a PreToolUse hook that asks	A Workflows recipe that waits for a green staging build and opens the promotion PR; the Kiro CLI	The opening-a-PR, babysit and shipping playbooks
Operate	The Agent SDK or scheduled headless runs; Claude Tag in Slack	Cloud sessions from Kiro Web; AWS powers for cost and security	/why across Sentry, Datadog and other MCPs; /reflect and /correct

Three lessons carry across all the tools. First, put shared rules where every agent actually reads them. My AGENTS.md is installed into Kiro's steering folder and imported from ~/.claude/CLAUDE.md, because Claude Code reads nothing in Kiro's folders — which is exactly how agents kept opening PRs against main long after my git rules said staging. Second, a skill advises and a hook enforces. Anthropic's playbook says the skill makes violations rare and the hook makes them close to impossible. Third, pstack's version of the same idea: when you catch yourself correcting an agent twice, encode the lesson in structure — a lint, a type, a script — rather than more text. /correct mines your history for those repeated corrections.

A worked example: a pull-today list

Theory is cheap, so here is one feature run through all four. It comes from a real project of mine, Perishable Shelf Stacking, which replaced the paper shelf-life list grocery stockers work from with a searchable product card. The new problem, in the stockers' words: "we find expired product in the middle of the shift." The card knows how long a product lasts. It does not tell anyone, at the start of a shift, what to pull today.

The feature: a pull-today list — every product whose sticker date falls in the next 48 hours, grouped by aisle, on a phone. Same stack in all four runs: Next.js and AWS Amplify Gen 2.

Through Anthropic's AI-native SDLC playbook

The store manager, not an engineer, starts it: a brainstorm with Claude that ends with an intent.md committed through the GitHub connector. The template's five headings force the questions that usually surface in week three:

# Intent: pull-today list

## Problem
Stockers find expired perishables mid-shift. The shelf-life list says
how long a product lasts, not which units on the shelf expire next.

## Proposed outcome
At shift start, a stocker opens one screen that lists, aisle by aisle,
every product whose sticker date falls in the next 48 hours.

## Affected users and systems
Stockers, store manager. Product catalog (Amplify Data), shelf locations.

## Constraints
Phone-sized screen, works on store Wi-Fi, no new hardware.

## Open questions
Is 48 hours right for every category, or does dairy need 72?

The product owner corrects and merges it. That merge triggers the requirements-and-design pass, guided by org skills (here, a food-safety skill that knows the rules for each category), which produces spec.md. Once the spec is accepted, the engineer opens Claude Code in plan mode and iterates until the plan could be handed to someone who never saw the conversation:

# Plan: pull-today list

## Files that change
- amplify/data/resource.ts      add stickerDate index on Product
- src/app/pull-today/page.tsx   aisle-grouped list
- src/lib/pull-window.ts        48 h window, category overrides

## Order of work
1. pull-window.ts with unit tests (boundaries: 47h59m, 48h, 48h01m)
2. data index + query
3. page, then E2E

## Risks
Time zones: sticker dates are store-local, Lambda runs in UTC.

## Proof
Vitest boundary cases green; Playwright E2E on the staging build.

Build starts with the failing boundary test, Claude implements until it passes, and Code Review checks the PR against spec.md and plan.md using the passes in REVIEW.md. A code owner approves; Claude cannot. Deployment sits behind a hook gate:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": ".claude/hooks/production-gate.sh" }]
      }
    ]
  }
}

And then the part my workflow lacks: in production, a scheduled agent watches the weekly waste figure against a control band. If waste does not fall — or rises past two standard deviations — the agent writes its diagnosis as the next intent.md, and the loop starts again.

Through AWS AI-DLC

The run starts with one command in either Claude Code or Kiro:

/aidlc Add a pull-today list to Perishable Shelf Stacking:
per aisle, every product whose sticker date falls in the next 48 hours.

The engine detects a brownfield workspace and, before any requirement is written, reverse-engineers the existing codebase. Then comes the step that feels most different: mob elaboration. Instead of a product owner reviewing a document, the developer, the store manager and a stocker sit with the AI for about an hour. It asks — what counts as a sticker date for loose produce? who acts on the list, and when? — and their answers become stories.md and personas.md on the spot.

Units generation then cuts the feature into loosely coupled units — say U1, the pull-window query and index, and U2, the aisle-grouped view — with a dependency graph, so two people (or two agents) can build them in parallel. Each unit goes through functional design, non-functional requirements (the list must load on store Wi-Fi in under two seconds), infrastructure design and code generation, inside a bolt of about a day. Operation adds observability setup, and its feedback stage points back to Ideation.

For a team, this is excellent: the stocker's answer about loose produce surfaces in hour one, not in UAT. For one engineer it is a lot of stages, which is why AI-DLC ships workflow profiles that skip what a given scope does not need.

Through Cursor's pstack

pstack's guide gives one piece of advice above all: give the agent a goal and a way to check it, in your own words. So the whole run starts from one message:

/poteto-mode add a pull-today list to perishable shelf stacking: per aisle,
every product whose sticker date falls in the next 48 hours. category
windows can differ. verify it on the real app before opening the pr.

The mode matches the feature playbook and copies its steps into a todo list. /how walks the product and shelf-location code first. Because the code crosses function boundaries, /architect settles the shape before anyone writes logic: a PullWindow type and a table of per-category windows, instead of if (category === 'dairy') scattered through the page — the principle model the domain. The playbook then writes a throughput checkpoint (what blocks, what parallelizes, what shares state) and delegates the code to the configured code model. If there are several valid shapes, it hands the work to /arena so parallel attempts surface the alternatives and a cross-judge picks.

Verification is on the matching surface — the real app in a browser, not "it compiles" — and "inconclusive" is not a pass. If the design is contested, /interrogate asks different models to break the diff. The PR opens with a Conventional Commits title and a short briefing: why, what changed, scope, blast radius, verification.

What pstack does not do is ask the stocker anything. Nobody writes down whether dairy needs 72 hours; the message above says "category windows can differ", and the table makes it cheap to change. That is pstack's bet: get the data shape right and the requirement becomes a row, not a rewrite.

Through my workflow

Mine is a sequence of commands, gates and merges:

/problem-to-issues   "stockers find expired product mid-shift"
  -> issues.md: #52 feat: pull-today list by aisle   (create 1)
/spec-from-issue 52
  -> requirements.md  -> approve
  -> design.md        -> approve
  -> tasks.md         -> approve
  -> spec/52-pull-today-list  PR into staging, Refs #52
(merge)  -> #52 Todo -> In Progress
/implement-tasks 52-pull-today-list        # fresh session
  -> feat/52-pull-today-list  PR into staging, Closes #52
(merge)  -> #52 Done
staging -> main  release PR after the preflight

The requirements are where most of the thinking happens, and the EARS form makes them testable line by line:

### Requirement 1: pull window

1. WHEN a stocker opens the pull-today list THEN the system SHALL show
   every product whose sticker date falls within the next 48 hours,
   grouped by aisle.
2. WHEN a product's category defines its own window THEN the system
   SHALL use that window instead of 48 hours.
3. IF no product falls in the window THEN the system SHALL say so
   instead of showing an empty list.

Requirement 2 is Anthropic's open question about dairy, caught here at the requirements gate instead. tasks.md ends, by rule, with an end-to-end task and a build-lint-test checkpoint. /implement-tasks runs in a fresh session — old sessions carry polluted context — on a branch cut from staging, checks off each box as it goes, and drives a real browser through Playwright MCP before it opens the PR. The release PR waits for a green Amplify staging build and a local preflight that reproduces the production install and checks the server bundle against Amplify's size cap, the lesson from deploying Next.js 16 on Amplify and the TypeScript error only CI could see. If I want the whole thing orchestrated rather than prompted, the Kiro Workflows recipes run the same steps as one graph and stop at an open PR.

What the four runs tell you

All four arrive at roughly the same code. What differs is who has to be in the room, and when you find out you were wrong. AWS's mob finds the loose-produce question first, because the stocker is in it. Anthropic's playbook finds the dairy question in intent.md and the time-zone risk in plan.md, and it is the only one that will tell you, weeks later, whether waste actually fell. Cursor's pstack finds the design mistakes earliest — a scattered conditional, an untested boundary, a diff another model can break — and proves the result on the real app, but it learns about the business only through what you typed. Mine is the fastest from complaint to staging for one person, and the one most likely to ship a correct feature that nobody measures.

What I am taking from the other three

1. A plan step inside the implementation session (from Anthropic). tasks.md says what; plan.md says which files, in what order, with what risk and what proof. Starting /implement-tasks in plan mode costs a minute and makes the session's intent reviewable before it edits anything.
2. Evals for my own skills (from Anthropic, and pstack's eval playbook). My skills and steering change often, and nothing tests them except the next real run. An eval suite built from 20 to 50 real tasks, run whenever a skill or hook changes, is the cheapest insurance I am not paying for.
3. A production signal that writes an issue (from Anthropic and AWS). Even a single CloudWatch alarm that opens a GitHub issue would close my loop on real behavior rather than on QA findings.
4. A verifier that did not write the code (from pstack). My /implement-tasks session verifies its own work. pstack's rule — only a verdict from an agent that did not write the code counts, because an author checks what it meant to build — is a cheap upgrade: a fresh subagent that runs the feature on staging and posts PASS or FAIL on the PR before I merge.
5. Encode repeated corrections in structure (from pstack). When I correct an agent twice, the fix should become a lint, a type or a script, not another line of steering.
6. Mob elaboration for client work (from AWS). With a client, an hour where the AI asks and the people with the problem answer is a better requirements session than any I run alone — and it fits how I already work at the customer's side.

What I am keeping: the written spec, the one-spec-per-feature rule, status derived from merges, all verification local, and agents that never merge. pstack lets agents land a verified stack; I still want a person on that last button.

Which one should you start from?

• You are one person or a very small team shipping many small projects: start from something like mine. Fewer stages, gates you can actually staff, and an artifact trail anyway.
• You run engineering for an organization with code owners, compliance and a platform team: start from Anthropic's AI-native SDLC playbook. Its governance sections — managed settings, hooks as gates, separation of duties — are the part most teams skip and later need.
• You are a team of three to five starting a sizeable feature or product, especially on AWS: try AWS AI-DLC. Install the harness, run /aidlc on something real, and let the engine carry the process while you learn which stages your scope can skip.
• You already know what to build and want each change to be rigorous while several agents work at once: install Cursor's pstack, in Cursor or Claude Code, and start every non-trivial task with /poteto-mode. It pairs well with any of the other three: their artifacts decide what, pstack's playbooks decide how well.

Whichever you pick, the shared core is the part to copy: write down what matters, prove the change on the real thing, and put a person at every gate that cannot be undone.

If you would like a pipeline like this set up for your team, that is part of what I offer as services. You can also tell me about the problem.

References

• Anthropic Academy: The AI-native SDLC playbook
• Claude blog: The AI-native SDLC playbook
• AWS: AI-DLC Method Definition paper
• AWS DevOps blog: AI-Driven Development Life Cycle
• awslabs/aidlc-workflows and its phases and stages guide
• Cursor: pstack, its guide and its Claude Code adapter
• jpmti2016/projects-workflow-ai
• Claude Code: extend Claude Code
• Claude Code: plugins
• Kiro: how Kiro works
• Kiro: specs