A QA robot that tests checkout before every change

The short version

One command, about 65 seconds. The robot buys on a test copy of my store, on desktop and mobile, and tells me if anything broke. This project won the harness challenge in Ricardo Celis’ class at Gradiente School of Engineering on October 8, 2026.

Context

I run an online perfume store. Every time I change something, a price, a line of copy, a section, I can break checkout without noticing. And if checkout fails, I lose sales without ever finding out.

In Ricardo Celis’ class, the challenge was to build our own harness, show it working and make a video. I picked the problem that hurt most in my business.

The problem

• Checking checkout by hand after every change is slow and boring, so in practice it doesn’t happen.
• What works on desktop can break on mobile, and most of my customers buy on their phones.
• A small bug, like a marketing opt-in box ticked by default, can become a legal and trust issue.

The approach

A harness is the frame around automated work: the rules, the limits, the tests and the evidence. The core idea was this: AI doesn’t need more freedom. It needs clear rules.

So the robot has hard limits:

• It never touches the live store. It runs on a test copy with synthetic data.
• It makes no real purchases or payments.
• It can’t say “done” without evidence: a video, a trace and a summary.
• It tests itself. I plant a bug on purpose and it has to catch it. If it doesn’t, the robot is useless.

What I built

• One command that spins up the test copy of checkout.
• A full walkthrough on desktop and mobile: fills the form with synthetic data, leaves marketing opt-ins unticked and places the order.
• A negative test. It plants a defect, opt-ins ticked by default, and the robot catches it on both screen sizes.
• Evidence at the end. A video of the run, the technical trace for debugging and a summary in Spanish anyone can read.

I built it with Claude Code and Codex. I defined what it should check, what it must never touch and what counted as done. The agents wrote the code and tests. I reviewed and ran everything before recording.

Demo and status

• Status: pilot in my own store.
• Demo results: 20 of 20 checkout cases green, 60 unit tests and a correct negative test. The full demo, video included, takes about 65 seconds.
• Honest limit: it runs on a copy with synthetic data. It doesn’t certify the live store, payments or the CRM.
• What came next: using the same idea, I built a second reviewer that checks the live store for design, content and SEO issues, and tests the purchase flow right up to payment.

What I learned

• A robot that never fails proves nothing. The negative test is where the value is. If it can’t catch a bug I planted myself, I won’t trust it when it says everything’s fine.
• Evidence sells. The video and the plain-language summary were what people liked most in class. A business owner won’t read a trace. They will watch a video and read a summary.
• Being honest about it counts too. In the video I said the robot tests a copy with fake data. I’d rather say that than let someone think I certify real payments.

What broke and how I found it

• A robot that always said “all good”. Before the negative test, there was no way to tell a working robot from a broken one. I planted a bug on purpose (marketing opt-ins pre-ticked) and made two tests fail because of it, on desktop and mobile. Now every run proves the detector works.
• “Done” without evidence. A run could end with a missing video or a stale trace and still look finished. The coverage check now rejects skips, failures, retries and evidence that is missing, altered or belongs to other code.
• A busy port tested the wrong thing. If port 4173 is taken, the runner refuses to start instead of reusing an unknown server. Better to fail than to test someone else’s app.

Does your store or site need this?

If you run an online store, a contact form or a booking flow, a robot like this warns you before your customer does.

Message me on LinkedIn