Ask Claude for a "What Could Go Wrong" List Before You Ship
After Claude finishes implementing a feature, do not ship it immediately. Instead, ask it to write a "what could go wrong" list first.
"Before we merge this, write a list of everything that could go
wrong with this implementation. Think about edge cases, race
conditions, error handling gaps, and security issues."
This gives you a systematic second review from the same context that wrote the code. Claude already understands every line it just produced, so it can spot problems that a fresh reviewer might miss on first pass.
The results are surprisingly thorough. You will often get back things like:
- Missing null checks on optional fields
- Race conditions in async operations
- Unhandled error paths that silently fail
- Input validation gaps that could cause unexpected behaviour
It only takes a few seconds and frequently catches real issues. Think of it as a built-in QA step that costs nothing but a single prompt.
You can also make this a habit by adding it to your CLAUDE.md as a post-implementation instruction so Claude does it automatically.
Your best reviewer already knows the code. Just ask.
via @TomilolaNa53446
Log in to leave a comment.
Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.
Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.
Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.