2 min lesson
The time-box protocol
Start at the first move in "The time-box protocol" and carry it through to the proof.
Step 1 of 2
The time-box protocolScope → build → document → demo
- 1First 15% · Scope ruthlessly and write it down. State the one outcome you'll ship and the things you're explicitly cutting. "I'll deliver a working access-request command; I'm cutting the approval UI and hard-coding the approver for now."
- 2Build the thin vertical slice first. Get one end-to-end path working, with request in, API call out and result back, before you polish anything. A demoable spine beats four half-features.
- 3Use AI tooling visibly and well. Drive Cursor's agent to scaffold the boilerplate, then review and correct what it generates out loud. Showing judgment over AI output is the signal, not raw speed.
- 4Write the runbook as you go. A short README: what it does, how to run it, the env vars it needs and the one thing that would break it. This is the "owned end-to-end" evidence.
- 5Leave time to demo it running. End on a live run, not a code tour. Then narrate the two decisions you'd revisit with more time.
Say it like this
"I had the agent stub the Slack handler and the Okta client, but I rewrote the error handling myself. The generated version swallowed failures silently, and for an access tool I want every failed grant to be loud and logged."
That answer shows fluent AI use, critical review of AI output and the security instinct this role demands. Those are the three signals to practice surfacing in any build.