Co zostaje człowiekowi w inżynierii agentowej
Człowiekowi w inżynierii agentowej zostają decyzje, których żadna wyrocznia weryfikacyjna nie podejmie za agenta: smak i architektura, kierunek produktu, projekt ewaluacji i warunków stopu, wobec których agenci pracują, uprawnienia, z jakimi chodzą, oraz decyzja, które pętle nie mogą działać bez nadzoru. Granicę wyznacza zdanie, które Karpathy cytuje z aprobatą: myślenie da się zlecić na zewnątrz, zrozumienia nie.
Niewygodna wersja pytania nie brzmi “czy będzie praca”, tylko “która praca”. Andrej Karpathy odpowiada w swoim podsumowaniu Sequoia Ascent z 30 kwietnia 2026, że zmieniła się jednostka, a nie odpowiedzialność: “Jednostka programowania przesunęła się z pisania linii kodu na delegowanie większych ‘makrodziałań’”. BCG Platinion, piszące jako konsultanci w marcu 2026, ujmuje tę samą myśl w zdaniu, które rozumie zarząd: “Zmiana definiująca nie polega na braku ludzi, tylko na przeniesieniu ludzkiego wysiłku”.
Sześć obowiązków, których nie da się przekazać
Dział zatytułowany „Sześć obowiązków, których nie da się przekazać”Nie rozkładają się na drabinie równo. Na poziomie 2 wszystkie sześć chowa się w samym pisaniu kodu i dlatego wydaje się automatyczne i bezimienne. Od poziomu 3 w górę każdy trzeba wypowiedzieć wprost, zapisać w pliku, bramce albo polityce, bo agent go nie wywnioskuje, a przechodzący zestaw testów nie zgłosi jego braku. Niżej jest ta lista, z podanym źródłem przy każdym punkcie.
Karpathy mówi o dzisiejszej pozycji agentów wprost: “Na razie agenci są jak stażyści. Nadal odpowiadasz za estetykę, osąd, smak i nadzór”. Gdzie indziej na tej samej stronie: “odpowiadasz za smak, inżynierię, projekt i za to, czy system ma sens”.
Smak nie jest dekoracją. To osąd, że działająca implementacja jest tą złą: abstrakcja, która będzie kosztować rok, zależność rozwiązująca dzisiejszy problem i przejmująca jutrzejszy, API poprawne i nie do użycia. Żaden zestaw testów na tym nie padnie i właśnie dlatego zostaje przy człowieku.
Architektura
Dział zatytułowany „Architektura”“Nadal musisz rozumieć podstawy”, pisze Karpathy, “nie będziesz dobrym reżyserem, jeśli nie rozumiesz”. Decyzja architektoniczna ma też najgorszą pętlę zwrotną w całym zawodzie: złe odpowiedzi wypływają po miesiącach, długo po tym, jak przebieg, który je podjął, poszedł w niepamięć.
Że to obowiązek nośny, a nie sentymentalny, potwierdza źródło zewnętrzne. Raport DORA z 2025 roku znalazł, że “zespoły pracujące w luźno powiązanych architekturach, z szybkimi pętlami zwrotnymi, notują zyski, a te skrępowane ciasno powiązanymi systemami i wolnymi procesami zyskują niewiele albo nic”. Architektura rozstrzyga, ile z przyspieszenia zespół zatrzyma.
Kierunek produktu
Dział zatytułowany „Kierunek produktu”Karpathy nazywa wąskie gardło bez łagodzenia: “Sam staję się wąskim gardłem w tym, żeby w ogóle wiedzieć, co próbujemy zbudować, po co to robić i jak kierować agentami”. Człowiek z poziomu 4 u Shapiro (The Five Levels, styczeń 2026) pisze specyfikację i pracuje bliżej menedżera inżynierii albo produktu niż programisty.
Agent zbuduje to, co mówi specyfikacja, z cierpliwością większą niż jakikolwiek zespół. Nie powie ci, że tej funkcji nie powinno być.
Projekt ewaluacji i warunku stopu
Dział zatytułowany „Projekt ewaluacji i warunku stopu”Ten obowiązek rośnie, gdy inne maleją. Na poziomie 4 warunek stopu jest wytworem twojego osądu: co znaczy “zrobione”, zapisane jako komendy kończące się kodem 0. Wersja Shapiro brzmi “wychodzisz na 12 godzin i sprawdzasz, czy testy przechodzą”, a to jest bezpieczne tylko wtedy, gdy ktoś te testy zaprojektował.
Argument za determinizmem dobrze ujmuje Naresh (DEV Community), pisząc o inżynierii grafowej w lipcu 2025: “Model może argumentować, że jego praca jest skończona. Deterministyczny walidator może udowodnić, że brakuje wymaganego pola”. Fabryka Stripe’a to ta sama myśl w skali: Minions pracują wobec “ponad trzech milionów” istniejących wcześniej testów, z ograniczeniem do “najwyżej dwóch rund CI”, po których “odsyłamy gałąź do jej ludzkiego operatora do ręcznej kontroli”.
Wyrocznia jest tą częścią systemu, której agentowi nigdy nie wolno napisać. Jej wybór to zadanie człowieka, a trzymanie jej poza zasięgiem agenta to ograniczenie projektowe, nie preferencja.
Uprawnienia
Dział zatytułowany „Uprawnienia”To, co agent może uruchomić bez nadzoru, jest decyzją, a każde narzędzie prosi cię, żebyś ją podjął. Codex dokumentuje politykę zatwierdzeń określającą, “kiedy Codex musi cię zapytać, zanim wykona działanie (na przykład wyjdzie z sandboksa, użyje sieci albo uruchomi komendy spoza zaufanego zbioru)”, z nazwanymi trybami. Tryb auto w Claude Code przepuszcza “wywołania narzędzi przez klasyfikator, który blokuje wszystko nieodwracalne, destrukcyjne albo wycelowane poza twoje środowisko”, a jego sandbox prosi, żeby “zdefiniować, jakich plików i domen sieciowych mogą dotykać komendy”. Cursor wystawia do tego samego wyboru tryby uruchamiania.
Ustawienia domyślne nie są polityką. Zbiór uprawnień, który przebieg bez nadzoru dziedziczy o trzeciej w nocy, to ten zostawiony przez ostatnią sesję, a to jest decyzja podjęta przez kogoś, kto jej nie podjął.
Decyzja, żeby czegoś nie automatyzować
Dział zatytułowany „Decyzja, żeby czegoś nie automatyzować”Tekst inżynierski Lineara o delegowaniu agentom, sierpień 2025, stawia zasadę prościej niż jakakolwiek dokumentacja producenta: “agenta nie da się pociągnąć do odpowiedzialności”. Produkt to wymusza, bo “zgłoszenia można przypisywać tylko ludziom, a agentom tylko delegować”, więc “zgłoszenie nadal ma ludzkiego przypisanego, kogoś odpowiedzialnego za wynik, ale ma też delegowanego agenta odpowiedzialnego za działanie”.
Odpowiedzialności się nie deleguje, więc ktoś musi zdecydować, co chodzi bez nadzoru, i umieć się z tego wytłumaczyć. W praktyce ta decyzja ma kształt: nazwana osoba na pętlę, spisany powód i data przeglądu. Pętle, które ranią zespoły, rzadko są tymi, które ktoś świadomie zautomatyzował. To te, które zostały bez nadzoru, bo nikt nie powiedział inaczej.
Kiedy pętla nie może działać bez nadzoru
Dział zatytułowany „Kiedy pętla nie może działać bez nadzoru”Rozstrzygają to cztery pytania z tekstu o fabrykach oprogramowania, zadane pętla po pętli i na piśmie:
- Jaka wyrocznia rozstrzyga, że “zrobione”? Nazwij konkret. “Testy przechodzą” to wyrocznia. “Wygląda dobrze” nie.
- Czy agent może to podrobić? Jeśli agent może edytować wyrocznię, wyrocznia jest sugestią.
- Ile trwa, zanim zła odpowiedź wypłynie? Sekundy to zielone światło. Trzy tygodnie to czerwone.
- Jaki jest zasięg rażenia, jeśli odpowiedź jest zła? Odwracalny i ograniczony, czy migracja schematu.
Odpowiadaj na nie na piśmie, pętla po pętli, i trzymaj odpowiedzi tam, gdzie znajdzie je następna osoba. Pętla, która czysto odpowiada na wszystkie cztery, może dziś chodzić po ciemku; ta, która oblewa pytanie 2 albo 3, zostaje przy świetle, choćby harness był najlepszy. Pięć klas pracy oblewa te pytania na tyle często, że warto nazwać je z góry.
Schemat, autoryzacja, cennik i migracje. Wyrocznią jest zachowanie na produkcji, informacja zwrotna idzie dniami albo tygodniami, a zasięg rażenia to klienci. Te zostają przy świetle: człowiek czyta diff, za każdym razem.
Wszystko, co nie ma wyroczni działającej w CI. Standardowym przykładem są refaktory architektoniczne. Nie ma czego uruchomić, żeby powiedziało, że nowy kształt jest lepszy, a odpowiedź przychodzi po miesiącach. Zamiast automatyzacji zainwestuj z góry w planowanie.
Praca, w której agent trzyma obie strony. Robota nad funkcją w dobrze pokrytym module wygląda na pętlę z zielonym światłem, dopóki nie zauważysz, że agent napisał i funkcję, i testy, które ją przepuszczają. Albo plan czyta człowiek, albo rozstrzygające sprawdzenie jest starsze niż zmiana.
Pętle z wolną informacją zwrotną. Wszystko, gdzie zła odpowiedź wypływa dopiero wtedy, gdy zauważy ją człowiek, a nie gdy komenda kończy się kodem różnym od zera, po cichu zbiera błędy.
Wszystko, co czyta tekst pisany przez kogoś z zewnątrz. Treści zgłoszeń, komentarze do pull requestów, ładunki webhooków, zescrapowane strony i poczta przychodząca to wejścia kontrolowane przez atakującego. Agent bez nadzoru, z narzędziami i powierzchnią na prompt injection, jest ścieżką zdalnego wykonania kodu pod przyjazną nazwą. Jeśli taka pętla musi działać, opakuj wejście jako dane, odbierz mu prawo wydawania poleceń i daj mu najwęższy zbiór uprawnień w całym systemie.
Gotowe prompty, które utrzymują robotę przy człowieku
Dział zatytułowany „Gotowe prompty, które utrzymują robotę przy człowieku”Gdzie robota człowieka po cichu znika
Dział zatytułowany „Gdzie robota człowieka po cichu znika”Recenzent zmienia się w zatwierdzającego. Faros AI zmierzył w kwietniu 2026, na 22 000 programistów, o 31,3% więcej pull requestów scalanych całkiem bez review. Nikt tego nie postanowił; działo się po jednym zabieganym popołudniu naraz. Uczciwa wersja to spisana reguła, które klasy zmian mogą wejść nieprzeczytane.
Wyrocznia staje się specyfikacją. Kiedy testy są jedynym zapisem tego, co znaczy “poprawnie”, decyzje produktowe przenoszą się do fixture’ów, gdzie nikt ich nie przegląda i nikt ich później nie znajdzie.
Odpowiedzialność dryfuje do narzędzia. “Agent to zrobił” nie jest odpowiedzią na przeglądzie incydentu. Reguła Lineara, w której zgłoszenie zostaje przy człowieku, jest tanią wersją naprawy, która po pierwszej awarii robi się droga.
Zrozumienie odchodzi ostatnie i po cichu. Zdanie, które Karpathy cytuje z aprobatą, jest ostrzeżeniem: myślenie możesz zlecić na zewnątrz, ale zrozumienia nie. Zespół, który przestaje umieć wytłumaczyć własny system, stracił coś, czego nie pokaże żadna liczba o przepustowości.
Poziom 5 bywa mylony z celem podróży. Ciemna fabryka Shapiro, gdzie “ludzie nie są ani potrzebni, ani mile widziani”, opisuje garstkę zespołów poniżej pięciu osób. Sześć obowiązków powyżej opisuje poziom 4, na którym leżą opublikowane dowody i na którym jest ciekawa robota.