---
name: dual-thread-development
title: Dwuwątkowy Development
description: "Wzorzec dwóch wątków do pracy z AI: jeden wątek buduje, drugi audytuje. Prowadź sesję dev i równoległą sesję review na tym samym codebase. Wątek dev implementuje funkcje; wątek audytu łapie bugi, problemy bezpieczeństwa i dryft architektoniczny w czasie rzeczywistym. Daje wyższą jakość kodu niż sekwencyjne buduj-potem-recenzuj, bo reviewer ma zerowe zanieczyszczenie kontekstem."
category: coding
tags:
  - workflow
  - development
  - testowanie
  - audyt
  - równoległość
  - jakość
source: https://madejski.ai/pl/promptoteka/dual-thread-development
locale: pl
license: MIT
---

# 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ę