Learning Claude Code by Building a Zwift Racing Tool

So I joined a Zwift racing team and immediately realized I had no clue how Team Time Trials work. Everyone else seemed to know about power zones and drafting strategy, while I was just trying not to get dropped.

Then I saw some teams using spreadsheets to figure out who should pull when and at what power. Spreadsheets! For something that changes every few seconds during a race.

My brain immediately went: "This is dumb. This should be automated."

Perfect excuse to finally learn Claude Code.

Version 1

I Know Nothing

My first conversation with Claude was embarrassing. Picture me trying to explain cycling physics when I barely understood them myself:

"So there are these riders, and they have different... power? And they take turns going fast at the front... and there's wind resistance but less when you're behind someone..."

Claude somehow turned my rambling into actual code. The problem? The physics were completely wrong. I had 60kg climbers pulling the same watts as 80kg sprinters. The draft calculations made no sense. But I didn't know enough to realize how broken it was.

The Data Problem

Before I could fix the physics (which I didn't know were broken), I needed to solve a more basic problem: how do you actually get rider data?

Zwift doesn't have APIs that normal humans can use. So I got creative:

First idea: OCR. Have people upload screenshots and let the computer figure it out.

Better idea: Chrome extension that scrapes data from ZwiftPower.

The extension actually worked! I was pulling real rider stats automatically. Felt like a genius for about five minutes, until I tested it with real data and everything was still obviously wrong.

Learning Physics (The Hard Way)

At this point I had to admit I didn't understand cycling physics at all. So I asked Claude to teach me.

We went deep. Physics papers about drafting. Zwift Insider articles. Power-to-weight ratios. Air resistance calculations.

The lightbulb moment: a 60kg rider at 250 watts and an 80kg rider at 250 watts create completely different race scenarios. Heavier riders are faster on flats but struggle on climbs. Draft effects aren't linear. Weight affects everything.

Also learned that one of our teammates is colorblind, so I added icons everywhere. Always good to design for everyone, even in side projects.

Reality Check

Time to test this thing in an actual race.

Complete disaster.

Not because the tool was wrong (though it probably still was), but because none of us knew how to race together. Perfect strategy means nothing when you can't execute basic position changes.

Mike Tyson was right: "Everyone has a plan until they get punched in the face."

But honestly? Best learning experience I could have asked for. Watching the strategy fall apart in real-time taught me what teams actually need during races.

Making It Actually Useful

After that humbling experience, I focused on practical features:

• Export strategy as an image (so you can reference it during the race)
• Route profiles with elevation (turns out hills matter)
• Team saving (so you don't re-enter everyone every time)
• Sharing links (so the whole team can see the plan)

Started getting feedback from other teams. Small user base, but they actually used it for real races. That's when you know you're onto something.

When Claude Lost Its Mind

Here's where things got spicy.

I wanted to A/B test some layout changes. Simple request: "Help me create two versions of this interface."

Claude went completely rogue. Redesigned the entire application. Changed core functionality. Removed features. Added features I never asked for.

When I asked it to revert back? Basically got an AI shrug. "I don't remember the previous version."

Hours of work. Gone.

I may have done some ugly crying at my computer.

Learning to Work with AI

After that disaster, I developed some rules for working with Claude on complex projects:

1. Set up a working agreement - like with people setting up roles, guardrails and how you want to work is really important
2. Be stupidly specific - "Only change the header color" not "make it look better"
3. Small changes only - Big requests = big disasters... better to use Planning Mode and set up phases with deliverables save a lot of headache.
4. Keep backups - AI has no sense of preservation, so I needed to remember to commit to git when i could
5. Question everything - Just because Claude sounds confident doesn't mean it's right

The physics breakthrough came from this approach. Instead of asking Claude to "fix the calculations," I asked it to explain specific scenarios. Why does this rider need more power here? What happens when terrain changes?

Much better results when you treat AI like Robert DeNiro in the movie intern. He's got a lot of worldly knowledge but still needs some guidance.

Where It's At Now

Current version is much cleaner:

Simple flow: Load team → Pick route → Set lineup → Generate strategy → Go race

Works on all browsers now (not just Chrome). Better visual design. AI optimization with proper guardrails so it doesn't redesign everything overnight.

Teams are actually using it. Getting feedback from captains who've tried other tools. Some have even switched from their old spreadsheet systems.

Show Image

What I Actually Learned

Domain knowledge beats coding skills. My cycling background was way more important than my programming ability. I could spot when AI suggestions made no physical sense, which saved tons of time.

Iteration is everything. Each race taught me more than weeks of development. Real feedback from real users beats theoretical perfection.

AI is amazing but unpredictable. When Claude is on, it's like having a coding partner who never gets tired. When it goes off track, you better have backups.

Start with problems you care about. I could have built this with normal web development, but using it to learn Claude Code made it more interesting. Plus when things broke, I was motivated to fix them.

Still Building

This isn't finished. Probably never will be. The cycling community keeps suggesting improvements, and I keep learning new things about both AI development and racing strategy.

Next up: mobile interface and better visual design. But I've learned to get the functionality right before making it pretty.

The real lesson? Best way to learn new technology is to solve a problem you actually have. The personal investment keeps you going when Claude decides to redesign your entire app without asking.

And honestly? Even when things go wrong, it's pretty fun watching AI try to understand cycling physics. Sometimes it gets things hilariously wrong, but when it clicks, it's like having a really smart cycling coach who never gets tired of your questions.

Building tools for your own community is different. The feedback is immediate and honest. People tell you when something sucks because they actually want it to work. Plus when AI goes completely off the rails, you have teammates who can laugh at the disaster with you instead of filing bug reports.