Phase 11: Capstone: The AI-Native Product Engineer · 50 min · Claude Code · Python
Capstone Hardening: The Production Readiness Review
Google's SREs won't take over a service until it passes a production readiness review. Your capstone deserves the same standard applied to itself, by you, before you call it done.
Hiring signal: Running a real production readiness review against your own capstone — scoring maturity honestly and producing a prioritized remediation plan, not just a pass/fail badge — demonstrates the same operational discipline Google SRE requires before taking over a production service.
What you will learn
- Explain what a production readiness review (PRR) is and why Google SRE requires one before taking over a service
- Score your capstone product's maturity across seven categories: spec coverage, test coverage, quality gates, observability, incident response, harness regression, and platform architecture
- Distinguish a category scored 'not started,' 'partial,' and 'complete' using concrete, checkable evidence rather than self-assessment alone
- Produce a remediation plan that prioritizes fixes by real production risk rather than listing gaps in arbitrary order
Introduction
Capstone Hardening: The Production Readiness Review
A learner declares their capstone "production ready" because it runs without crashing and the demo works end to end. Pushed to actually answer specific questions — what's the incident response plan if the agent misbehaves at 2am, when was the harness regression suite last actually run and not just written once, what percentage of the spec's acceptance criteria have a corresponding test — they realize "it runs" and "it's production ready" are different claims entirely. Google's own Site Reliability Engineering team won't take over operating a service internally until it passes a structured production readiness review (PRR) — a checklist covering observability, alerting, reliability, deployment, and documentation — specifically because "it works in the demo" has never been a reliable signal of "it's safe to operate." Your capstone deserves the same standard, applied by you, before you call it finished.
The seven categories, scored honestly
A real PRR for this course's capstone product means scoring seven categories as Not Started, Partial, or Complete, based on evidence, not confidence: spec coverage (what fraction of the actual system's behavior has a corresponding spec entry), test coverage (what fraction of the spec's acceptance criteria has an automated test), quality gates (are the drift-gate and primary-reviewer checks actually required status checks, not just present in a config file somewhere), observability (are there real, configured alerts, not just log statements nobody watches), incident response (is there an actual documented plan, or would a real incident be improvised from scratch), harness regression (has the regression suite been run recently, or just written once and never re-executed), and platform architecture (does the documented multi-agent/team architecture match what's actually deployed).
'Partial' is an honest, useful answer — 'I'm not sure' is not
A production readiness review only works if every category gets scored against concrete evidence: a specific test file, a specific alert configuration, a specific document. Scoring a category 'Complete' because it feels finished, without pointing to the artifact that proves it, defeats the entire purpose of the review — the same way a vague spec defeats the purpose of writing one down.
A learner scores their capstone's 'observability' category as 'Complete' because 'the system logs everything.' What's wrong with this self-assessment, and what would a more honest score require?
Logs that exist but that nobody is actively watching provide no real operational readiness — if a failure happened right now, nothing would proactively surface it. A genuine 'Complete' score requires pointing to the specific artifact (a configured alert, a dashboard with a defined threshold) that would actually catch a real problem, the same evidence-based standard this course has applied to every other claim throughout.
Unlock the full lesson
You've read the first 2 sections. The rest of this lesson covers Why this matters more for AI-native systems than traditional software, Building the remediation plan: prioritize by risk, not by list order, Gathering evidence per category, not just impressions, Build It — plus a hands-on lab, quiz, and project artifact.
Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.
Browse all courses · View pricing · DeVenture Academy