« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 15 — AI-Native SDLC: Spec-Driven Development, Reusable Commands & Coding Agents

Answers these JD lines: Temporal's AI Foundations team — "agentic coding skills for tools like Codex and Claude Code," "build trusted agentic coding systems," and the explicit "using AI to increase quality, not just output volume" (jd.md §11); Anthropic's Claude Code developer-productivity and agent runtime roles (§14); and the track's own resume positioning — "AI-native software delivery, Spec-Driven Development, reusable agent workflows, human-in-the-loop validation" and "structured planning, tool invocation, validation loops, and reusable commands" (jd.md "Resume positioning"). This is the flagship agent use case: an agent that edits your codebase.

Why this phase exists

The single most-shipped agent in the world today is a coding agent. Claude Code, Codex, Cursor, and Aider are the ones millions of engineers touch daily, and every JD in the "resume positioning" section names them. If Phase 01 was "build the agent loop," this phase is "point that loop at a repository and make it safe to merge." The mechanism is specific and worth building from scratch, because when a coding agent corrupts a file, edits the wrong path, or loops without converging, the person who built the plan→patch→verify loop is the one who debugs it.

The whole discipline reduces to one reframing and four mechanisms:

• The reframing: quality, not volume. Temporal's JD says it in one line — "using AI to increase quality, not just output volume." A coding agent that emits more code faster is a liability; one that raises quality (reviews, tests, refactors, verified diffs) is the point. More code is not the goal; a verified change is.
• Apply-patch (edit blocks). The agent edits via a structured patch — an exact search/replace hunk it can locate and swap, or a whole-file write — not by regenerating the file and hoping. Exact-match, fail-on-ambiguity is what makes the edit safe and reviewable.
• Spec-Driven Development. Write a verifiable spec first. The spec plus its acceptance checks are simultaneously the contract and the eval — GitHub's Spec-Kit, AGENTS.md / CLAUDE.md, the "prompt standards" resume language.
• Verification as the ground truth. Tests are the reward signal. SWE-bench scores a patch only if the repo's tests pass. "Trust but verify" is the loop, not a slogan.
• Reusable commands / skills. Parameterized workflows — Claude Code slash-commands, skills, subagents — checked into the repo so the team runs the same good process every time.

Concept map

• The coding-agent loop: context → plan → apply-patch → run tests/verify → iterate — the ReAct loop of Phase 01 with the acceptance checks as the reward and the diff as the action.
• Apply-patch families: exact search/replace (Aider/Claude-Code edit block) · unified diff (@@ hunks, Codex/Cursor) · whole-file (new file or heavy rewrite). Search/replace fails closed on a missing or ambiguous match — the safety property.
• Spec + acceptance checks: the spec is the contract and the eval; verify runs provided callables, never eval of agent output (the Phase 09 discipline, and cross-cut with Phase 11 evals).
• Rollback: snapshot/restore so a failed apply never leaves the tree half-patched — a bad edit is an observation, not corruption (Phase 01 errors-as-observations, specialized to code).
• Least-privilege guardrail: allowed_paths bounds what the agent can touch — the trust boundary from Phase 09/10, applied to file edits.
• Reusable commands: name + args → Spec — the slash-command / skill registry, the "reusable agent workflows" on the resume.
• Human-in-the-loop review: the transcript is the diff a human approves before merge — the final gate, because the model proposes and you merge.

The lab

Integrated scenario (how this shows up at work)

A ticket says: "add a greet(name) helper to util.py returning Hi {name}, with a passing test." You do not paste the ticket into a chat and copy back a file. You write it as a spec with acceptance checks — util.py exists, defines greet, the body renders Hi {name}, test_util.py exists and defines test_greet. You run the reusable /add-function command that expands to that spec. The agent plans two steps, applies two patches (edit blocks, scoped to the two allowed files), and verifies. Iteration 1's patch returns Hey {name} — verify fails on the Hi {name} check. The agent sees the failure, its iteration-2 patch fixes the string, and verify passes. A human reads the four-event transcript, sees a clean two-file diff that satisfies every acceptance check, and merges. The injected wrong-first-patch is the whole lesson: the loop's correctness comes from verification, not from the model being right the first time — and the guardrail meant the agent could never touch secrets.py even if it tried. Same ticket, and the outcome is a verified change, not just more code. That is the AI-native SDLC.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py (30 tests).
• You can explain why exact search/replace fails closed on a missing or ambiguous match, and how that differs from a unified diff and a whole-file write.
• You can state what Spec-Driven Development buys: the spec is the contract and the eval.
• You can trace why the loop passes on iteration 2 and stops at max_iters.
• You can justify the allowed_paths guardrail as least privilege on file edits.
• You can articulate "quality, not volume" as the design goal — verification is the point.

Key takeaways

• A coding agent is the ReAct loop with tests as the reward — plan → apply-patch → verify → iterate, bounded and reviewable. It is not autocomplete.
• Apply-patch is the safety mechanism. An exact search/replace that fails on a missing or ambiguous match is reviewable and safe; regenerating the whole file and hoping is neither.
• Spec-Driven Development makes the spec the contract and the eval at once — the same idea as test-first, plus the agent reads the spec to know what "done" means.
• Verification is the point, not volume. "Using AI to increase quality, not just output volume" is the JD line and the design principle: a verified diff beats a bigger diff.
• Reusable commands/skills encode the team's good process once and run it every time — the "reusable agent workflows" that turn a tool into a platform.
• The AI-native SDLC positioning — Spec-Driven Development, reusable commands, human-in-the-loop validation — is the through-line of this candidate's resume, and this phase is where it becomes something you built, not something you claim.