Zanim zaczniesz kodować - lista, którą stosuję
Brzmi jak biurokracja. Zajmuje godzinę. Oszczędza tygodnie.
Krok 1: Model procesów dla MVP (15-20 min)
Zanim napiszesz jeden prompt - opisz, co ten system ma robić. Nie na poziomie kodu. Na poziomie procesów biznesowych. Co się dzieje krok po kroku? Kto jest aktorem? Jakie są wyjątki?
Ten opis staje się kontekstem dla każdego kolejnego zadania AI. Model wie, w jakim świecie pracuje.
Krok 2: Architektura i modele danych (15 min)
Jakie komponenty? Jakie technologie? Jak komunikują się ze sobą? Jakie są granice między modułami?
Nie musisz rysować diagramów UML. Wystarczy prosta lista decyzji: "używamy X, nie Y, bo Z." Ten dokument to mapa dla modelu - i dla Ciebie, gdy wrócisz do projektu za trzy tygodnie.
Krok 3: Strategia jakości (10 min)
Bezpieczeństwo - co jest wrażliwe? Testy - jakiego pokrycia oczekujesz? Dokumentacja - co musi być opisane? Dług techniczny - gdzie akceptujesz kompromisy, a gdzie nie? Migracje - jak będziesz aktualizował zależności?
To nie są pytania na etap produkcji. To są pytania na etap "zanim napiszemy pierwszy wiersz kodu."
Krok 4: Way of Working (5 min)
Jak pracuje ten projekt? Jak wygląda daily? Jak definiujemy zakończenie sprintu? Jak robimy code review? Tak - nawet jeśli programistą jesteś Ty i Anthropic Claude.
Definition of Ready dla zadania AI
Zanim przekażesz zadanie modelowi, sprawdź, czy masz odpowiedzi na trzy pytania:
"Po co?" - jaki jest cel biznesowy tego zadania? Nie "zaimplementuj endpoint", ale "ten endpoint pozwoli użytkownikowi X na zrobienie Y, co rozwiązuje problem Z."
"Jaki efekt?" - jak wygląda dobry wynik? Co musi być prawdą po zakończeniu? Jak będzie wyglądał happy path?
"Jak testujemy?" - co sprawdzimy, żeby wiedzieć, że to działa? Testy jednostkowe? Integracyjne? Manualna weryfikacja?
Te pytania są ważniejsze przy AI niż przy ludzkim programiście. Dlaczego? Bo ludzki programista pyta o niejasności. AI - jeśli nie zadasz mu tych pytań - wypełni luki własnymi założeniami. I zrobi to z pełną pewnością siebie.
Definition of Done dla zadania AI
Co oznacza, że zadanie jest skończone?
U mnie wygląda to tak:
- Testy napisane i przechodzące
- Pokrycie testami w ustalonym zakresie
- Security scan - brak znanych podatności
- Code review... i tu jest mój ulubiony element.
Code review między modelami.
Tak brzmi absurdalnie. A jednak działa. Gdy Claude pisze kod, Claude może też zrobić review tego kodu - ale jako osobna sesja, bez kontekstu poprzedniej. Inaczej: daję ten kod drugiemu modelowi i proszę o ocenę pod kątem bezpieczeństwa, czytelności i zgodności z architekturą.
Jak to wygląda w praktyce? Nowa sesja, zero historii z poprzedniej rozmowy. Prompt wygląda mniej więcej tak: "Przejrzyj poniższy kod pod kątem: 1) bezpieczeństwa - OWASP Top 10, 2) czytelności dla człowieka, 3) zgodności z tą architekturą: [opis]. Wskaż problemy i zaproponuj poprawki." To eksperymentalna praktyka - nie ma badań potwierdzających jej skuteczność w tym konkretnym zastosowaniu.
Modele się pokłócą? Czasem tak. Ale szybko dochodzą do konsensusu. I wyłapują rzeczy, których sam bym nie zobaczył.
Dokumentacja - co musi być opisane, żeby za trzy tygodnie ktoś (ja) rozumiał, co i dlaczego zostało zrobione.
Rytm pracy - dlaczego to kluczowe przy AI delivery
Przy ludzkim zespole masz retrospektywę raz na sprint. Przy AI delivery rytm musi być gęstszy.
Dzienny refaktor (30-60 min): na początku lub końcu każdego dnia roboczego - przeglądasz kod wygenerowany tego dnia. Nie przepisujesz. Pytasz: czy to jest zrozumiałe? Czy nie narasta dług? Czy coś wymaga wyjaśnienia?
Tygodniowy refaktor (2-4h): raz w tygodniu - głębszy przegląd. Analiza zależności, długu technicznego, spójności architektury z rosnącą bazą kodu.
Bez tego rytmu projekt po miesiącu wygląda jak... syf. Każde zadanie było lokalne. Nikt nie patrzył na całość.
Dodatkowe wyzwanie przy dłuższych projektach: zarządzanie kontekstem modelu. Okno kontekstowe ma swoje limity - model "zapomina" historię projektu między sesjami. Dlatego model procesów i architektura z Kroku 1 i 2 są tak ważne. To jest Twoja pamięć projektu, którą każdorazowo możesz przekazać modelowi jako kontekst.
Uczciwe zastrzeżenia
Ten model mi działał. Cztery razy. To nie jest "zawsze działa".
Czym charakteryzowały się te projekty? Małe i średnie rozmiarowo - jeden deweloper lub mała grupa. Czas trwania od kilku tygodni do kilku miesięcy. Technologie webowe i skryptowe, bez regulacyjnych wymagań bezpieczeństwa. To ważny kontekst, zanim zdecydujesz, czy ten model jest dla Ciebie.
Co go ogranicza? Większe projekty z wieloosobowymi zespołami - tu potrzebujesz więcej niż godzinnego przygotowania i daily refaktoru. Legacy systems z latami długu technicznego - tu AI będzie generować kod, który koliduje z tym, czego nie opisałeś w modelu procesów, bo sam go nie znasz w pełni. Systemy krytyczne z wymaganiami regulacyjnymi - tu strategia jakości musi być znacznie głębsza.
"Cztery razy mi działało" to nie "jedyna słuszna droga". To punkt startowy do Twojej własnej refleksji.
Cena sukcesu - paradoks, którego się nie spodziewałem
Tu muszę powiedzieć coś osobistego.
Nie jestem programistą. Od czasu do czasu zabieram się za napisanie "czegoś" - Arduino, web, własne narzędzie. Zawsze brudne, surowe, nieidealne. Ale moje.
Odkąd mam Codex i Claude Code - to się zmieniło. Opisuję co chcę, model pisze. Projekt wychodzi dobry. Naprawdę dobry. Lepszy niż cokolwiek, co napisałem sam.
I właśnie dlatego jest problem.
Przestałem pisać. Przestałem się uczyć. Straciłem hobby.
Pisanie kodu było dla mnie ćwiczeniem myślenia. Problem - hipoteza - błąd - rozwiązanie. Pętla, która uczyła. AI tę pętlę skróciło do zera. Nie muszę rozumieć problemu. Wystarczy, że go opiszę.
To jest pytanie, które wykracza poza AI delivery. Gdy narzędzie jest tak dobre, że wyautomatyzowuje nie tylko zadanie, ale też proces uczenia się, który towarzyszył robieniu tego zadania słabo - co tracisz?
Nie mam tu definitywnej odpowiedzi. Jestem coachiem, więc naturalnie skończę pytaniem.
Czy masz coś, czego AI nie może Ci zabrać - bo wartość jest właśnie w tym, że robisz to sam, nawet brudno? I czy sprawdziłeś ostatnio, czy to coś wciąż jest Twoje?
A jeśli jutro zaczynacie projekt z AI - od czego zaczynacie? Architektura, DoD... czy po prostu piszecie prompt i patrzycie co wyjdzie?