An AI-assisted software development lifecycle
A working path through discovery, design, planning, implementation, review, release, and maintenance, with an owner and an output at every stage.
01Give each stage an owner and an observable result
The software development lifecycle, or SDLC, is the path from deciding what to build to operating and improving it. AI can help throughout that path. It does not remove the need to agree on requirements, examine evidence, or own a release decision.
Our starting split is Claude /design for product design, Claude Code for implementation, and Codex for review. Codex can also own a website or landing-page build. Choose the next tool based on the task and the evidence, rather than forcing every task through a fixed sequence.
02The delivery path
These are recommended responsibilities for a project. One person may cover several roles, but each decision still needs an accountable owner.
| Stage | AI contribution | Human decision and output |
|---|---|---|
| Discover | Turn notes into questions, assumptions, and a brief. | Founder and engineer agree on one user outcome and acceptance criteria. |
| Design | Use Claude /design to explore flows and interface states. | Designer reviews hierarchy, usability, accessibility, and the handoff. |
| Plan | Inspect the repository and propose a small change sequence. | Engineer confirms architecture, permissions, dependencies, and scope. |
| Build | Claude Code usually implements; Codex can also implement. | Engineer keeps changes reviewable and inspects affected callers. |
| Review and verify | Codex reviews the change and helps exercise failure cases. | Engineer triages evidence; designer checks the implemented experience. |
| Release | Prepare checks, release notes, and operating instructions. | Named owner approves deployment, data changes, and recovery. |
| Maintain | Help investigate incidents and propose improvements. | Owner checks behavior, support needs, and the next priority. |
03A worked example: a client report
Start with the outcome: a client can view only their project’s report for an agreed date range. The designer covers loading, empty, error, mobile, and export states. The engineer identifies the records, tenant boundary, calculations, and existing reporting code.
Give the implementer the approved flow and acceptance criteria. Give the reviewer the same requirement, the revision, and the surrounding code. Verify the expected total and attempt the request with an account that must not have access. A persuasive explanation cannot substitute for that check.
Before release, confirm how the report is observed, what happens if the export fails, and how the deployment can be recovered. The example is illustrative; it is not a claim about a client engagement.
04Use a written handoff when switching tools
Carry forward the goal, approved design, revision or diff, files changed, checks run, unresolved questions, and decisions already accepted. The second tool should verify the code rather than inherit the first tool’s confidence.
Stop a review cycle when the agreed checks pass and material findings have a recorded resolution. Repeating reviews indefinitely can add cost without resolving the underlying uncertainty.