Tuesday morning: checkout works fine. Tuesday afternoon: twelve angry emails.
I maintain a Shopify Plus store for a mid-sized outdoor gear brand that ships across the EU. We sell hiking boots, waterproof jackets, tents—nothing exotic. Tuesday morning I pushed a small update to our checkout scripts: a new line to track which payment method customers select, so we could finally answer whether anyone actually uses bank transfer. Deployed at 11:00, tested three dummy orders, everything cleared. I went to lunch.
By 15:30 I had twelve support emails, all variations of "payment failed but my bank shows the charge" or "stuck on loading screen after I clicked Pay". Every single one was either SEPA direct debit or Klarna. PayPal and cards worked fine. The error logs showed a 500 from our webhook endpoint, but only intermittently—maybe one in five attempts. I rolled back the script change. Errors kept coming.
I spent two hours reading Shopify's webhook documentation, checking our Heroku logs, and running test orders in incognito windows. Nothing obvious. The webhook code hadn't changed in four months. SEPA and Klarna both hit the same endpoint, but so does PayPal, and PayPal was fine. I needed a second pair of eyes, and my backend developer was on holiday in Portugal.
So I opened Kryotta and fed the problem to Claude Sonnet 4.5 and Gemini Pro. Not because I thought AI would magically fix it, but because explaining a bug to something that asks clarifying questions often surfaces what you missed. What I didn't expect was how differently the two models approached the same logs.
Claude wanted the whole story. Gemini wanted the data first.
I started with Claude. Pasted the error logs—about forty lines showing intermittent 500s from /webhooks/payment/confirm—and wrote: "SEPA and Klarna checkout failing randomly after I added one tracking line to checkout scripts. PayPal works. Rolled back the change, still broken. What am I missing?"
Claude asked for the tracking line I'd added. Then it asked what the webhook does when it receives a payment confirmation. Then it asked whether SEPA and Klarna send their webhooks at different times compared to PayPal. Three questions before it offered a hypothesis.
When I gave it the webhook code—a Node.js function that validates the payload, writes to our database, and sends a confirmation email—it pointed out that SEPA and Klarna both send a pending status first, then a second webhook with completed a few seconds later. PayPal sends completed immediately. Claude's theory: the two webhooks were arriving close enough together that the database write from the first one hadn't finished when the second one tried to read it. A race condition. The tracking script hadn't caused it, but deploying anything had restarted the server and changed the timing just enough to make a latent bug visible.
I switched to Gemini Pro and pasted the same logs with the same question. Gemini's first response was a numbered list: five possible causes, from "webhook signature validation failing" to "database connection pool exhausted". Confident, specific, mostly wrong. I gave it the webhook code. It highlighted the database write and suggested wrapping it in a transaction. Reasonable advice, but it didn't explain why only SEPA and Klarna failed, or why the rollback didn't fix it.
I asked Gemini directly: "Why would this only affect SEPA and Klarna?" It rephrased the symptoms back to me—"these payment methods may send multiple webhooks in quick succession"—but didn't connect that to the race condition until I fed it Claude's hypothesis and asked it to evaluate. Then it agreed and suggested the same fix Claude had already given me: add a row-level lock or check for existing records before writing.
The fix took ten minutes. Getting there took three hours.
I added a SELECT ... FOR UPDATE lock to the webhook handler so the second request would wait for the first one to finish. Deployed, tested twenty SEPA orders in a row, all cleared. The bug was gone. Total code change: two lines.
But here's what mattered: Claude's reasoning process matched how I'd debug this with a human. It asked about the context, noticed the pattern in the timing, and built a hypothesis that explained all the symptoms. Gemini gave me a checklist of common problems, which would've been helpful if I didn't already know the webhook code was sound. When you're staring at logs at 17:00 and nothing makes sense, you don't need five generic suggestions—you need one person (or model) to say "here's what I think is happening, and here's why".
That doesn't mean Claude is always better. Two days later I had a CSS bug where a product image was overflowing its container on mobile, but only in Safari, and only on product pages with more than four variants. I gave both models the HTML and stylesheet. Gemini spotted it in fifteen seconds: a flexbox property that Safari interprets differently when the container has a dynamic height. Claude asked three clarifying questions about the layout before suggesting the same fix. For a narrow, visual problem with a clear scope, Gemini's directness won.
When to use which model for debugging production issues
I've now used both models to debug maybe a dozen issues—checkout bugs, API rate limits, broken email templates, a webhook that stopped firing after a Shopify API update. A rough heuristic has emerged.
Use Claude when the bug is intermittent, context-dependent, or involves timing. Race conditions, authentication flows that fail only for certain user types, webhooks that behave differently depending on the payload—anything where the answer is "it depends". Claude will ask for the surrounding code, the sequence of events, what changed recently. It's slower, but it's thinking about causality.
Use Gemini when the bug is narrow and the symptoms are clear. A function returns the wrong value, a CSS rule doesn't apply, an API call gets a 403. Give Gemini the specific code block and the error message. It'll scan for the obvious mistakes—typos, wrong variable names, missing imports—faster than you will. If the first suggestion doesn't work, ask it to try again with more context, but don't expect it to intuit what you didn't tell it.
For anything involving payment providers, give both models the full webhook payload and the provider's documentation. Stripe, Mollie, Adyen, Klarna—they all have slightly different retry logic and status codes. I've learned to paste the relevant doc section into the chat alongside the logs. Claude uses it to refine its hypothesis; Gemini uses it to check whether your code matches the spec. Both helpful, different angles.
One more thing: don't trust either model's first answer if it involves security or GDPR compliance. I asked both how to log payment errors without storing card details. Claude suggested hashing the last four digits, which is fine. Gemini suggested logging the full payment_method object and redacting it later, which would've been a nightmare if we'd ever had a data breach. Always verify anything that touches customer data against the actual regulations or your DPO's guidance.
My debugging workflow now: logs to Claude, fixes to Gemini, humans for the final call
When something breaks in production, I open Kryotta and start a chat with Claude Sonnet 4.5. I paste the error logs, describe what changed recently, and let it ask questions. If it lands on a hypothesis that makes sense, I'll switch to Gemini Pro and ask it to review the specific function or code block Claude identified. Gemini's faster at spotting syntax errors or suggesting a cleaner way to write the fix.
Then I test the fix in staging, read the code again myself, and deploy. The models don't replace thinking—they replace the part where you explain the problem out loud to a rubber duck, except the duck occasionally says "wait, have you checked whether those two webhooks are arriving in order?"
I still ask a human when the stakes are high—anything that could charge a customer twice, expose data, or take the site down. But for the everyday "why is this failing on Tuesdays" problems, Claude and Gemini together get me unstuck faster than scrolling Stack Overflow and hoping someone had the exact same issue in 2019.
The race condition bug cost us maybe €800 in lost sales and two hours of support time cleaning up the failed orders. The fix cost me three hours and the price of a Kryotta subscription. I'll take that trade.
Questions people ask
Can I just paste error logs into ChatGPT instead of using Claude or Gemini?
You can, but Kryotta lets you compare both models side-by-side in the same workspace, and you're not fighting a consumer UI that wants to sell you a subscription every third message. If you already pay for ChatGPT Plus, try it—but I've found Claude better for debugging and Gemini faster for narrow fixes.
What if the bug involves proprietary code I can't share?
Redact customer data, API keys, and anything covered by your NDA, then share the structure. Both models are good at reasoning from pseudocode or anonymised examples. "Function A calls Function B, which writes to table X, and sometimes returns null" is enough to start.
Do I need to know how to code to use this method?
Yes. These models help you think through a problem, but you still need to understand the fix they suggest and why it works. If you're hiring a developer, send them this article—they'll get more done faster.
Which model is better overall?
For debugging: Claude if the problem is complex, Gemini if it's narrow. For everything else, try both and see which one's reasoning style matches how you think. I use Claude for planning and Gemini for execution, but your mileage will vary.
If you're debugging production issues alone and need a second perspective, try Claude and Gemini together in Kryotta. Compare their reasoning in one workspace, switch models mid-conversation, and keep your chat history organised by project. First two weeks free, no card required.
