Code review any function or PR with Crade
Crade reads the code on your screen and flags bugs, security issues, performance problems, and style nits. Use it before you push, or as a second pair of eyes on a PR.
Review this code for bugs, security issues, and obvious cleanup.
Bug (line 8): rawQuery uses string interpolation. SQL injection risk. Use parameterized query: db.query(sql, [userId]) Bug (line 12): error swallowed. Logging without rethrow means callers think the operation succeeded. Performance (line 14): single query inside the loop. 200 users = 200 queries. Use IN clause. Nit: rename users to userList for clarity. users is shadowing the import. Priority: fix the SQL injection first.





Code review is high-value but easy to skip when you are reviewing your own code at 5 PM on a Friday. Crade reads the code on your screen and gives you a structured review: what looks wrong, what might break, and what is fine but could be cleaner. It is not a replacement for a senior reviewer, but it catches the obvious stuff before they have to.
What you put on your screen
- The diff in your editor (VS Code, JetBrains, your terminal git diff)
- The GitHub or GitLab PR view
- A single function or file you want a quick gut-check on
What you say to Crade
Or focused: "Is there a race condition here?", "What is the worst case for performance?", "Should this be a transaction?".
What you get back
- Bugs Crade is fairly confident about (with line references)
- Possible issues that need verification ("this might race if X happens")
- Security concerns (unescaped input, leaked secrets, auth bypasses)
- Performance flags (N+1 queries, unbounded loops, memory issues)
- Style nits, but only if you ask
Tips for better reviews
- Tell Crade your priorities. "I care about correctness first, performance second, style not at all." Saves time.
- Share the surrounding context, not just the diff. A 10-line function review is more accurate when Crade can see the imports and the calling code.
- Ask for the negative: "What is the worst case here?" Catches edge cases.
- For PR reviews, ask Crade to summarise the diff in plain English first. Helps you spot if your changes drifted from the stated intent.
- Use Crade as preparation for human review: "What should I ask my reviewer to look at?" identifies the parts worth their attention.
Frequently asked questions
Does Crade replace human code review?
No. Crade is great at common patterns and catches the obvious things. Senior reviewers bring architecture judgement, team context, and product knowledge Crade does not have. Use Crade to clean up before review, not instead of.
How accurate is Crade at finding real bugs?
Very good on common categories (null checks, off-by-one, unhandled errors, race conditions). Less accurate on subtle algorithmic issues or framework-specific gotchas. Treat Crade's flags as hypotheses, verify before acting.
Can Crade fix the bugs it finds?
On Pro Agent mode, yes. Crade can edit the file directly after you confirm the fix. For review-only mode, Crade gives you the suggested patch in chat and you apply manually.
What languages does Crade review?
All major languages (JavaScript, TypeScript, Python, Go, Rust, Java, Swift, Kotlin, Ruby, PHP, C++, etc.) plus configuration files (Terraform, Kubernetes YAML, Dockerfile).
Can Crade enforce my team's style guide?
Crade respects whatever style is in the visible code. For specific rules, tell Crade: "We use camelCase, single quotes, no semicolons." Crade adapts.
The whole loop in one sentence
Code on screen, one prompt, structured review back. Catches the obvious before the senior reviewer has to.
A brief lands in your Notes app. Thirty seconds later, the landing page is open in your browser. Here is what to put in front of Crade, what to say, and the exact step-by-step from brief to live preview.
Build red. Stack trace. Module not found. Type mismatch. Crade reads your editor, terminal, and error output on screen and tells you exactly what is wrong and how to fix it.
Crade reads your database schema on screen and gives you the exact SQL for what you actually want, in PostgreSQL, MySQL, BigQuery, or whatever you are running.