Od frontendu po fullstack - jak AI rozszerza możliwości frontend developera

Case Study projektu fullstack - Dog Routine Assistant

1. Prawdziwe pytanie

Czy frontend developer bez wiedzy o backendzie może samodzielnie zbudować produkcyjną aplikację fullstack i to w dwa tygodnie?

Właśnie o tym jest to case study. Dog Routine Assistant to aplikacja webowa dla właścicieli psów, zbudowana solo - od schematu bazy danych po pipeline CI/CD - przez developera, którego doświadczenie było wyłącznie w React i Next.js. Backend, migracje SQL, Row Level Security i logika powtarzających się harmonogramów - to było praktycznie nowe terytorium.

Odpowiedź brzmi: tak - ale nie dlatego, że AI pisze kod za Ciebie. Działa to dlatego, że AI, używane właściwie, staje się partnerem do myślenia - pomaga zadawać lepsze pytania, wyłapywać luki i zachowywać spójność architektoniczną przez cały projekt.

Kluczowy wniosek

Developerzy, którzy osiągają najwięcej z AI, łączą dwie kompetencje: wiedzą jak pisać precyzyjne prompty - i wiedzą jak ocenić to, co AI produkuje. Jedno bez drugiego nie wystarczy.

2. Problem wart rozwiązania

Nowi opiekunowie psów - szczególnie szczeniaków - czują się przytłoczeni. Mają dużo obowiązków do ogarnięcia: spacery, karmienie, zabawę, pielęgnację. Brakuje prostego, skoncentrowanego narzędzia do budowania i śledzenia codziennej rutyny.

Istniejące aplikacje są albo zbyt złożone (przeznaczone dla profesjonalnych trenerów), albo niedostosowane do polskiego rynku. Luka do wypełnienia: minimalistyczna, mobile-first aplikacja, która ułatwia planowanie, realizację i refleksję nad codziennym harmonogramem psa.

Użytkownik docelowy

• Nowi opiekunowie psów w Polsce
• Aktywni cyfrowo, zaznajomieni z aplikacjami
• Przytłoczeni nadmiarem obowiązków, szukający prostej struktury dnia
• Zniechęceni zbyt złożonymi narzędziami

Czego potrzebują

• Szybkie logowanie aktywności
• Szablony powtarzających się czynności
• Prosty tygodniowy raport regularności
• Jeden przejrzysty widok „dzisiaj"

3. Co zostało zbudowane

Dog Routine Assistant to pełnoprawna aplikacja fullstack. Baza danych składa się z 7 tabel i 10 migracji SQL wersjonowanych w Git.

Kluczowe funkcje

Zarządzanie rutyną

• Dashboard dzienny z procentowym postępem
• Oznaczanie: Wykonane / Pominięte / Zaplanowane
• Szablony aktywności (standard RRULE)
• Szybkie dodawanie nieplanowanych aktywności
• Profil psa z automatycznym obliczaniem wieku

Analityka

• Wykres regularności tygodnia (Pn–Nd)
• Historia aktywności z filtrami
• Widok kalendarza aktywności
• Procentowy wskaźnik regularności
• Tygodniowe podsumowanie i raport

Ekrany aplikacji

Dashboard — dzienny widok aktywności z paskiem postępu, kartą profilu psa i wykresem regularności tygodnia. Aktywności oznaczone jako wykonane wyróżnione zielonym tłem; zaplanowane widoczne poniżej z możliwością oznaczenia jednym kliknięciem.

Modal szybkiego dodawania aktywności — domyślnie ustawiony na aktualny czas i 30 minut długości. Typ aktywności wybierany z listy systemowych kategorii lub definiowany własny.

Architektura techniczna

Każdy wybór technologiczny był podjęty i udokumentowany zanim napisano pierwszą linię kodu.

Struktura projektu - dokumentacja przed kodem

Każdy większy komponent miał napisany plan zanim rozpoczęła się implementacja. Folder .ai/ w repozytorium zawiera:

.ai/prd.md              - Dokument Wymagań Produktu (przed rozpoczęciem kodowania)
.ai/tech-stack.md       - Analiza technologii i uzasadnienie wyborów
.cursor/rules/          - Plik reguł AI: konwencje projektu dla Cursora
supabase/migrations/    - Historia migracji SQL wersjonowana w Git
e2e/                    - Scenariusze testów end-to-end Playwright
src/app/api/v1/         - Route Handlers Next.js (warstwa REST API)
src/components/         - Komponenty React z shadcn/ui

Strona szablonów aktywności — 6 szablonów opartych o standard RRULE (codziennie / co tydzień) z oznaczeniem statusu „Aktywny". Każda karta pokazuje godzinę i czas trwania aktywności. Szablony automatycznie generują aktywności w dashboardzie.

Modal tworzenia nowego szablonu — dwie sekcje: podstawowe informacje (nazwa, typ aktywności, godzina, czas trwania) oraz harmonogram powtarzania oparty o standard RRULE (codziennie, co tydzień itd.) z podglądem reguły w czasie rzeczywistym.

4. Zakres i decyzje produktowe

Dobre case study jest szczere co do zakresu projektu. Nie wszystko z PRD trafiło do tego MVP - i była to świadoma decyzja produktowa, a nie niedopatrzenie.

Dlaczego to decyzja produktowa, a nie niedociągnięcie

UI planu Premium jest już zaimplementowane - użytkownik widzi co dostanie po ulepszeniu konta. Sama logika bramkowania płatności jest poza zakresem MVP. To klasyczne podejście „validate first, monetize later": najpierw udowodnij, że użytkownicy budują i przestrzegają rutyny, zanim zainwestujesz w infrastrukturę płatności. Budowanie integracji Stripe, zanim wiadomo czy użytkownicy zostają, to częsty błąd produktowy. Architektura jest już gotowa - dodanie bramki to kwestia jednego feature'a, a nie przebudowy całego systemu.

5. Gdzie kończy się AI, a zaczyna developer

Najważniejsza rzecz do zrozumienia w tym projekcie to to, czego AI nie robiło. Nie projektowało architektury. Nie definiowało czym ma być aplikacja. Nie decydowało co warto zbudować. Te decyzje były w pełni ludzkie.

Co AI robiło: dramatycznie skracało czas między „muszę zrozumieć ten koncept" a „mam działający kod, który rozumiem". To jest prawdziwa dźwignia.

Dwa podejścia - vibe coding vs. spec-driven development

Vibe Coding (co robi większość)

„Wygeneruj mi aplikację fullstack z autentykacją i dashboardem." AI produkuje kod. Developer kopiuje go. Trzy dni później coś się psuje i nikt nie wie dlaczego - bo nikt nie rozumiał co zostało zbudowane.

Spec-Driven Development (ten projekt)

Najpierw napisz PRD. Zaplanuj schemat bazy danych. Zdefiniuj API. Naszkicuj architekturę UI. Potem proś AI o pomoc w implementacji każdego fragmentu - z pełnym kontekstem, w małych krokach, z punktami kontrolnymi do przeglądu.

Cztery fazy projektu

Faza 1 - Planowanie przed kodem

Pełny PRD został napisany zanim powstał jakikolwiek kod. Zawierał user stories, KPI i zdefiniowany zakres MVP. Następnie: plan schematu bazy danych, plan API i dokument architektury UI - wszystko w folderze .ai/ repozytorium.

Rola AI tutaj: sokratejski partner do dyskusji. Zamiast „powiedz mi co budować", używane prompty brzmiały: „Zanim zaczniesz, zadaj mi 10 pytań które pomogą Ci zrozumieć mój kontekst i wymagania." To konsekwentnie ujawniało ślepe zaułki - np. obsługa stref czasowych dla powtarzających się zdarzeń - zanim stały się bugami.

Faza 2 - Backend: nowe terytorium

Migracje SQL, Row Level Security i harmonogramy oparte o RRULE - niemal wszystko kompletnie nowe. AI pomagało wyjaśnić logikę stojącą za każdą polityką RLS, nie tylko generować kod. Gdy generowany kod miał bugi stref czasowych, proces debugowania był iteracyjny i edukacyjny.

Plik MIGRATION_CONSOLIDATION.md w repozytorium dokumentuje najtrudniejszą część tej fazy: naukę, że każda zmiana schematu to nowy plik migracji, nie edycja istniejącego.

Faza 3 - Cursor Rules: danie AI pamięci projektu

Jedna z praktyk o najwyższym ROI: pisanie pliku z regułami (tutaj .cursor/rules), który daje modelowi AI stałe instrukcje dla projektu. Bez reguł każda sesja zaczyna od zera. Z regułami AI zna stack, konwencje i ograniczenia od pierwszego tokenu.

# Fragment z .cursor/rules
Zawsze preferuj Server Components, jeśli nie potrzebujesz useState ani useEffect.
Formularze: używaj react-hook-form + Zod do walidacji.
Nazwy plików: kebab-case. Komponenty: PascalCase.
Nigdy nie przechowuj project secrets po stronie klienta.

Faza 4 - Testy i CI/CD

Konfiguracja testów była zrobiona z pomocą AI. Scenariusze testowe były pisane ręcznie - bo definiowanie, co aplikacja powinna robić, wymaga rozumienia produktu, a nie tylko składni. Playwright do E2E, GitHub Actions do automatycznego deploy'u przy każdym pushu na main.

Konkretne techniki pracy z AI

1. Metoda Sokratejska - pytania przed implementacją

Zamiast od razu prosić o kod, poproś AI by najpierw zidentyfikowało luki:

Chcę zaimplementować powtarzające się harmonogramy oparte o RRULE.
Zanim zaczniesz, zadaj mi 10 pytań które pomogą Ci zrozumieć mój kontekst, edge cases i wymagania.

Połowa tych pytań konsekwentnie ujawniała coś, co stałoby się bugiem lub znaczącym refaktoringiem.
Koszt: kilka minut. Zysk: godziny debugowania.

2. Workflow 3x3 - kontrolowane iteracje

<implementation_approach>
  Zaimplementuj maksymalnie 3 kroki. Podsumuj, co zostało zrobione.
  Opisz plan na kolejne 3 kroki.
  Zatrzymaj się i czekaj na mój feedback, zanim będziesz kontynuował.
</implementation_approach>

3. Protokół resetu - gdy sesja się blokuje

Zatrzymaj się. Daj mi obiektywne podsumowanie tej konwersacji:
- Co działa i powinno zostać zachowane
- Gdzie nasze podejście zawiodło i dlaczego
- Czego się nauczyliśmy
- Czysty opis problemu do nowej konwersacji

Zasada trzech prób: Jeśli trzecia poprawka wprowadza nowy problem, zresetuj konwersację. Kontynuowanie takiej sesji to pułapka - trwasz przy niej, bo już dużo czasu włożyłeś, a nie dlatego, że zmierzasz w dobrym kierunku.

4. Tagi XML - struktura w złożonych promptach

<project_context>
  Stack: Next.js 15, Supabase, TypeScript; Etap: implementacja API
</project_context>
<task>Zaimplementuj endpoint create-activity z walidacją Zod</task>
<constraints>
  Użyj istniejących typów z src/types.ts
  Nie modyfikuj schematu bazy danych
</constraints>

6. Wyniki

Baza danych: 7 tabel, 10 migracji SQL wersjonowanych w Git. Testy E2E: 8 scenariuszy krytycznych (auth, dashboard, aktywności, historia, szablony, onboarding, ustawienia, odzyskiwanie hasła) w architekturze Page Object Model - 26 page objects zapewniających czytelność i reużywalność testów.

Techniczne

• Działająca aplikacja produkcyjna (Vercel)
• Pełna autentykacja (Supabase Auth + JWT)
• Row Level Security na wszystkich tabelach
• Playwright E2E - 8 scenariuszy, 26 page objects
• Pipeline CI/CD - GitHub Actions
• Audyty dostępności axe-core
• 10 migracji SQL wersjonowanych w Git
• Dokumentacja: PRD, plan DB, plan API, plan UI

Produktowe

• Dashboard z procentowym postępem dnia
• Szablony aktywności oparte o RRULE
• Historia aktywności + widok kalendarza
• Wykres regularności tygodnia (Pn–Nd)
• Profil psa z automatycznym obliczaniem wieku
• Procentowy wskaźnik regularności
• Publiczna strona landing page
• W pełni responsywny interfejs (mobile-first)

Ustawienia — zakładka profilu psa z edytowalnymi polami (imię, rasa, data urodzenia, waga, zdjęcie pupila) i przyciskiem zapisu zmian. Cztery zakładki: Profil psa, Konto, Prywatność, Plan.

7. Wyzwania i jak zostały rozwiązane

Historia aktywności — widok listy z filtrami po statusie i typie aktywności. Aktywne filtry widoczne jako tagi z możliwością szybkiego wyczyszczenia. Trzy zakładki widoku: Lista, Kalendarz, Raport.

Najtrudniejszy moment

Najtrudniejszym momentem nie był żaden konkretny bug - było pierwsze zderzenie z logiką migracji baz danych. Jako frontend developer byłam przyzwyczajona do tego, że można edytować plik i zapisać zmiany. W SQL każda zmiana schematu to nowy plik migracji, wersjonowany w Git, nieodwracalny na produkcji. Kiedy po raz pierwszy lokalnie zresetowałam bazę i straciłam mnóstwo czasu pracy - zrozumiałam, dlaczego backend developerzy mówią o „dyscyplinie migracji". AI pomogło mi to zrozumieć, ale lekcji nie dało się ominąć. Trzeba było ją po prostu odbyć.

Najważniejsza zmiana nastawienia

Gdy AI produkuje błędny kod, instynkt podpowiada by winić model. Bardziej produktywne podejście: prompt był niekompletny albo problem był zbyt duży na jedną sesję. Zmiana pytania z „dlaczego AI się myli?" na „jakiego kontekstu brakowało?" dramatycznie poprawia efektywność pracy.

8. Lessons Learned

Co działało lepiej niż oczekiwano?

• Supabase drastycznie obniżył barierę wejścia do backendu. Bez niego projekt trwałby 3× dłużej.
• Cursor Rules działają jak pamięć projektu - AI zachowuje decyzje architektoniczne między sesjami.
• Planowanie przed kodowaniem: pisanie PRD i planu DB przed implementacją zmniejszyło refaktoryzację o co najmniej 50%.
• TypeScript + AI: typy dają AI kontekst; AI pomaga utrzymywać i rozszerzać typy spójnie.
• axe-core + Playwright: testowanie dostępności za darmo - automatyczne audyty bez żadnego dodatkowego wysiłku.

Co zrobiłabym inaczej?

• Więcej testów jednostkowych wcześniej - zwłaszcza dla logiki RRULE.
• Atomic commits od pierwszego dnia - małe, częste, opisowe.
• Szybsze resety konwersacji. Za dużo czasu na próbach ratowania zablokowanych sesji z AI.
• Dokumenty ADR (Architecture Decision Records) od pierwszego dnia, nie wstecznie.

9. AI-Powered Frontend Engineer

Kiedy zaczynałam ten projekt, szczerze nie byłam pewna, czy sobie ze wszystkim poradzę. Backend był dla mnie trochę czarną skrzynką - RLS, migracje SQL, harmonogramy RRULE. Wiedziałam, że AI może pomóc, ale nie wiedziałam, czy to wystarczy.

Dwa tygodnie później miałam działającą aplikację produkcyjną. Nie dlatego, że AI napisało ją za mnie - ale dlatego, że nauczyłam się zadawać mu właściwe pytania, oceniać to, co produkuje, i wiedzieć, kiedy zacząć od nowa.

Efektywna praca z AI to kompetencja, którą można systematycznie budować - i którą chcę dalej rozwijać. Widzę w tym realną przewagę, która dziś jest wyróżnikiem, a za kilka lat stanie się oczekiwaniem. Chcę być wśród tych, którzy budują tę kompetencję teraz - i pomagają innym zespołom robić to samo.