Boxed is the race team app I've been building since 2025. It's a web app on a phone in the car and a phone on the pit wall, tied together through Firebase, so the crew can send "BOX BOX BOX" and the driver can answer with a tap. Teams have tested it at events, and it held up across two days of racing at NJMP.

This week I gave it something it never had: official race timing. The driver now sees their real class position and the gap to the car ahead, pulled live from the timing system the track already runs, with no one typing anything. It went from idea to a full day of live racing in about two days, built almost entirely in conversation with an AI. Here's how that went, including the parts that broke.

The ask: official timing, nobody typing

Boxed already had its own GPS lap timer. What it couldn't tell you was what mattered most in an endurance race: where you stand against everyone else. That lives in the official timing, which most club events publish live online.

My opening question to the AI was simple: can we build a tool to watch a lap timer app? The first useful thing it did was split that into three very different problems: a live timing website, my RaceBox GPS unit, or a closed phone app. Only the first was worth building on. Phone apps can't be watched by another app, and talking to the RaceBox directly over Bluetooth doesn't work on iPhones.

The result is a small watcher program that runs on any computer with internet, including my desktop at home. It follows the live timing for one race, works out where our car sits, and writes a short summary to Firebase every few seconds. The pit wall and the driver's phone already listen to Firebase, so they update within a second. Nothing at the track has to change.

One design choice I'm glad we made early: the race and the car to follow are set from the pit wall app, not on the computer running the watcher. At the track, someone pastes in the race link and our car number, and a computer back home switches over within 15 seconds.

From overall position to the cars you're actually racing

Overall position is mostly noise in multiclass racing. If you're P38 overall, the car right ahead might be a C car you're lapping, and the one behind an A car about to lap you. In endurance racing the real race is inside your class: A, B or C.

So the watcher reads each car's class off the timing board and finds the nearest car in your class ahead and behind. The gap to a class rival can have ten other cars between you, so it adds up each car's gap to the one in front of it all the way along. The pit wall shows "P2 B, P12 overall" with the class gaps, and the driver sees "P2 B" in big type.

Once the data was flowing, I asked what we could do with it that was predictive. The watcher now keeps every car's lap history, throws out pit laps and traffic laps, and averages the rest into a pace. From that it works out:

• Closing rate: "gaining 0.6s a lap on the class car ahead."

• Laps to catch: gap divided by closing rate, or "not catching at current pace."

• Target lap time: what we'd need to run to catch them before the flag, given the race end time.

• Defense: the same math pointed backward at the car behind.

The driver gets one line, "T 1:59.7", meaning run that and you catch them by the end. It recalculates once a lap, at the moment our car crosses the line, so it doesn't twitch.

What broke along the way

None of this went in clean, and the failures taught me more than the features did. Each one surfaced in a real test, not in planning.

• The watcher couldn't find the timing board. The site waited on a cookie banner before loading it. The fix was to answer the banner with the most private option, then read the board.

• The pit wall said "Saved" when nothing was saved. My Firebase security rules only allowed known fields, and the app never checked whether a write succeeded. I added the new fields to the rules, and the app now says NOT SAVED in red when a write is refused.

• Class detection worked on karting and failed on Lemons. Lemons prints the class mid-row, after the team name, not at the end. We now read it from where Lemons actually puts it, tested against real rows from the race.

• Catch and defend numbers jumped every few seconds. The class gap changes whenever any car between you crosses the line. The numbers now lock in once a lap, when our car crosses.

• The watcher quit when its browser died. One hiccup ended the session. It now restarts its browser within 10 seconds and keeps the lap history.

• A home internet drop could leave stale numbers marked LIVE. The heartbeat kept saying "alive" while the board was frozen. It now stops the heartbeat after 90 seconds without a change and reloads the board after 3 minutes.

• The in-car timing box covered the clock. It was an overlay with no space of its own. The driver screen is now split, timing on the left, clock and stint countdown on the right.

• The installed phone app kept showing an old version. Offline caching served its saved copy first and held updates back. Pages now load fresh when online and fall back to the saved copy offline.

• The fuel calculator disappeared from the pit wall. A new panel cut off the rest of the page on one browser. I removed the element that broke it, then checked the live copy instead of a local one.

That last one is worth dwelling on. More on it below.

The real test: a full day at Laguna Seca

The best test data is a real race, so on Monday I pointed the watcher at a Lemons race running at Laguna Seca, roughly 40 cars across three classes. I picked a B-class car at random, entered it on the pit wall, and let my home computer run.

The first read failed because nothing had started; the board was empty before the green flag. Once cars crossed the line they appeared one by one, and within a few laps the watcher was reading the full field, 41 cars and later 44, with no missing positions. It found the car's class from the board, named the B cars ahead and behind, and its gap math matched the board's own numbers to the thousandth.

It then ran from late morning into the evening without breaking. That mattered more to me than any single feature. A tool that works for an hour in testing is a demo. One that runs all day on a live race, with the fixes from that morning in place, is something I can hand to a team.

What building this with AI taught me

The speed is real. Two days from a vague question to a feature running on a live race would have taken me weeks on my own. The lessons were less about speed than about where the AI needs a short leash.

It's good at reframing the problem. My first question was badly scoped. The most valuable answer wasn't code; it was "there are three different things you might mean, and only one is worth building."

It can be confidently wrong about your screen. When I said the fuel calculator was gone, the AI checked its own copy of the file, found the calculator there, and told me where to scroll. I was right and it was wrong: something it had added was cutting the page off on my phone. Its copy of the file told it nothing about what I was looking at. Now, when I say something is missing, the rule is to start from "what did I change that broke this," not "it's still there."

Silent success is the worst failure. The pit wall cheerfully said "Saved" while the database refused every write. Nothing crashed, so nothing looked wrong. A tool that reports success without checking is worse than one that throws an error.

Test on the real thing, early. Every simulated test passed. The real Lemons board still had its class in a different spot than the karting board I'd built against, and that only showed up when real data arrived.

Make it ask before it builds anything I'll look at. Its first pass at the in-car layout was a guess, and a bad one. When I told it to ask questions instead of just acting, it came back with four short multiple-choice questions, and the next version was right the first time.

Next up is running it for my own team this weekend, from the computer at home, and then seeing whether a handful of other teams want the same thing.