Step 1 of 4
Audit the current approval moments
Count them, read them, feel the fatigue.
Audit approvals as they exist. Instrument or review recent sessions and collect: approvals per task (average and worst case), what each prompt actually displayed, time-to-decision per approval, and any decline-then-nothing dead ends. Classify prompts by information sufficiency: could the user decide correctly from the prompt alone, or did they approve on faith? Interview or observe one real user session if possible. Deliver the audit: the fatigue numbers, the faith-approval percentage, and the three worst prompt examples verbatim.
Expected after this step
A fatigue-and-sufficiency audit with concrete numbers.
Should not happen
- ✕Approval prompts that say 'Agent wants to edit file.js - Allow?' with no diff
- ✕Every ask styled identically, so rm approval looks like ls approval
- ✕No session grants, generating twenty prompts for twenty edits of one file
- ✕Unmeasured fatigue, discovered only when users disable safety wholesale
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Approval prompts that say 'Agent wants to edit file.js - Allow?' with no diff
- !Every ask styled identically, so rm approval looks like ls approval
- !No session grants, generating twenty prompts for twenty edits of one file
- !Unmeasured fatigue, discovered only when users disable safety wholesale
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
No instrumentation exists to audit. Add approval-event logging first (prompt content, decision, latency) and run three real tasks - the redesign needs a baseline to beat.