Jest 16:00, a AI właśnie wygenerowało diff na 600 linii, który refaktoryzuje twój przepływ checkoutu w Next.js. Kompiluje się. Testy przechodzą. Wygląda wiarygodnie. Jedyne pytanie, które ma znaczenie, to to, na które żaden model nie odpowie za ciebie: czy naprawdę rozumiesz, co zmieniło, na tyle, by podpisać się pod tym commitem?
Ta chwila to teraz cała robota. Przyjęcie asystentów AI nie czyni developera zbędnym — przenosi twoją pracę o poziom wyżej, z pisania kodu na kierowanie nim, ograniczanie go i przeglądanie. Zespoły, które dowożą stabilny kod wspomagany przez AI, to nie te, które piszą najszybciej; to te, które nigdy nie pozwalają AI samemu zamknąć pętli.
W przepływie pracy z człowiekiem w pętli nosisz trzy kapelusze po kolei. Każdy z nich to świadomy punkt kontrolny, a nie przeczucie.
1. Architekt (planowanie)
Zanim zostanie napisana jakakolwiek linia kodu, to ty jesteś właścicielem wizji i planu. Dajesz AI wysokopoziomowe wymagania, każesz mu zbadać bazę kodu w trybie tylko do odczytu i krytycznie oceniasz jego proponowany plan. To twoje doświadczenie wyłapuje wady architektoniczne i pominięte wymagania, póki naprawienie ich jest jeszcze tanie.
2. Nadzorca (wykonanie)
Podczas implementacji dzielisz zatwierdzony plan na małe kroki i podajesz je AI po jednym na raz. Przeglądasz każdy diff, zanim zacznie się następny krok. Jesteś ręką na kierownicy, a nie widzem patrzącym, jak materializuje się commit na 600 linii.
3. Recenzent (weryfikacja)
Jesteś ostatecznym strażnikiem jakości. Traktuj każdy diff od AI jak pull request od szybkiego, ale naiwnego juniora: czytaj każdą linię, sprawdzaj przypadki brzegowe i ścieżki błędów oraz upewnij się, że nie zgadywał reguł biznesowych. AI przyspiesza pisanie — ty pozostajesz odpowiedzialny za poprawność.
Oto pętla zastosowana do prawdziwego zadania — dodania limitowania zapytań do trasy API w Next.js — wraz z promptem, który operacjonalizuje każdy kapelusz.
Architekt: zdobądź plan do przejrzenia, nie kod.
W trybie tylko do odczytu (Cursor Ask, Claude Code plan mode lub codex --sandbox read-only) zmuś AI do zaplanowania i oznaczenia założeń, zanim cokolwiek ruszy.
Nadzorca: wykonaj jeden krok, potem zatrzymaj się. Zatwierdź plan, przełącz się na tryb wykonania i ogranicz AI do pojedynczego kroku z twardym punktem kontrolnym, by przejrzeć zmiany, zanim ruszy dalej.
Recenzent: każ AI zaatakować własny diff. Zanim cokolwiek zaakceptujesz, zamień AI w sceptycznego recenzenta jego własnej pracy, a potem przeczytaj wszystko jeszcze raz samodzielnie.
Pętla planuj-wykonuj-przeglądaj jest wszędzie taka sama, ale każde narzędzie daje ci inne mechaniczne bramki, które egzekwują kapelusz Recenzenta. Korzystaj z nich.
Przejrzyj plan AI w trybie Ask, zanim przełączysz się na Agent. Podczas wykonania Cursor zapisuje punkt kontrolny przed każdym zestawem edycji — jeśli krok pójdzie źle, przywracasz dowolny wcześniejszy stan zamiast rozplątywać częściowo zastosowaną zmianę. Akceptuj lub odrzucaj każdy diff fragment po fragmencie w panelu przeglądu, zamiast akceptować hurtem, żeby nic spoza planu się nie prześlizgnęło.
Użyj plan mode (Shift+Tab lub claude --permission-mode plan) na fazę Architekta, a potem przeglądaj diffy bezpośrednio w terminalu podczas wykonania. Zamień przegląd w zautomatyzowaną bramkę za pomocą hooków: hook PreToolUse może blokować edycje chronionych ścieżek (migracje, .env, konfiguracja CI), a hook PostToolUse może automatycznie uruchamiać twój linter lub zestaw testów po każdej edycji, żeby wadliwa zmiana nie nazbierała się po cichu.
Pozwól Codeksowi pisać w worktree, żeby jego zmiany pozostały odizolowane od twojego drzewa roboczego, dopóki nie będziesz gotowy. Następnie przeprowadź właściwy przegląd przez swój istniejący przepływ pull requestów na GitHubie: Codex otwiera PR, a ty (oraz twoje zwykłe sprawdzenia CI i wymagani recenzenci) decydujesz o scaleniu. Ludzka akceptacja zostaje tam, gdzie już jest — w przeglądzie PR — zamiast w ulotnym czacie.
AI doskonale dopasowuje wzorce i generuje kod, ale brakuje mu osądu, który zapewniają te trzy kapelusze:
