JJoche Ojeda.NET · XAF · AI · architecture
Oct 19, 20267 min read/2026/10/19/owning-an-f1-car-doesnt-make-you-a-driver/

Owning a Formula 1 Car Doesn't Make You a Driver: AI Tools, Experience and the Minority Report

AI AgentsSoftware DevelopmentCode ReviewExperienceTeamsClaude Code

I was listening to a podcast with George Hotz, the guy who unlocked the first iPhone when he was a teenager, and the conversation drifted to Into the Wild.

If you haven't seen it: it's the true story of Christopher McCandless, a young man who walks into the Alaskan wilderness in 1992 to live off the land, and dies there. The point that stuck with me from the conversation is that he wanted to be an explorer, but there was nothing left on the map to explore. So he removed the map. He went in without one, to make the journey hard enough to feel like exploration. The difficulty was artificial, and it killed him: a map would have shown him a way across the river that trapped him.

Going without the map didn't make him an explorer. It made him a man without a map.

The Formula 1 car

I keep coming back to a related idea: owning a Formula 1 car doesn't make you a Formula 1 driver.

Today everyone can be a programmer. You open ChatGPT, Claude, DeepSeek or Kimi, describe what you want, and an agent writes it, runs it and fixes it. That's real, and I use all of these tools every day. The car is extraordinary.

But the car isn't the driver. Some things only come from experience: knowing which question to ask, which corner is dangerous, which "it works" is lying to you. And some things come from perception: seeing the problem from a place you weren't standing.

I learned that again, recently, the uncomfortable way.

Four AI reviewers and one partner

One of my active research projects is a model training pipeline: the engine that prepares data, trains small models and measures them. I spend about eight hours a day on it. I wrote it with AI tools, and I had it reviewed by four different AI models: Kimi from Moonshot, ChatGPT, Claude Code and Codex. Each review found things; I fixed them; I re-ran everything. It worked. It reached its objective.

I've been writing code since I was 15. I'm 45 now: thirty years. I was confident this one had, for practical purposes, zero errors.

Then I gave it to my partner Pedro to test.

Pedro and I both have more than twenty years of experience, but we look at software from different places. He's extremely good at business processes: he thinks in users and flows. I think in code and possibilities. My business partner in Xari, Javier, is the same as Pedro in that sense. I like to try every technical possibility; they keep asking whether the user needs any of it, and whether it could be simpler.

Pedro found flaws in my pipeline. Not typos: problems in how it would behave in real use, things that four AI reviewers and thirty years of my own experience had walked right past. Two of them, in plain words:

  • Real input got cut off. Part of the pipeline trains models that turn speech into text. My tests used single sentences of about three and a half seconds each, and they all passed. Pedro fed it what the app actually sends: 28 seconds of someone talking continuously. The text stopped in the middle of a sentence, right before an important number, because of a hard limit on how much text the model was allowed to produce. And anything longer than 30 seconds was silently dropped. The output wasn't empty, so my "never silent" check stayed green.
  • The units weren't checked. My checks for critical numbers compared the digits, not the unit next to them. So a transcript that kept "40" but changed a micro-unit into a milli-unit, the same digits and a thousand times bigger, passed every hard check I had. And this wasn't hypothetical: in his test, a stock speech model made exactly that mistake.

Neither of these is exotic. Both are obvious the moment someone says them out loud. But my tests measured the system the way I had imagined it, and Pedro tested it the way it would actually be used.

How did that happen, if I'm supposed to be the expert?

The minority report

There's a Tom Cruise movie, Minority Report, about a police unit that arrests people for crimes they haven't committed yet, using three "precogs" who see the future. The title is a real term: in a committee or a court, the minority report is the dissenting opinion, the one written by the people who saw it differently. In the movie, sometimes one precog sees a different future than the other two, and that dissent is the clue that changes everything.

There's a related idea in law and psychology, named after Kurosawa's film Rashomon: the same event, seen by different witnesses, produces different and equally sincere stories. If someone walking next to me on the street falls, from one angle it looks like I pushed him; from another, he slipped. Neither witness is lying. Reality is what you get when you cross the points of view.

That's what happened with my pipeline. My four AI reviewers and I were, in a way, standing in the same place: we were all asking "is this code correct?" Pedro read the same code with a different question: "how will this serve a real person, on a real day?" Same code, different witness. He wrote the minority report.

The ZZZZZZ lesson, again

This isn't new for me, and that's the part that gives me hope.

In my first job, in my early twenties, I worked on Sage Accpac. The company moved its factories from the UK to China, people started entering item names in Chinese, and the reports stopped being complete: records were missing, and nobody knew why. The reports asked for "all items" with a filter from the empty string to "ZZZZZZ". In English that looks like everything. But to a computer, letters are numbers, and every Chinese character is a much bigger number than Z, so all of those items fell outside the range. Lowercase letters can fall outside it too. I wrote about it in detail in Why My Chinese Reports Skipped Records.

I'm working on tokenizers now, and it's the same lesson in a new costume: a Russian or Chinese sentence costs more tokens than the same sentence in English, because of how many bytes each character takes. Twenty years apart, the same question saved me: "what does this look like to someone who isn't me?" For the reports, it was someone typing Chinese. For the tokenizer, someone writing Russian. For my pipeline, it was Pedro.

No model gave me that question. Experience did. And when my experience wasn't enough, a person with a different experience did.

So is our experience still worth anything?

This episode made me more optimistic, not less.

Yes, you can generate billions of lines of code now. You can generate an entire application in an afternoon. But code doesn't become good because it was generated, or because it was reviewed by four models, or because it was written by someone with thirty years in the job. It becomes good when people with different experience cross their points of view on it, and someone asks the right question.

That's still true when the code is AI-generated. Maybe it's more true: when writing code is cheap, the expensive part is knowing what to ask, and noticing what's missing.

So my conclusions, for now:

  • The tools are the car. Use the best one you can get. I do.
  • Experience is the driver. It's the slow part, and it only comes with time and mistakes, including thirty-year-old mistakes about "ZZZZZZ".
  • Perspective is the team. Give your work to someone who stands somewhere else: the user, the business person, the partner who wants it simpler. Their minority report is where your bugs are.
  • Don't remove the map to feel like an explorer. Using AI isn't cheating, and refusing it isn't mastery. The difficulty that matters isn't artificial: it's the problem itself.

The one-line mental model

AI made the car available to everyone. It didn't make everyone a driver, and even good drivers crash when they only look through their own windshield.