Od surowych danych do porywającej historii: tak zmieniłem swoje treningi z AI

Fitness tracking, który wreszcie rozumie kontekst

Fitness aplikacje świetnie liczą. Kiepsko opowiadają historie.

Mój Samsung Fit 3 wie, że w zeszłym miesiącu przebiegłem 180 kilometrów. Nie wie, że przygotowywałem się do pierwszego półmaratonu. Nie wie, że te biegi były częścią zaplanowanego cyklu treningowego, którysfotografowałem z tablicy w siłowni.

Ta luka między danymi a kontekstem zainspirowała mały projekt poboczny. I pokazał mi, dlaczego AI coding agents zmieniają zasady gry w personalnej automatyzacji.

Problem z metrykami

Używam Strava do biegania i Samsung Fit 3 do treningów siłowych. Konfiguracja działa elegancko — tracker automatycznie synchronizuje się z aplikacją, dając mi standardowe metadane: czas, dystans, tętno, strefy.

Ale Strava nigdy nie powie mi, czy dana sesja "treningu siłowego" to dzień mocy z przysiadami, czy dzień regeneracyjny z ćwiczeniami mobilności. Aplikacja wie, że coś robiłem przez 45 minut. Nie ma pojęcia, że pracowałem nad progresją goblet squat z obciążeniem 24 kg.

Prawdziwy kontekst żył wyłącznie w zdjęciach, które wrzucałem do postów na Strava. Tablica w siłowni dokumentowała faktyczną strukturę treningu — ćwiczenia, serie, powtórzenia, rozróżnienie między dniami regeneracyjnymi a intensywnymi blokami.

Strava chwytała ilość. Zdjęcia opowiadały jakość.

Pipeline, który łączy światy

Rozwiązanie nie było jednym narzędziem — była to pipeline, która pozwalała różnym systemom robić to, co robią najlepiej:

Pobierz → Przetwórz → Wyciągnij → Zwizualizuj

Zaczęło się od prostego skryptu Pythona, który ściągał wszystkie aktywności ze Strava wraz z załączonymi zdjęciami. Skrypt utrzymywał lokalną pamięć podręczną, więc pomijał już pobrane media i wznawiał się po przerwach.

Najciekawsza część? Wyciąganie kontekstu treningowego ze zdjęć tablicy.

Użyłem Claude Code jako coding agenta z możliwościami vision. Dla każdego zdjęcia tablicy trenerskiej agent generował ustrukturyzowany opis treningu w formacie JSON:

{
  "type": "workout",
  "exercises": [
    {
      "name": "Romanian deadlift",
      "sets": 4,
      "reps": "8-10",
      "weight": "60kg",
      "muscle_groups": ["posterior chain", "glutes"]
    }
  ],
  "focus": "strength",
  "notes": "Felt strong today, increased weight from last week"
}

Podejście z agentem w pętli sprawdziło się znakomicie. Jeśli wynik wyglądał źle, po prostu usuwałem plik JSON i generowałem od nowa. Jeśli obraz był już przetworzony, skrypt go pomijał. Workflow był wznawialny, naprawialny i — co najważniejsze — iteracyjny.

Kiedy miałem już ustrukturyzowane dane treningowe połączone z metrykami ze Strava, renderowanie finalnej infografiki było proste. Prosty szablon HTML łączył wszystko w shareable PNG.

Klasyfikacja okazała się prostsza, niż myślałem

Tagi aktywności na Strava nie były spójne. Niektóre sesje siłowe oznaczałem "weight training", inne po prostu "workout". Dni mobilności czasem pojawiały się jako generyczne aktywności. Ten chaos był w pełni moją winą — trzy lata luźnego tagowania bez żadnego standardu.

Zamiast budować wyrafinowany model klasyfikacyjny (co byłoby przerostem formy nad treścią dla projektu osobistego), użyłem pragmatycznego podejścia: połączyłem typ aktywności ze Strava, słowa kluczowe z tytułu i dane z fotek, żeby zgadywać klasyfikację.

Logika wyglądała tak:

• Słowa jak "squat", "deadlift", "bench" + fotki siłowe = trening siłowy
• "Mobility", "stretch", "recovery" + fotki z ćwiczeniami rozciągającymi = sesja mobilności
• Dystans + czas + brak fotki z siłowni = bieganie (metadane Strava są tu wiarygodne)

Ta hybrydowa klasyfikacja była wystarczająco dobra dla osobistego podsumowania. Finalny poster czuł się dokładny, bo wykorzystywał to, co każde źródło danych robiło najlepiej.

Rozważania o MCP

Przetestowałem chwilę Strava MCP server, który obiecywał uproszczenie integracji z API. Sprawdził się świetnie do pobierania metadanych aktywności, ale nie potrafił pobierać zdjęć załączonych do aktywności. Dla projektów wymagających tylko liczb, MCP znacząco uprościłby development. Dla tego przypadku, gdzie dostęp do zdjęć był must-have, pozostałem przy ręcznym skrypcie.

Co to mówi o AI coding agents

Prawdziwa wartość tego projektu nie była w samej infografice — była w pokazaniu, jak AI agenci mogą służyć jako elastyczne middleware między źródłami danych a pożądanymi outputami.

Tradycyjne narzędzia automatyzacji działają sztywno: jeśli A, to B. Coding agenci potrafią reasonować między modalnościami. Mogą spojrzeć na obrazek, zrozumieć kontekst i wygenerować ustrukturyzowane dane. Potrafią adaptować się, kiedy pojawiają się edge cases. Potrafią pomóc ci zbudować automatyzację, a nie tylko wykonywać się w jej ramach.

Dla developerów i technicznych przedsiębiorców to fundamentalna zmiana. Pytanie nie brzmi już "Czy mogę to zautomatyzować?", ale "Jak szybko mogę iterować nad automatyzacją?". Projekt, który kiedyś zająłby cały weekend, teraz można prototypować w jeden wieczór — agent zajmuje się boilerplate'em i pomaga myśleć przez edge cases.

Konkluzja

Efekt końcowy to shareable podsumowanie treningowe, которое wreszcie opowiadało historię mojej fitness podróży. Ale proces wskazuje na coś większego: erę personal data empowerment.

Twoje dane fitness, projekty kodowe, metryki biznesowe — większość leży w rozdrobnionych systemach, które ze sobą nie rozmawiają. AI coding agenci stają się tkanką łączną, która pozwala budować customowe widoki własnych informacji bez zasobów na skalę enterprise.

Następnym razem sprawdzę, jak sprawdzi się local model — wszystko na urządzeniu, bez wysyłania danych do chmury. Jeśli eksperymentujesz z podobnymi projektami personalnej automatyzacji albo masz własne fitness-agent workflows, chętnie posłucham.

Czasem najbardziej satysfakcjonujące projekty nie są te, które się skalują — są to te, które wreszcie pozwalają twoim własnym danym opowiedzieć twoją własną historię.