I told myself three times that checking requirements was a good idea
This is part three of building the live demo for my apidays Australia 2026 workshop with Claude Code. Part one covered the structural flaw in the original FGA model; part two covered the Vercel Sandbox mistest and the Neon database that snuck into the codebase against my own stated constraints. This post is about a smaller, more embarrassing pattern I only noticed because I went looking for it: I checked the plan against the original brief three separate times in the same session, and every time, I described the check to Claude as though it were the obvious thing to finally be doing - never once noticing I'd said more or less the same sentence twice already.
The first time, disguised as a design question
The session started with a question that didn't look like a requirements check at all: did the app still need demoState, the Firestore doc a presenter would flip to unlock the room mid-talk, given the actual goal was a demo attendees could run themselves? I'd already told Claude, more than once, that the delegation toggle should be something a user flips on their own case, not something gated behind a live room. Claude pulled the thread and three separate mechanisms came apart at once: the room switch itself, a two-deployment split that existed purely to stop a room-state leak, and - only once I asked a direct follow-up in the same breath - the /admin role gate, which turned out to be hiding the entire second half of the demo's brief behind a role only a presenter could grant. None of that got flagged by Claude on its own. It took a plain question about whether a mechanism still made sense, asked by me, to unwind three layers of infrastructure that had all quietly survived a redesign that made them pointless.
The second time, with the brief in hand
A day later I pasted the actual brief back in and asked Claude to recheck the plan, the build, and the demo story against it properly. Claude's own response to that request included this: "This is exactly the kind of check that should have happened before now, and it's a real opportunity to catch drift systematically rather than one question at a time." Read on its own that's a reasonable thing to say. Read next to what had happened the day before, it's Claude describing the exact same realisation it should already have had - that requirements need checking against systematically, not just when something happens to trigger a question - as though this were the first time either of us had thought of it. The check itself was genuinely useful: it found that the RBAC requirement (Auth0 securing APIs "at a high level with roles/permissions" as well as fine-grained FGA) had been silently dropped the day before, when the /admin role gate got removed for the self-directed-demo goal. Nobody had noticed that removing the gate also removed the only RBAC in the entire app. The fix was a persona choice at signup - citizen or caseworker, a real Auth0 role, still no presenter, still no grant script - which restored the RBAC story without reintroducing the privileged-operator problem the gate removal was solving in the first place.
The third time was you telling me
By the time I asked whether a second adversarial review was worth running, I'd already forgotten - or never registered - that this was the third time the same underlying question had come up. It wasn't until I drafted this exact post that the pattern became visible from the outside: three separate "let's go back to what was actually asked for" moments, and I'd narrated each one to myself as a discovery rather than a recurrence. The second adversarial review, run the same way as the first (two reasoning-tier models via the internal LiteLLM proxy, this time reviewing the plan and the actual code together), found real things - a race condition in the citizen-provisioning code, a crash risk if a case existed with no matching agent record, and a contradiction I'd written into the plan myself earlier that same session, where one section said the app used a single shared AI-agent identity and another still described the per-citizen agent IDs the code had actually used the whole time. Checking that specific contradiction against the tradeoff rather than just picking a side turned up something worth keeping: per-citizen agent identities are the better design anyway, because isolation between citizens doesn't depend on every authorisation tuple's target being correct - it's structural, since each citizen's AI agent is simply a different principal from every other citizen's.
What actually needed to change
None of the three checks were wasted, and I'm not trying to talk myself out of having done them. What was missing wasn't the checking - it was noticing that checking kept being necessary, and asking why. A requirements pass that has to be reinvented from scratch each time isn't a process, it's a lucky question. The fix was small: a short "requirements checklist" section went into the build plan itself, mapping every line of the original brief to its current status, so the next time something drifts, the check is a lookup rather than a full re-read of a two-hundred-line document. Whether that actually stops a fourth recurrence is not something I can claim from inside the same session that produced the first three.
Final Thoughts
The pattern here is smaller than the FGA flaw in part one or the Sandbox mistest in part two, but it might be the more useful one to notice, because it's not about a single wrong technical decision - it's about how easy it is to have the right instinct repeatedly without it ever becoming a habit. Claude flagged its own suggestion as overdue three times without once cross-referencing that it had said something similar before, and I didn't catch it either until I sat down to write about it. If you're running a similar build with an AI collaborator doing the typing, the thing worth watching for isn't whether it ever suggests checking the requirements - it will, probably more than once - it's whether anyone notices when the same suggestion keeps arriving as if it were new.