Człowiek w pętli to developer, który w jednym zadaniu przechodzi przez trzy role: architekta, gdy powstaje plan, nadzorcy, gdy agent implementuje, i recenzenta, zanim zmiana trafi do commita. Dopasowanie roli do ryzyka zadania oddziela bezmyślną pieczątkę od wąskiego gardła i trzyma nieprzejrzany diff z dala od produkcji.
Jest 16:00, a agent właśnie przepisał twój moduł uwierzytelniania: piętnaście plików, 800 zmienionych linii. Kompiluje się, testy przechodzą, wygląda wiarygodnie, więc akceptujesz całość. Dwa tygodnie później odkrywasz, że przepisanie po cichu usunęło sprawdzanie CSRF, które było w oryginalnym kodzie. Nikt tego nie wychwycił, bo nikt naprawdę nie przeglądał.
Druga skrajność kosztuje tyle samo. Zatwierdzaj każdy pojedynczy zapis pliku, a spędzisz na nadzorowaniu agenta więcej czasu, niż zajęłoby ci samodzielne napisanie kodu. Czytanie każdej wygenerowanej linii miało sens, gdy diff pisał człowiek; nie przetrwa zderzenia z agentem, który pisze większość kodu.
Odpowiedzią nie jest więc ani ślepe zaufanie, ani ciągły nadzór. Zespoły, które dowożą stabilny kod wspomagany przez AI, skupiają się na bramkach — zatwierdzony plan, findings z recenzji agenta, merge, autoryzacja wdrożenia — a pomiędzy nimi pozwalają sesji sprawdzać własną pracę. Te bramki rozpisuje AI-native SDLC; ta strona mówi, kto przy nich stoi i co tam naprawdę robi.
Twoja rola zmienia się w trakcie sesji, a każda zmiana to świadomy punkt kontrolny, a nie przeczucie. Rozpoznanie, w której właśnie jesteś, oszczędza czas i wychwytuje problemy, póki naprawienie ich jest tanie.
1. Architekt (planowanie)
Zanim powstanie jakikolwiek kod, to ty jesteś właścicielem wizji i planu. Dajesz agentowi wysokopoziomowe wymagania, każesz mu zbadać bazę kodu w trybie tylko do odczytu i krytycznie oceniasz proponowany plan. Spędź tu najwięcej czasu: błędy architektoniczne są najdroższe do naprawienia, a to twoje doświadczenie wyłapuje pominięte wymaganie, póki wyłapanie go nic nie kosztuje.
2. Nadzorca (wykonanie)
Agent implementuje, a ty monitorujesz. Dzielisz zatwierdzony plan na małe kroki, podajesz je po jednym i przeglądasz strumień zmian pod kątem czerwonych flag — plików, których nie powinien dotykać, podejścia, na które nikt się nie umawiał. Nie musisz rozumieć każdej linii w czasie rzeczywistym, ale jesteś ręką na kierownicy, a nie widzem patrzącym, jak materializuje się commit na 800 linii.
3. Recenzent (weryfikacja)
Zadanie jest skończone i to ty decydujesz, czy idzie dalej. Jesteś strażnikiem intencji i ryzyka, nie każdej wygenerowanej linii. Rutynowe diffy najpierw przechodzą warstwową recenzję agenta (REVIEW.md, Bugbot, claude-code-action albo recenzja Codex); czytasz plan, podsumowanie PR i to, co agent oflagował. Linia po linii przeglądasz kod regulowany lub krytyczny, albo gdy finding mówi, że zmiana może zepsuć zachowanie, wyciec dane lub złamać politykę. Agent przyspiesza tworzenie; merge i produkcja nadal należą do ciebie.
Oto pętla zastosowana do prawdziwego zadania — dodania limitowania zapytań per użytkownik do trasy API w Next.js — wraz z promptem, który operacjonalizuje każdą rolę.
Architekt: proś o plan do przejrzenia, nie o kod.
W trybie tylko do odczytu (Cursor Ask, Claude Code plan mode lub codex --sandbox read-only) zmuś agenta do zaplanowania i oznaczenia zgadywanek, zanim cokolwiek ruszy. Sekcja „Assumptions” jest tu tym, co naprawdę się opłaca: zamienia niewidoczne założenia w listę, którą poprawisz w trzydzieści sekund.
Nadzorca: wykonaj jeden krok, potem się zatrzymaj.
Zatwierdź plan, przełącz się na tryb wykonania i ogranicz agenta do pojedynczego kroku z twardym punktem kontrolnym, żeby przejrzeć zmiany, zanim ruszy dalej. To najtańsze lekarstwo na zmęczenie recenzenta: diff, który faktycznie przeczytasz, bije diff, który przelecisz wzrokiem.
Recenzent: każ agentowi zaatakować własny diff.
Zanim cokolwiek zaakceptujesz, zamień agenta w sceptycznego recenzenta jego własnej pracy, a potem przeczytaj wszystko jeszcze raz samodzielnie. Wymienienie konkretnych zagrożeń w prompcie znaczy więcej niż poproszenie o „recenzję” — to ta konkretna lista wyciąga findings, których ogólne pytanie nigdy nie ujawni.
Nie każdy moment zasługuje na równą uwagę. Praktyczna reguła brzmi: przerwanie jest tanie wcześnie i drogie późno, więc wydawaj je na sygnały, a nie na każdy zapis pliku.
Interweniuj natychmiast, gdy:
Monitoruj, ale nie przerywaj, gdy:
Przeglądaj po zakończeniu, gdy:
Ryzyko zadania ustawia domyślne zachowanie, a to domyślne zachowanie warto spisać dla zespołu:
| Poziom ryzyka | Typ zadania | Zalecane podejście |
|---|---|---|
| Wysoki | Zmiany w auth, migracje danych, kod bezpieczeństwa | Zatwierdzaj każdy zapis pliku. Przeglądaj diffy linia po linii. |
| Średni | Nowe funkcjonalności, endpointy API, komponenty UI | Pozwól agentowi pracować, przejrzyj całość zmiany przed commitem. |
| Niski | Formatowanie, zmiana nazw, dokumentacja, dodawanie testów | Automatyczne zatwierdzanie lub tryb bezobsługowy. Przejrzyj wiadomość commita. |
Kontrakt zakresu poniżej to najtańsza wersja wszystkich trzech list: każe agentowi zadeklarować, czego zamierza dotknąć, więc „poza ustalonym zakresem” staje się czymś, co możesz sprawdzić, a nie czymś, co zauważasz po fakcie.
Pętla jest wszędzie taka sama; mechaniczne bramki, które ją egzekwują, już nie. Korzystaj z tych, które twoje narzędzie ma na pokładzie.
Zaczynaj sesję agenta od kontraktu zakresu powyżej — to pełniejsza wersja jednolinijkowego „wypisz pliki, które zamierzasz zmodyfikować”, która wyłapuje też nowe zależności i usuwanie kodu.
Shift+Tab lub claude --permission-mode plan) blokuje wszelkie modyfikacje plików, co czyni fazę Architekta bezpiecznąPreToolUse blokuje edycje chronionych ścieżek (migracje, .env, konfiguracja CI), a hook PostToolUse uruchamia twój linter lub zestaw testów po każdej edycji, żeby wadliwa zmiana nie nazbierała się po cichuTam, gdzie prompt krokowy powyżej zatrzymuje się po kroku planu, ten zatrzymuje się po każdym pliku — przydaje się, gdy krok planu okazuje się większy, niż wyglądał:
Implement the rate limiter from the plan. After each file you modify,stop and tell me what you changed and why. Wait for my approvalbefore moving to the next file.Implement the rate limiter. Show me the full diff when done.Do not push or merge until I review.Przeglądanie outputu agenta to nie to samo co przeglądanie pracy człowieka. Agent się nie męczy, nie chodzi na skróty i nie ma gorszych dni — ale ma systematyczne martwe punkty i to tam należy się twoja uwaga.
git diff --stat daje ci kształt zmiany, zanim otworzysz choć jeden plik.Dwie różne połówki tej roboty robią dwa prompty. Autoprzegląd poniżej inwentaryzuje zmianę i oflagowuje to, czego agent nie jest pewien; prompt wrogiej recenzji z pętli powyżej atakuje ten sam diff, szukając tego, co poszło źle. Najpierw inwentaryzacja, potem atak — inwentaryzacja mówi ci, gdzie wycelować atak.
Trzecia opcja usuwa konflikt interesów w całości: jedna sesja pisze, a druga, pozbawiona kontekstu, recenzuje. Recenzent nie pamięta, dlaczego skrót wydawał się wtedy rozsądny.
Najbardziej produktywni developerzy korygują wcześnie. Delikatna korekta po pierwszym pliku jest tańsza niż przepisanie po piętnastu i o wiele tańsza niż revert po merge’u.
Stop. The approach you're taking with the notification servicewon't work because it doesn't account for our message queue.
Let me redirect: instead of direct database writes, use theexisting event bus in @src/services/eventBus.ts. Read that filefirst, then revise your approach.Jeśli Cursor zaszedł za daleko w złą stronę, cofnij się do ostatniego dobrego punktu kontrolnego, zamiast rozplątywać zmiany ręcznie.
Undo that last change. The notification service should use theevent bus pattern, not direct database writes. Readsrc/services/eventBus.ts for the pattern we use.Jeśli kontekst sesji jest zaśmiecony nieudanymi podejściami, zrób /clear i zacznij od nowa z lepszym promptem. Czysty kontekst z dobrym promptem za każdym razem bije zanieczyszczony kontekst z poprawkami.
W ChatGPT desktop dodaj kolejny prompt, żeby przekierować pracę:
Change approach: use the event bus pattern fromsrc/services/eventBus.ts instead of direct database writes.Revert the notification service changes and start over withthe event bus approach.Przy wątkach cloudowych możesz porzucić wątek w całości i zacząć nowy ze zmienionym promptem; praca oryginalnego wątku jest czysto odrzucana.
Agent doskonale dopasowuje wzorce i generuje kod. Brakuje mu dokładnie tego, co zapewniają te trzy role: