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 - request in, API call out, 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 sentence does three things at once: it shows fluent AI use, it shows you review AI output critically and it shows the security instinct this role demands. That's the texture the work-trial is built to surface.