I read about an AI chat connector for Garmin data. Analyze your health data with an LLM, sounded useful. Then I read the fine print: your heart rate, sleep, and HRV land on another US company's server.
That was a no go.
So I built the thing myself. I'm a mechanical system designer with no programming background. My background is material flow and system design for automated warehouses — I define interfaces and module boundaries. The translation into Python syntax was never going to happen on my own.
That's where Claude came in. That escalated a bit.
The actual problem wasn't coding. It was context.
Claude.ai has token limits. That single constraint changed how I work.
In long chats Claude quietly begins to drift. It starts filling gaps from training data instead of from your actual project — and you don't always notice when it happens.
Same fix I'd use in any engineering project: document everything, hand over clean.
Every session starts with a START_PROMPT — a stable document that tells Claude what exists, how modules are structured, and what the rules are. When a chat gets long or the task is done, I open a new one and load the prompt again. Next chat starts from the same baseline.
NOTES track what happened inside a session — decisions taken, decisions not taken, open questions. Not for me to read later, but for the next Claude instance.
Anchors (OLD/NEW blocks) are how code changes get delivered. The old block, then the new block. Never a full file unless more than 30% changed. Forces precision on both sides.
The rule that makes all of it work: never implement without explicit instruction. Claude's failure mode is "question understood → solution built." The START_PROMPT says: assess first, explain, wait for confirmation, then build. That one rule helped more than anything else.
What got built
A local Python tool that archives Garmin Connect health data — raw intraday data, daily summaries, bulk import from GDPR export, HTML dashboards with personal baselines, weather and pollen context. Windows EXE, no Python installation required. Everything stored locally, nothing leaves the machine.
The architecture has a validator, quality assessment, encrypted token storage, a self-healing loop, five test suites, and a PyQt6 desktop app. I designed the architecture. Claude implemented it.
One thing that surprised me
Couldn't burn tokens on long messy chats, so I had to think before prompting. The architecture got cleaner because of that, not despite it. The constraint was the feature.
The major risk: working code and secure code aren't the same thing. I can't read the syntax myself and there's no reviewer. So I run the code through multiple models — Claude, Gemini, ChatGPT, others — and look for the intersection. When several flag the same issue independently, that's worth taking seriously. What comes out of that ends up in the roadmap.
The honest version: I have no way to know whether this is actually solid or just bullshit that happens to run. When I ask the AI it tells me it's impressive. That's not useful. Which is why refactoring and security review are permanent roadmap items — not failures, just the cost of building without a reviewer in the room.
GitHub: Garmin Local Archive
There's a MINDSET.md that explains how the collaboration actually worked — who had which idea, and why the architecture looks the way it does.
Top comments (0)