Ideas gathering dust
I’ve had side projects that never see the light of day for years.
Ideas scribbled down somewhere. GitHub repos created on a Sunday evening, abandoned by Monday. No time, no energy, not all the skills either — let’s be honest. Life goes by, work, kids, and the ideas stay ideas.
This one had been sitting around for a while: something to analyze my running sessions. Something personal — a coach, data, lots of data.
RunSloth
Yes, it’s a sloth. That runs.
And for a sloth, it does quite a lot. It syncs with Strava, analyzes my performance, builds training plans, and gives me feedback on every run.
That’s the dashboard. The app also connects via an MCP server to an LLM (Claude, in my case). After a run, I just say: “Hey coach, I did my run today, can you sync? How I felt: pretty good despite a faster pace than planned.”
And the magic happens. It syncs. Analyzes my splits. Compares to what was planned. Gives me feedback…
Then it links the activity to the plan and projects ahead to the next session.
What’s actually great about it
The real pleasure isn’t that it does more than another app — that’s not even the point.
No, it’s that it’s my thing.
Let me paint a picture. I often go on runs that aren’t in the plan. Say it’s a Sunday in spring. Beautiful weather. The sun’s calling. I hop on my bike and ride around Lake Annecy. Unplanned. Not in the schedule.
All I have to do is say: “That wasn’t planned, but I did this. Can you adjust the plan accordingly?”
It adjusts.
If tomorrow I want the tool to suggest seasonal recipes for the night before a race, I can. If I want to change the way it analyzes my runs, I can. It’s my tool — I shape it however I want.
And most importantly, I’m learning. With every feature I add, I understand better how to interact with AI — the skills, the limits, the workarounds. It’s a playground.
Zero lines of code
I didn’t write a single line.
Not one. Zero.
The project runs an MCP server, a PostgreSQL database, a REST API, a Vue.js dashboard with advanced fitness charts, a training plan calendar… And I didn’t code any of it.
I specified. Iterated. Steered. Corrected.
How it works
A typical session looks like this:
I fire up Claude Code. I describe what I want — broadly, not in technical detail. We brainstorm together for about ten minutes. The structure, the edge cases, the architecture decisions.
Then it goes off and codes.
15 minutes. Sometimes 20. I do something else. I check in now and then to see if it’s done.
Once it’s finished, I test. I give feedback. “It breaks when I do this,” “The drawer doesn’t close,” “The pace is in min/km, not km/h for cycling.” It fixes. Next issue.
A big feature takes me 1 to 1.5 hours with all the back and forth. Sometimes I hit the token limit — Claude Pro — so forced 5-hour breaks. I pick up again next session.
The skills
I set up skills for the first time while building this project.
- brainstorming helped me structure the project from the start.
- mcp-builder saved me from banging my head against the wall like the last time I tried building an MCP server.
- subagent-driven-development lets you tackle big features as a team. Sub-agents working on independent tasks in parallel.
- And frontend-design… The entire UI came out right on the first try. I gave it the name, the vibe. And boom 🪄
It gives you enhanced capabilities, on a specific project or across all of them. You use them as needed.
It’s precision tooling.
The CLAUDE.md file
This is the heart of it.
A markdown file at the project root. It’s ground zero for context. Architecture, features, conventions. When Claude picks the project back up after a break, this is where it starts.
Keeping it up to date, organizing it, splitting it into multiple files by feature area — that’s my responsibility. It’s a bit like writing documentation, but for an AI.
It’s the memory.
The coach prompt
The final piece of the puzzle is the prompt that turns the LLM into a running coach.
A markdown file with the rules: the training methodology (Jack Daniels in my case), the recommended workflows (how to analyze a session, how to do a weekly check-in…), the available MCP tools (fetch activities, create a plan…) and when to use them.
That’s what makes it so that when I say “Hey coach,” it doesn’t respond like a generic assistant. It knows it needs to look at my target paces, compare against my heart rate, put things in the context of my training week.
It’s the personality.
Do I feel like a developer?
Yes and no.
I can tell that in some cases, if I don’t step in, if I don’t steer the bug hunt, the AI could spin in circles. Looking in the wrong place. Adding useless stuff in every direction.
And at the same time, it goes so fast. It does things almost certainly better than I would. You can’t help but feel a bit blown away by it.
But deep down, what I did on this project is what I’ve always preferred doing: thinking about the problems to solve. Not implementing them — thinking them through.
The real pleasure
No single “wow” moment. Just a string of cool things.
At first, I just wanted to sync my Strava activities and send them to an LLM. Then since that went fast, I added the MCP server so I wouldn’t have to export. Then since that went fast, I added plan management directly. Then the dashboard. Then fitness stats. Then…
The loop is so fast you just ride the wave. You planned a JSON export, you end up with a full product.
And above all, ABOVE ALL, I finished a side project.
For once.
I’ve had ideas rotting away for years. Here, in one week, I have something that works. That I actually use.
It sounds silly, but: it feels good to let yourself have fun.
I had a blast. It’s incredibly thrilling.
And now, I need to go for a run. Because that part, the AI can’t do for me 👟