The bug we'd have chased for a week, we found by lunchtime

Some bugs arrive with a big bang. Others just quietly cost a client money for weeks before anyone can prove what's happening. We experienced the latter recently, on a client's high-volume online store. This particular site sees a fair portion of orders placed manually over the phone, which staff manage as 'admin' customers. Every so often, an order would go out with wrong information, and nobody could work out why, because by the time anyone looked, the evidence was gone.

Building a tool to catch it red-handed

The usual approach to a bug like this is educated guesswork: read the code, form a theory, test it, repeat until something sticks. It is slow, and on a site with this many moving parts, it can eat into a week before you are confident you have found the real cause rather than a coincidence. This time, we used AI to help us build a small diagnostic plugin that watched the checkout process in real time and logged exactly what happened at every step, for every order, over a couple of weeks of normal trading.

That log turned out to be the whole answer. Under a specific, repeatable workflow, the checkout process wasn't clearing session data between orders the way it should have. It was not visible in normal testing, because it only showed up under that specific pattern of how the team actually used the admin panel day to day. Once the log showed us that pattern clearly, the fix itself took a fraction of the time the diagnosis had.

Then a second bug showed up, and the same method found it

Fixing the first issue exposed a related one. Some shipping and billing details weren't carrying through correctly on their way to the client's external delivery and tracking system. Same method, same result: log everything happening at that point in the process, let the pattern surface, then go and fix the actual cause rather than patching the symptom. What would ordinarily have meant hours of a client trying to describe a confusing problem over email and phone, and us trying to reproduce it blind, became a matter of reading the logs and testing directly.

What AI can't do is the part that matters

We want to be straight about the limits here, because it is easy to let a story like this sound more automated than it was. AI helped us build the instrument that caught the bug. It did not fix the bug itself, and it could not, because it has no direct connection to a client's servers or file system. Someone still has to understand the code, know where the fault actually lives, and make the change safely without breaking something else in the process. A tool that tells you where the smoke is coming from is genuinely useful. It is not the fire brigade.

Why this matters beyond one client

On an e-commerce site, a bug like this is not cosmetic. Every order that goes out wrong is a refund, a re-delivery, or a customer who does not come back, and those costs add up fast on a busy account. We are also using the same AI-assisted approach earlier in the process now, feeding a build with everything relevant happening elsewhere on the account (client feedback, reporting notes, meeting minutes), so a site update is built with the full picture rather than in isolation from what the rest of the team already knows. Fewer things get missed because they lived in someone else's inbox.

None of this replaces the judgement that comes from years of knowing where these systems tend to break. It just means that judgement gets applied faster, and on a live account, faster is very often the difference between a quiet fix and a customer complaint.