Stride

Problemet

Jeg ville have en coach til mit eget løb, ikke endnu et panel med de samme tal som Strava. Kravet var enkelt: en anbefaling skal kunne forklares. Siger den "rolig tur", skal den kunne vise hvilke data der pegede den vej.

Begrænsninger

• Data bliver i Strava

  Stride henter aktiviteter via Strava-API'et. Stravas vilkår forbyder at dele data med AI-udbydere, så løbeturene må ikke ende i et kontekstvindue hos en model. Det er en begrænsning der former arkitekturen, ikke en detalje.

• Rådene skal kunne gentages

  Samme data ind skal give samme råd ud. Derfor beregnes anbefalingerne af en regelmotor, ikke af en model. Det gør dem forklarlige, testbare og sammenlignelige over tid.

• Én bruger: mig

  Jeg tester på min egen telefon og mit eget træningsforløb. Hver ændring bliver vurderet mod et rigtigt løb, ikke mod demodata.

Beslutninger

• Regler frem for prompts

  Belastning, restitution og træningstype er regler med navn og rækkefølge. Når rådet er forkert, kan jeg pege på den regel der er forkert — i stedet for at gætte på om prompten var dårligt formuleret.

• Readiness som glidende gennemsnit

  Parathed beregnes som et vægtet, glidende gennemsnit frem for et dagsbillede. En enkelt hård tur skal kunne mærkes uden at vælte tallet, og en langsom omstilling skal kunne ses.

• Anbefalinger som komponenter

  Råd leveres som typede blokke der renderes som rigtige React-komponenter — kort, grafer og indsigter — i stedet for en tekstblob. Så kan et råd indeholde en graf uden at nogen skal klippe og lime tekst.

Stack

• Next.js 16
• TypeScript
• Drizzle ORM
• Neon Postgres
• Recharts
• Strava API

Hvad jeg tog med mig

At bygge mod en regelmotor tvinger beslutningerne frem: hver regel skal kunne forsvares, og hver undtagelse skal skrives ned. Det er mere arbejde end at kalde en model, og det er derfor rådene kan forklares.