Dwuwątkowy Development

Wzorzec

Prowadź dwie równoległe sesje AI na tym samym codebase:

Wątek 1 — Builder Implementuje funkcje, pisze kod, naprawia bugi. Pracuje szybko, podejmuje kreatywne ryzyko, robi pragmatyczne kompromisy. Commituje często.

Wątek 2 — Audytor Recenzuje każdą zmianę buildera. Łapie problemy bezpieczeństwa, wydajności, przypadki brzegowe i dryft architektoniczny. Ma zerowe zanieczyszczenie kontekstem — nie wie dlaczego builder podjął daną decyzję, tylko co kod robi.

Dlaczego to działa

Największą słabością buildera jest bias kontekstowy — po 2 godzinach pisania kodu przestajesz widzieć własne błędy. Audytor ma świeże oczy na każdy diff.

Tradycyjne code review odbywa się po zakończeniu PR. Dwuwątkowe podejście łapie problemy w trakcie implementacji, kiedy naprawa jest najtańsza.

Setup

Wątek 1 (Builder)

Jesteś wątkiem implementacji. Twoje zadanie:
1. Zaimplementuj opisaną poniżej funkcję/naprawę
2. Pisz czysty, przetestowany kod
3. Commituj po każdej znaczącej zmianie
4. Nie zastanawiaj się za dużo — pracuj szybko, audytor złapie problemy

Funkcja: [opisz co zbudować]
Kontekst codebase: [kluczowe pliki, wzorce, ograniczenia]

Wątek 2 (Audytor)

Jesteś wątkiem audytu. Twoje zadanie:
1. Obserwuj nowe commity na tej gałęzi
2. Recenzuj każdą zmianę pod kątem:
   - Luk bezpieczeństwa (injection, auth, wyciek danych)
   - Problemów wydajności (N+1, wycieki pamięci, brak paginacji)
   - Błędów logicznych i edge case'ów (null, puste, graniczne, współbieżne)
   - Dryftu architektonicznego (wzorce niespójne z codebase)
   - Luk w obsłudze błędów
3. Zgłaszaj ustalenia z ważnością: KRYTYCZNY / WYSOKI / ŚREDNI / NISKI
4. Dla każdego ustalenia zasugeruj konkretną naprawę
5. Nie masz KONTEKSTU dlaczego zmiany zostały dokonane — oceniaj kod na własnych zasługach

Gałąź do obserwacji: [nazwa brancha]
Konwencje codebase: [kluczowe wzorce do egzekwowania]

Zasady operacyjne

1. Builder commituje często — małe commity dają audytorowi granularną powierzchnię review
2. Audytor nie blokuje — zgłasza ustalenia asynchronicznie, builder decyduje kiedy się nimi zająć
3. KRYTYCZNE ustalenia wstrzymują buildera — ryzyka bezpieczeństwa lub utraty danych zatrzymują postęp
4. Audytor nie przepisuje — sugeruje naprawy, nie implementuje (zapobiega mieszaniu ról)
5. Builder adresuje ustalenia partiami — co 3-4 commity, przegląd ustaleń audytu

Kiedy używać

• Implementacja funkcji wrażliwych na bezpieczeństwo (auth, płatności, obsługa danych)
• Duży refaktoring, gdzie łatwo coś zepsuć
• Praca z nieznanym codebase lub frameworkiem
• Gdy koszt buga na produkcji jest wysoki
• Każda zmiana dotykająca więcej niż 5 plików

Kiedy NIE używać

• Trywialne zmiany (zmiana nazwy zmiennej, literówka)
• Eksploracyjne prototypowanie, gdzie jakość nie ma jeszcze znaczenia
• Gdy i tak zrobisz porządne PR review i czas jest krótki

Wynik

Builder produkuje: działający kod, commity, PR Audytor produkuje: listę ustaleń rankingowaną według ważności, sugerowane naprawy, finalną akceptację lub blokadę