The ADLC: the AI-assisted development lifecycle

Individual tricks — a faster review here, a generated test there — are not what changes an engineering organisation. What changes it is re-drawing the lifecycle: every stage from idea to operations, re-examined with one question — what does this stage look like when a capable agent is available at it? Call it the AI-assisted development lifecycle (ADLC). This lesson walks it stage by stage, with the tools from this course mapped where they belong, and the human role named at each step — because the pattern throughout is not fewer humans; it is humans moved to the decisions that need them.

Specify and plan: the front of the funnel moves

The largest underused gain is before any code. Turn a vague idea into a specification by making Claude the interrogator — in a claude.ai Project loaded with your product context, have it draft the spec, then attack it: unhandled edge cases, ambiguous requirements, missing non-functionals. Ten minutes of adversarial spec review saves days of building the wrong thing, and the complete-specification principle from the prompting lesson is made here — the ADLC's later stages are only as good as the brief this stage produces. Then planning drops to the codebase: Claude Code in plan mode explores the repo and proposes the implementation approach — files to touch, sequencing, risks — which you review and correct while correction is still free. Human role: decide what to build and approve the approach.

Build: the loop with a verifier

Implementation is the stage everyone knows, so this course adds only the discipline that separates demos from deltas: agents build best against a feedback loop. The strongest shape is test-first — specify behaviour as failing tests (written with Claude, reviewed by you), then let the agent implement until green; the tests convert "looks plausible" into "demonstrably works", and the agent iterates against the verifier instead of against your patience. Parallel worktrees from the power-use lesson mean several such loops run at once. Human role: define done; review the diff, not the keystrokes.

Review and test: coverage that scales with the code

Code volume rises when agents build, so review and test capacity must rise with it — and both automate well. The CI review bot from the automation lesson pre-reviews every PR against your rubric; human reviewers spend their attention on design and intent instead of typo-hunting. On testing, agents excel at the part humans skimp: adversarial case generation — boundary values, unicode, concurrency interleavings, the empty-input case nobody wrote — plus property-based suites and coverage-gap sweeps run as headless campaigns. The evaluation lesson's regression discipline applies to the AI pieces themselves: prompts and rubrics change through PRs with eval runs attached. Human role: own the rubric; adjudicate findings.

Document and release: the stages that stop being skipped

Documentation fails as a chore and succeeds as a byproduct: changelogs, API docs, architecture notes, and ADR drafts generated from the merged diff — accurate because they are derived from the change, cheap because they are headless jobs, reviewed because your name goes on them. Release work follows the same shape: CI-failure triage annotating the red build with a diagnosis, release notes drafted from the merge history, migration scripts proposed and human-approved. Human role: sign what ships.

Operate and maintain: the loop closes

Production is where the MCP lesson pays compound interest: an agent with read access to logs, metrics, and traces turns incident response from tab-juggling into interrogation — "what changed in the hour before the spike?" — with the sandbox-and-gate rules from the security lesson deciding what it may touch versus merely read. Maintenance, meanwhile, is the quiet killer app: dependency upgrades, deprecation sweeps, framework migrations — work that is important, unloved, and perfectly agent-shaped because it is well-specified and verifiable. Run them as scheduled campaigns that land PRs. What operations teaches — the recurring incident, the brittle module — feeds the next specification, and the loop closes. Human role: judgment at incidents; direction on debt.

Adopting it without breaking things

Sequence matters. Start where verification is cheap and blast radius is small — review bots, test generation, documentation — and let the evaluation lesson's evidence, not enthusiasm, promote automation toward higher-stakes stages. Keep every artifact on the same rails as human work: agent PRs get reviewed, agent docs get read, agent deploys don't exist until they have earned it. And write down where the humans stand — which gates are theirs — because an organisation that automates its lifecycle without naming its judgment points has automated its mistakes too.

What to take into the next lesson

The ADLC is this course's synthesis: specification up front, verifiers everywhere, artifacts over actions, humans at the judgment gates, agents at every stage in between. One capability got only a cameo — teams of agents working one problem together. That is the next lesson.