Built with AI, checked hard

I run an IT business: managed services, cloud and phone systems. DyComDrive is the first system I’ve built to run a transport service of our own.

How it was built

On 22 August 2026 I wrote down what the system had to do, and the things it must never do: show a rider’s name or exact pickup time publicly, let anyone edit a booking’s history, or charge more than the written quote.

On 23 August I started building, at 9:10 am. I designed it and directed the work; most of the code was written with Claude, an AI coding assistant. Of the 147 changes made to the code between 23 August and 7 October 2026, 136 were written with it, and one person directed all of them.

Up to 30 September it was all concept and build: designing, building, testing. On 30 September our booking entity authorisation took effect, and the system began running under it.

How I checked it

AI writes code fast, and it writes bugs just as fast. So the checking started on the first morning.

• Adversarial review. Every major change went to a team of AI reviewers whose only job was to find what was wrong with it. The first review found 12 problems, and they were fixed by 9:47 am on day one. The biggest rounds later confirmed and fixed between 12 and 42 problems each. Before we were ready to run under our own BEA, the work went through three rounds of checking, and every one found real bugs.
• Automated tests on every change. From 26 August, every change runs the full end-to-end test suites against a fresh, throwaway database before it can go anywhere. A run takes about three minutes. On its first day it caught four bugs that had only “worked” because of how one Windows computer was set up. By 7 October there were 37 test files, covering fares, quotes, receipts, texts, the shift log and the reports.
• A database copy before every release, so we can go back if a release goes wrong.

The kind of decision this makes possible

The driver app works without signal: it shows the last day sheet. But it deliberately refuses to record a tap (“rider on board”, “trip finished”) while offline. A tap saved and sent later would be stamped with the wrong time, and a wrong time on a legal record is worse than no time. That’s the kind of rule that is easy to write down and easy to forget, which is why it’s tested.

What I’d tell you

Don’t skip the review and the tests because the code arrived quickly. If the law relies on your records, that’s where the risk is.