I started with Claude because everyone said it was best for code
I work on Shopify apps and WooCommerce plugins—mostly payment integrations for Indian stores. Razorpay, UPI, Paytm, that sort of thing. When a client pushes a PR at 11 p.m. and wants it merged by morning, I used to spend two hours reading diffs, checking for SQL injection risks, making sure they didn't hardcode an API key somewhere obvious. Then I'd write six comments, they'd fix three, and we'd do it again.
Last month I decided to test whether AI could handle the first pass. I picked three models—Claude Sonnet 4.5, Gemini Flash and DeepSeek V3—and ran them against 60 pull requests from February and March. Small PRs, mostly: a Razorpay webhook handler, a WooCommerce cart discount function, a Shopify metafield sync. I wanted to know which model caught logic bugs, which one was better at style consistency, and whether any of them could spot the security issues I'd normally catch on my third read-through.
The short answer: no single model did everything well. Claude caught edge cases I'd missed. Gemini was faster for style checks and could explain why a function was confusing. DeepSeek spotted a race condition in a UPI callback that both other models ignored. I ended up using all three, each for a different part of the review, and I got through 60 PRs in about half the time.
The checklist: which model for which task
Here's the workflow I use now. I open the PR in Kryotta's compare arena, paste the diff, and run three prompts in parallel—one for logic, one for style, one for security. Then I read all three outputs side by side and decide what to comment on.
Logic bugs and edge cases: Claude Sonnet 4.5. This is where Claude beats the others. I give it the diff and a prompt like "Check this function for edge cases: empty arrays, null values, unexpected input types. Flag anything that could throw an error in production." It caught a bug in a Razorpay signature verification function where the developer assumed razorpay_payment_id would always be present in the webhook payload. It's not—if the payment fails before the ID is generated, the payload is missing that key and the function crashes. Gemini didn't mention it. DeepSeek said "consider validating input" but didn't point to the specific line.
Style and readability: Gemini Flash. Gemini's better at explaining why code is hard to read. I use it for PRs where the logic is fine but the function names are terrible or the nesting is three levels deep. Prompt: "Review this code for readability. Are variable names clear? Is the structure easy to follow? Suggest improvements." It told me a function called processData() should be calculateGSTFromCartTotal() because "processData doesn't tell the next developer what the function does or what data it's processing." That's useful. Claude would've said "consider renaming," but Gemini gave me the better name.
Security: DeepSeek V3. This was the surprise. I thought Claude would win here, but DeepSeek caught two issues Claude missed. One was a race condition in a UPI callback handler—two requests hitting the endpoint at the same time could mark the same order as paid twice. The other was an API key that wasn't hardcoded but was logged in plaintext when the payment gateway returned an error. Prompt: "Check this code for security issues: SQL injection, hardcoded secrets, race conditions, unvalidated input." DeepSeek's reasoning model shows its work, so I could see why it flagged the race condition. It walked through the sequence: request A reads order status, request B reads order status, both see "pending," both update to "paid."
Dependency and package checks: Gemini Flash. If the PR updates package.json or composer.json, I run a separate prompt asking Gemini to check for version conflicts or deprecated packages. It's faster than Claude for this and doesn't try to reason through every transitive dependency. Prompt: "Check this dependency update for breaking changes and version conflicts." It flagged a Razorpay SDK update from 1.0.5 to 2.0.0 that changed the signature of verifyWebhookSignature(). I wouldn't have caught that until the webhook failed in production.
How I compare outputs in Kryotta without switching tabs
I used to run prompts in three separate windows and alt-tab between them. Now I use Kryotta's compare arena. I paste the PR diff once, write three prompts, and send them to Claude, Gemini and DeepSeek at the same time. The outputs show up side by side in three columns. I can see which model caught what, where they agree, and where one model found something the others missed.
Example: a PR that added a discount code validator to a WooCommerce checkout. Claude said "check if the discount code exists in the database before applying it." Gemini said the same thing but added "also check if the code has expired or hit its usage limit." DeepSeek said both of those, then added "if two users apply the same single-use code at the same time, the second one should fail." That's the race condition again. I wouldn't have thought to test for it.
The compare view also makes it obvious when a model hallucinates. One time Claude told me to use a verifyUPISignature() function that doesn't exist in the Razorpay SDK. Gemini and DeepSeek both gave me the correct function name, so I knew Claude was wrong. If I'd only used Claude, I'd have wasted 20 minutes looking for that function.
The mistakes all three models made
None of them understand your codebase. If the PR references a helper function defined in another file, the model won't know what that function does unless you paste it into the prompt. I had a PR that called sanitize_order_meta() and all three models said "make sure this function validates input." It does—it's defined in includes/helpers.php and I wrote it two years ago—but the models couldn't see that. I now paste relevant helper functions into the prompt if the PR depends on them.
They also don't know your conventions. If your team always uses snake_case for function names and someone submits a PR with camelCase, the models won't flag it unless you tell them your style guide. I added a line to my style prompt: "Our functions use snake_case, variables use snake_case, classes use PascalCase." Now Gemini catches it.
And they're all bad at estimating performance impact. I had a PR that added a database query inside a loop—querying the wp_postmeta table once for every item in the cart. That's a disaster if someone has 50 items. Claude said "consider caching this query," which is true but vague. Gemini said "this could be slow with large carts," also vague. DeepSeek didn't mention it. I ended up catching it myself because I know that query is slow. If you're reviewing performance-critical code, don't trust the model—test it.
When I still do the review myself
I don't use AI for PRs that change payment logic or anything touching customer money. If someone modifies the Razorpay webhook handler or the UPI callback, I read every line myself. The models are good at catching syntax errors and missing null checks, but they don't understand the business risk of marking an order as paid when the payment actually failed. That's a refund, a support ticket, and maybe a lost customer.
I also don't use AI for PRs from junior developers who are still learning. If someone's first PR has 15 style issues and two logic bugs, I'd rather write detailed comments explaining why the code is wrong than paste an AI summary. The AI will tell them what to fix, but it won't teach them how to think about the problem. I'll use AI to check my own review before I post it—"did I miss anything?"—but the comments are mine.
The workflow I use now for every PR
- Open the PR in GitHub, copy the diff.
- Open Kryotta's compare arena, paste the diff.
- Run three prompts in parallel: logic (Claude), style (Gemini), security (DeepSeek).
- Read all three outputs side by side. If they agree, I trust it. If one model catches something the others missed, I investigate.
- If the PR touches helper functions or shared code, I paste those into a follow-up prompt and ask Claude to check for integration issues.
- Write my review comments based on what the models found, plus anything I caught myself.
- If it's a payment or security-critical PR, I do a full manual review even if the models said it was fine.
This gets me through 60 PRs in about 15 hours instead of 30. I'm not reviewing faster—I'm spending less time on the easy stuff (style, obvious bugs) and more time on the things that actually matter (business logic, edge cases, performance). The models do the first pass. I do the second pass. The code's better for it.
Questions people ask
Can I use Auto routing instead of picking models manually? You can, but I don't recommend it for code review. Auto routing picks the fastest, cheapest model that meets your quality bar, which usually means Gemini Flash or GPT-OSS. Those are fine for style checks, but they miss the edge cases Claude catches and the security issues DeepSeek finds. I'd rather spend an extra minute running three models in parallel than save ₹5 and miss a bug.
What if the models disagree on whether code is correct? Trust the one that shows its reasoning. DeepSeek and Claude both explain why they flagged something. If Gemini says "this looks fine" and DeepSeek says "this could cause a race condition" and walks through the scenario, I investigate DeepSeek's claim. If I still can't decide, I test the code.
Do I need to write different prompts for each model? Not really. I use the same logic prompt for all three: "Check this function for edge cases: empty arrays, null values, unexpected input types. Flag anything that could throw an error in production." The models interpret it slightly differently—Claude's more cautious, Gemini's faster, DeepSeek digs into concurrency—but the prompt works for all of them.
How much does this cost per PR? About ₹8 to ₹15 if I run all three models on a 200-line diff. Claude's the most expensive (₹10–12 per review), Gemini's cheaper (₹3–5), DeepSeek's in the middle (₹5–7). I could cut costs by only using Gemini, but I'd miss bugs, so I don't.
I've been using this workflow for six weeks and I'm not going back. The models don't replace me—they handle the tedious parts so I can focus on the parts that need a human. If you're reviewing code on your own or for clients, try running the same PR through two or three models in Kryotta's compare arena and see what each one catches. You'll find bugs you'd have missed, and you'll get faster at spotting the patterns the models can't see.
