Stop 7 of 10 · Weekly
Proof of concept with Claude Code
A written brief, Terraform generated in a repository and read line by line, a plan Fadi reads before any apply, a sandbox account with a hard boundary, and a teardown written before the build.
The demo that proves something
Rio Seco Unified wants to see the identity federation and the managed database restore working before they commit. Fadi has three days. Building it by hand means a console-clicked environment nobody can rebuild, no record of what was created, and a bill next month for something he forgot.
Claude Code in a repository fixes all three, and introduces exactly one new risk: infrastructure code that reads plausibly and does something slightly different from what the brief asked. The rest of this stop is about that risk.
The brief comes first
One page, written before any code, and it lives in the repository beside the Terraform.
| Section | What it says |
|---|---|
| Proves | The one or two things the agency will actually watch |
| Success criterion | The observable result, written as something you can point at |
| Boundary | One sandbox account, one region, a spend cap, no customer data |
| Destroy date | A date, in the brief, before the first resource exists |
I am the cloud architect on the Rio Seco Unified account. I need a three-day proof of concept in my own sandbox account that demonstrates two things: federated sign-in from the district identity provider using a test directory I control, and a point-in-time restore of a managed database into a working state. Write the brief: what it proves, the success criterion written as something observable, the boundary, and the teardown. Then list every resource type it will need and, for each one, the single riskiest way it could be misconfigured in a way I would not notice. No code yet. I want the list of what could go wrong before I read the code that could do it.
That last list is what turns the code review from skimming into looking for something.
The code, read line by line
In this repository, write the Terraform for the proof of concept described in brief.md. Constraints, all of them hard. Everything in one sandbox account and one region, with a variable for both and no defaults that point anywhere else. No resource is publicly reachable unless the brief says it is, and any that is carries a comment saying why. No secrets in the code or in the state, ever. Tag every resource with the project name and the destroy date from the brief. Write the teardown path in the same commit, and tell me anything that will survive a destroy. Before the code, write in plain English what this will create, what it will make reachable and what it will cost per day at the quantities in the brief, and put that in the pull request description.
Then Fadi reads it. Every line, out loud where a colleague can hear. Any line he cannot explain becomes a question back to Claude Code before anything runs.
Run terraform plan against the sandbox workspace and show me the full resource list rather than the count. Then, reading the plan output only, answer three questions. What in here is reachable from the public internet. What in here would still exist after a destroy. What in here is not mentioned in brief.md at all.
The third question catches the most. Generated code grows helpful extras: a log bucket, a default role, a network path nobody asked for. In a sandbox those are clutter. In a customer account they are findings.