A few weeks ago, a wellness clinic running KiviCare (a WordPress-based clinic and patient management system) asked me for something that sounded simple: “When a patient pays their invoice via Stripe, automatically email them a thank-you message with a PDF receipt attached.”
I built the entire thing – diagnosis, fixes, and final feature — working with Claude as my AI coding partner. Not by asking it to “write me a payment integration” and hoping for the best, but through a working style I think more people should understand: treat the AI like a very fast, very well-read engineer who still needs real evidence, not vibes, before you trust its fixes.
Here’s the journey, and the specific ways of working with Claude that made it actually land in production.
The problem looked simple. It wasn’t.
“Email a receipt after payment” turned out to involve four separate codebases: KiviCare’s free core plugin, a paid Pro add-on, a commercial Stripe gateway add-on, and a bespoke custom add-on built specifically for this clinic by a previous developer.
The first thing I did – and the first habit I’d recommend to anyone doing this kind of work – was upload the actual plugin source code as zip files directly into the conversation, rather than describing the problem in the abstract. Claude unzipped them, grepped through the PHP, and traced real function calls and WordPress hooks across all four codebases. That distinction mattered enormously: an AI reasoning from “how WordPress plugins typically work” would have guessed wrong at almost every turn. An AI reading the actual files found the real hook names, the real database schema, the real bugs.
Round one: a crash, and a lesson in verifying instead of assuming
My first fix (adding proper Stripe Sandbox/Live mode switching) took the client’s live site down with a fatal PHP error.
This is where working with Claude effectively meant something specific: I gave it the exact error message and full stack trace, not just “it’s broken.” Claude traced the trace line by line, identified that the deployed code assumed a newer plugin version than what was actually installed, and fixed it by making the method self-contained rather than dependent on a version that might not exist. No guessing — the stack trace was the evidence, and the fix was built directly against it.
Round two: the bug wasn’t where either of us initially thought
After that fix, Stripe test mode still didn’t work. Instead of patching the same file again, Claude went back into the bespoke add-on’s source and found the real issue: the clinic’s actual live payment flow ran through a completely different, custom-built “Payment Link” feature — with its own separate Stripe integration that ignored the sandbox/live setting entirely.
This is the single biggest thing I’d tell anyone using AI for real debugging: a good AI collaborator doesn’t just fix the file you point it at – it verifies which code path is actually running before trusting that’s the right file at all. That only works if you let it read the whole system, not just the piece you assume is broken.
Round three: logs and databases as the actual source of truth
Once the payment flow worked, the notification pipeline needed the same treatment. Over several rounds:
I pasted raw PHP error log output back to Claude – not a description of the bug, the actual log lines – and it traced the exact function call that silently failed
A property-name bug ($patient->user_email vs. the model’s real $patient->email) was only findable by having Claude grep the actual ORM class definitions, not by assuming standard WordPress field names
I ran a SQL query Claude gave me against the live database and pasted the result back, which is how we confirmed a template lookup issue in seconds instead of guessing
A mysterious 2–3 minute email delay was traced to a background task queue – again, found by asking Claude to trace the actual function being called, not by re-describing symptoms
The pattern across all of these: I never asked Claude to “just try something else.” I fed it hard evidence – logs, stack traces, query results – every single time, and it reasoned from that evidence to a specific, verifiable fix.
Round four: making Claude prove its own work before I tested it
The last stretch – building a properly branded PDF receipt with a real letterhead, sequential numbering, and precise layout – is where this really clicked for me. When I asked for pixel-level alignment fixes, Claude didn’t just hand me CSS and hope it looked right. It actually rendered the real HTML template end-to-end and numerically measured where elements landed in the output, catching a genuine bug (a table silently rendering at half its intended width) that would have been very easy to miss by eye. It only presented the fix to me once it had evidence the fix worked, not before.
That’s the difference between an AI that outputs plausible-looking code and one you’re using as a genuine engineering partner: it verifies before it hands you the answer.
What I’d tell anyone trying to use Claude (or any AI) for real engineering work
Upload the real source, not a summary of it. The moment I stopped describing the plugins and started handing over the actual code, the quality of every fix jumped.
Give it evidence, not symptoms. “It’s broken” gets you guesses. A pasted stack trace, error log, or SQL result gets you a diagnosis.
Let it verify before you deploy. Ask for lint checks, test renders, numeric measurements – anything that turns “this should work” into “this is confirmed to work.”
Watch for the reported bug not being the real bug. The best debugging session in this whole project was the one where Claude went looking for a second code path instead of re-patching the first one.
This is not “vibe coding.” Vibe coding is accepting AI output because it looks plausible. What actually worked here was closer to pair programming with a partner who reads faster than any human and is willing to double-check everything before claiming it’s done.
Where it landed
The clinic now has a fully automated payment-confirmation system: Stripe payment completes -> the patient gets a properly worded thank-you email using their own branded template -> a professional PDF receipt is attached, with sequential numbering and their official letterhead – all within seconds.
But the more transferable outcome is the working process itself. If you’re evaluating how to actually use AI coding tools for real production work – not toy demos – I hope this is a useful, concrete example of what that looks like when it’s done with real rigor.
If you’re wrestling with a legacy plugin stack, a “simple” feature request that keeps unraveling, or you’re just curious how AI-assisted debugging actually works in practice – happy to compare notes.
Curious how others are using AI tools for real debugging work, not just code generation – what’s your process for making sure the fix is actually verified before it ships?