You're building staging, deployment safety, measurable SLOs, and a projection-capable cost model for a podcast hosting platform in Toronto whose engineering director is tired of deploys that feel like prayers.
The discipline skills: a multi-environment Terraform layout with staging isolated from production; a GitHub Actions pipeline with a manual approval gate; health checks that verify the database and downstream dependencies, not just that the process is up; rolling updates with a minimum-healthy-percentage floor; SLOs keyed to what users experience rather than CPU; custom application metrics; three audience-specific Grafana dashboards; and a cost model that projects the AWS bill under scenarios Marcus can take to his leadership.
The AI-direction lesson is about depth of safety work. AI will generate the shape of every mechanism you ask for -- staging, a promotion gate, a health check, a rolling update, an SLO dashboard, a cost model -- and each one, on the first pass, will look right and will not actually protect against the failure it names. The health check returns 200 as long as the container is running. Promotion to production is automatic rather than gated. The rolling update has no minimum-healthy floor. The SLO is keyed to infrastructure metrics. The cost model multiplies current cost by a scaling factor. Your job is to recognize each shallow default and specify the depth that makes it real.
Your Role
You're the cloud engineer Marcus Chen brings in because Waveform Media grew too fast to set up the practices a platform at their scale needs. Marcus is a strong engineer -- he has read the Google SRE book -- but he has been shipping product for three thousand podcasts and eight million monthly downloads instead of building himself the safety net. You do that work.
Scaffolding holds at the same level as last time. What's different is that deployment, observability, and cost all step up together. That sounds like a lot, and it is -- but each advance sits on top of work you have already done. You have deployed to production, built dashboards, and estimated costs. What's new is a second environment with a real gate between them, SLOs tied to contracts your client has actually signed, dashboards keyed to three specific audiences, and cost projections that account for how services interact.
With AI, the collaborative register continues. You bring the context AI can't infer -- the 2am analytics batch jobs that skew any cost model built on averages, the shared RDS instance between the API and analytics that staging has to split, the three enterprise SLAs on specific services. What's newly surfaced is AI's weakest spot in 2026: the safety mechanisms around deployment are where it reaches the shallowest. You review, specify depth, push back.
What's New
Last time in Nagoya you inherited Yuki's two-year-old factory IoT platform, added structured JSON logging, decomposed the diagnostic work in plan mode, and used hypothesis-driven troubleshooting to find three problems that weren't in the code AI kept proposing to fix. You left her team with a logging standard, Logs Insights queries, and a handoff document.
This time the work is greenfield again -- you're adding new infrastructure on top of Waveform's production stack, not diagnosing something broken. The failure mode shifts. AI's errors now aren't "propose a code fix for a non-code problem." They're "generate the safety mechanism shallow, and name it after the thing it doesn't do." A health check that doesn't verify health. A promotion gate that doesn't gate. A rolling update that rolls everything at once.
The hard part: three areas advance at the same time, and each has its own shallow-default trap. Staging without letting AI double the bill. SLOs that measure what users experience, not infrastructure metrics. A cost model that accounts for the 2am batch peak and cross-service interactions, instead of current cost times a scaling factor. The underlying discipline -- specify what you need, review what AI produced, verify against what matters -- is the same. The failure modes are new.
Tools
- Claude Code -- directing Terraform, pipeline YAML, health check handlers, custom metric instrumentation, Grafana JSON, and cost-model logic
- Terraform CLI -- multi-environment layout with staging and production as separated environments (new shape; the tool is familiar)
- GitHub Actions -- CI/CD pipeline with a manual approval gate via GitHub Environments (new usage)
- ECS on Fargate -- rolling updates are configured here
- CloudWatch -- standard metrics, custom application metrics via PutMetricData (new usage), Logs carrying from P7
- Grafana -- new in P8; Amazon Managed Grafana with the CloudWatch data source
- Infracost -- carrying from P4; one input to the cost model, not the whole model
- AWS Cost Explorer and Compute Optimizer -- new usage; scenario comparisons and right-sizing verified against peak usage
- AWS CLI and Console -- inspecting ECS events, approval state, custom metric emission
- checkov, Docker and ECR, Git and GitHub, VS Code -- carrying forward
The unit introducing Grafana walks through the workspace setup. Everything else you've used before.
Materials
In the project folder:
- Marcus's Slack first-contact (
first-contact.md) -- his three pain points in his words, with "where would you start?" at the end - Architecture summary (
architecture-summary.md) -- Waveform's existing production stack (ECS behind an ALB, RDS, S3 for podcast audio, CloudFront for downloads), shared-RDS annotated - Infracost baseline (
infracost-baseline.json) -- current-month output; the starting number for your cost model - Cost Explorer snapshot (
cost-explorer-snapshot.csv) -- a few months of actuals to sanity-check Infracost against real spend - PRD (
prd.md) -- scope and non-goals; canary and zero-downtime deploys are deferred to P11
No staging layout, pipeline template, health-check handler, rolling-update configuration, SLO values, dashboard JSON, cost model structure, or handoff template is provided. You write them all, with AI doing the generation and you doing the depth.