I Spent a Weekend Building What Tesla Won’t Tell Us
AI is reshaping what projects are worth doing
Is Tesla’s Robotaxi safer than a human driver?
This should be a straightforward data question. But when I searched Google, nothing. Tesla’s website? Nothing. NHTSA reports? Scattered numbers that don’t connect to anything. News coverage? One day it’s “Robotaxi violated traffic laws,” the next it’s “NHTSA investigating,” then “Tesla filed confidential documents.”
Nobody was tracking this in a way that actually answered my question.
So I built the answer myself. In about four hours.
If this were 2023, here’s what would have happened: I’d evaluate whether it was even feasible. Then I’d spend weeks learning Python, web scraping, frontend development, and deployment automation. Then months actually building the thing. Then ongoing headaches maintaining it when websites change or bugs appear.
Conservative estimate? Six to twelve months of work. If I outsourced it, 10 to 12 thousand dollars.
But this is 2026.
What I actually did was open Claude Code, describe what I wanted, run the code it generated, fix the problems that came up, and push it live. The whole thing took a weekend afternoon plus a few evening tweaks.
The result: Tesla Robotaxi Safety Tracker
It shows the current miles per incident (107,500), the fleet size (232 vehicles), how fast safety is improving (doubling every 69 days), and how far we are from matching human driving benchmarks.
This project taught me something I hadn’t fully grasped before: AI isn’t just for answering questions. It’s for building things.
The Shareholder’s Question
June 22, 2025 was a day I’d been waiting for. After years of promises, Tesla’s Robotaxi finally hit the road.
The excitement lasted about a day before the obvious question surfaced: Is this thing actually safer than me driving?
I went to Tesla’s website looking for safety statistics. Nothing useful. I dug through NHTSA’s site and found fragments—”fleet traveled 250,000 miles,” “8 collisions reported,” “average of one collision per 40,000 miles.” Okay, but is that number getting better or worse? How does it stack up against regular human drivers? When will it cross the threshold where I can confidently say it’s safer than me?
No one had these answers organized anywhere. As a shareholder trying to understand whether this technology was actually working, I needed a tracker that would pull the data automatically, calculate the key metric, compare it to human driving, and show me the trend over time.
I searched for an hour. Nobody had built this.
Fine. I’ll do it myself.
The First Hour: Figuring Out What I Actually Wanted
I opened Claude Code and started describing the project:
I want a website that tracks Tesla Robotaxi safety. Accident data comes from NHTSA reports—Tesla has to file these whenever their autonomous system is involved in a collision. Fleet size comes from robotaxitracker.com, a community-run site where Tesla enthusiasts across the US log Robotaxi sightings with license plates, cities, and dates.
The core metric is miles per incident: total miles driven divided by total accidents. I estimate total miles by multiplying fleet size by 115 miles per day (an industry estimate for robotaxi usage) by the number of days since launch.
For comparison, human drivers average about 300,000 miles between insurance claims and 500,000 miles between police-reported accidents. The website should show where Robotaxi currently stands, display the trend on a logarithmic scale (since we’re tracking exponential improvement), and update automatically every day.
Tech-wise, I wanted web scrapers to pull the data, a simple HTML/CSS/JavaScript frontend, and free hosting on GitHub Pages.
Claude generated the project structure, the scraper code, the analysis scripts, the frontend, and the automation configuration. All in maybe twenty minutes.
The Second Hour: Everything Breaks
Running the code is when reality sets in.
First problem: the scraper returned blank data. I figured out with Claude together that robotaxitracker.com uses lazy loading—the charts don’t render until you scroll down to them. Standard web performance optimization, but a nightmare for scrapers. Claude rewrote the code to simulate scrolling and wait for the charts to actually appear before grabbing the data.
Second problem: the chart values wouldn’t extract. The site uses Recharts, and you have to hover your mouse over each data point to see the number. Claude’s initial approach—simulating mouse movement—didn’t trigger anything. The tooltip just sat there saying “Hover to see data.” I told Claude to try a different approach: trigger the display logic directly through JavaScript rather than faking mouse events. That worked.
Third problem: dates kept parsing wrong. The GitHub Actions runner that executes the daily updates doesn’t have consistent locale settings. Sometimes dates came through in English, sometimes as numbers, sometimes in formats I’d never seen. Months were getting scrambled. I told Claude to make the date parser recognize everything—CJK formats, Korean, European style, ISO standard, English. Overkill? Maybe. But it solved the problem permanently.
Hours Three and Four: Making It Actually Good
With the core working, I started adding the features that would make this genuinely useful rather than just functional.
I added a “current streak” indicator showing how many miles had been driven since the last incident, with a progress bar tracking toward the 300,000-mile human benchmark. I swapped the bar chart for a line chart with shaded fill underneath—easier to read the trend. I put the y-axis on a log scale so the exponential improvement shows up as a clean straight line instead of a hockey stick. I added a little celebration animation for when the tracker crosses major milestones. And I built in light/dark theme support that follows your system settings.
Publishing was the easy part. Push to GitHub, enable Pages, configure the automation to run daily at 2pm Beijing time. Done.
What the Data Actually Shows
On launch day—June 22, 2025—the fleet had 20 vehicles, roughly 50,000 cumulative miles, and 8 reported incidents. That works out to about 31,250 miles per incident.
Today, January 26, 2026, there are 232 vehicles (68 in Austin running fully autonomous, 164 in the Bay Area with safety drivers). Cumulative miles are around 1,075,000. Incidents have only increased to 10. Miles per incident: 107,500.
The improvement rate works out to a doubling every 69 days.
To match human driving at the insurance-claim level (300,000 miles per incident), Robotaxi still needs to improve by a factor of 2.8. To match the police-report standard (500,000 miles), it needs a 4.7x improvement.
If the current trajectory holds, it should cross the insurance threshold around May 2026 and the police-report threshold around July 2026.
Caveats matter here. This is still a tiny sample—232 vehicles, 10 incidents. The incident data only covers Austin’s Level 4 vehicles; the Bay Area cars with safety drivers aren’t included. And the 115 miles per day estimate could be off. But directionally, the trend is clear and positive.
The Part That Actually Matters
Here’s what changed for me through this project.
The old workflow went like this: Have an idea. Evaluate whether it’s feasible. Learn all the skills you’d need. Build the thing. Test it. Launch it. Most ideas died at step two, because “evaluating feasibility” really meant “calculating how many months of learning this would require” and the answer was usually “too many.”
The new workflow is different: Have an idea. Describe it to an AI. Get a prototype. Test it. Refine it. Launch it. Most ideas can be validated in a week or two.
The key shifts are that startup costs collapsed (you don’t need to master everything first), validation speed increased dramatically (you see if something works before investing months), and iteration became fast (adding features takes hours, not weeks).
This changes which projects are worth attempting. The old calculus required large audiences, mature technology with existing examples to copy, and substantial resources. The new calculus just asks: Do you need this yourself? Can you describe what you want clearly? Are you willing to spend a weekend finding out?
A lot of projects that seemed “not worth the effort” before are now completely reasonable. A Robotaxi safety tracker for a few thousands Tesla shareholders. A personal data visualization tool that only you’ll ever use. A niche community tool for a few hundred people who share some obscure interest.
None of these will make money. The audiences are tiny. But they solve real problems for real people. And now they’re possible to build in a weekend instead of impossible to justify.
If You Want to Try This
Find your own “tracker” project. Something where you genuinely want to see data organized that nobody’s organizing. Something where the information is public but scattered. Something that doesn’t require sophisticated algorithms—just consistent collection and display.
Track a stock metric that matters to you. Track trends in an industry you follow. Track your own fitness or reading or coding time in a way the existing apps don’t support.
Start by spending an hour defining exactly what you want: What data? Where does it live? What do you want to see? Then spend a day describing it to an AI in detail and running what it generates. Then spend a week or two iterating—fixing what breaks, adding what’s missing, refining what’s ugly.
Your first version won’t be perfect. The functionality will be rough. The UI will be basic. You might be the only person who ever uses it.
But you’ll have solved your own problem. You’ll have learned how to collaborate with AI on building things. And you’ll have crossed from being someone who consumes tools to someone who creates them.
That shift matters more than any individual project.
Don’t ask “has someone already built this?”
Ask “can I build this myself?”
The answer, increasingly, is yes.
Project Links:
Website: robotaxi-safety-tracker.com
GitHub: github.com/kangning-huang/tesla_robotaxi_mile_per_incident_tracker