The Checklist
This isn't a list of things AI coding tools can't do. Most of them can, technically, if you prompt for it. This is a list of what happens by default when you don't — because that's the actual risk. Nobody skips security on purpose. They skip it because the tool didn't bring it up, and neither did they.
One more thing up front: this site has no pull request gate. Claude pushes directly to production here. I don't read the diffs. What I do instead is make sure something else is watching what ships — a nightly process that checks the result, not the code. I'm not reviewing what Claude wrote. I'm verifying what Claude did.
01 / BY DEFAULT
Covered by default
Claude does these without being asked, most of the time — because they are baked into how modern frameworks and Claude’s training tend to default.
- Parameterized queries / ORM usageReal SQL injection is rare in AI-generated code now.
- HTTPS enforcementIn standard deploy targets — Vercel and the like.
- Password hashing via standard librariesbcrypt or argon2, not rolled-your-own.
- Basic input type validation
- Reasonable CORS defaultsFor same-origin setups.
- Escaping outputIn JSX and autoescaping template engines. Anything that builds HTML from strings is not.
Verify, don’t assume — these are patterns, not guarantees.
02 / IF YOU ASK
Covered if you ask
Claude can do these well. It just won’t volunteer them unless you name the concern.
- Rate limiting on public endpoints
- Row-level security policiesSupabase / Postgres.
- Environment variable and secrets hygieneNot hardcoding keys.
- Dependency vulnerability scanning
- Least-privilege API keys and service roles
- Session and token expiration policy
- Structured logging for auditability
03 / NEVER
Never covered
Claude will not proactively do these, no matter how you phrase the prompt — because they require judgment about your specific system, your specific users, and your specific threat model.
- Penetration testingUnprompted, no. Building the nightly probe is column 04’s job; volunteering it is not something the tool does.
- Business-logic auth flawsUser A can view user B’s data by changing an ID in a request. This isn’t a syntax bug; it’s a logic gap.
- Threat modeling“Who would want to break this, and how” is a judgment call, not a pattern match.
- Secrets rotationSetting up a key is easy. Remembering to rotate it in 90 days is a process, not code.
- Monitoring and alertingClaude will add Sentry if you ask. Deciding what counts as broken, at what threshold, and who gets woken up is the part it cannot do.
- Incident response planningWhat actually happens at 2am when it breaks.
- Load testing under real trafficSynthetic tests rarely mirror how your actual users hit the system.
04 / WHAT REPLACES THE CODE REVIEW
What replaces the code review
Since there is no PR gate on this site, this is the actual safety net — a nightly automated process, not a human reading diffs.
Nightly pen test pass
Automated probes against this site’s own endpoints: auth bypass attempts, injection probes, checking for routes that shouldn’t be exposed.
Content and output validation
Whatever Claude pushed that day gets checked before it is considered live-live: no broken markup, no secrets or API keys leaked into committed content, no injected scripts if any content path touches external input.
Dependency and secrets scanning
Same cadence. Catches what a code review would have caught by eye.
Auto-rollback on failure
If the nightly pass finds something, the job reverts to last known-good automatically. It doesn’t wait for me to wake up and decide.
None of this means don't do it. It means know which list you're operating from. I don't review Claude's code here — I review Claude's results, every night, automatically. That's the trade I'm making, and it's a deliberate one, not a skipped one.