O czym jest ten film
- Autor omawia pięciostopniową skalę korzystania z agentów kodujących AI — od „pikantnego autouzupełniania” po „ciemną fabrykę” — opartą na wpisie blogowym Dana Shapiro.
- Skala jest zbudowana na analogii do poziomów automatyzacji jazdy samochodem: od pełnej kontroli kierowcy po pojazd bez kierownicy.
- Poziom 0–1 to AI jako podręczna wyszukiwarka i „stażysta” piszący kod szablonowy; poziom 2 to „junior developer”, któremu ufamy tylko w łatwych sytuacjach.
- Zdaniem autora większość osób tkwi dziś na poziomie 2, a celem powinien być poziom 3 — pełna delegacja pisania kodu przy zachowaniu człowieka w pętli planowania i walidacji.
- Cole Medin twierdzi, że sam od ponad roku nie napisał ani jednej linijki kodu ręcznie — całość deleguje agentowi, „kanapkując” implementację między planowanie i walidację.
- Poziom 4 („zespół inżynierski”) to praca na dużych specyfikacjach i PRD z rzadszą kontrolą; poziom 5 („ciemna fabryka”) to system, do którego wchodzi spec, a wychodzi kod wdrożony na produkcję — bez człowieka w pętli.
- Autor ostrzega: bez ugruntowanego, sprawdzonego systemu niezawodność na poziomach 4–5 gwałtownie spada; jeden błąd w specyfikacji może skutkować dziesiątkami wadliwych wdrożeń.
- Film wyjaśnia, czym jest „system” dla kodowania z AI: warstwa AI (reguły, subagenci, skille) nadbudowana nad agentem kodującym oraz pętla RPIV — research, planowanie, implementacja, walidacja.
- Kluczowa praktyka to ewolucja systemu: każdy błąd agenta powinien prowadzić do poprawy reguł lub workflow, a nie tylko do załatania kodu.
- Ciemna fabryka wymaga osobnych agentów do planowania, generowania kodu, code review, wdrożeń i orkiestracji — jest możliwa (przykład: StrongDM), ale to ogromny wysiłek inżynieryjny i osobna warstwa do zbudowania.
Redakcyjne tłumaczenie
Jak różnie używamy agentów kodujących
Każdy korzysta z asystentów kodowania AI inaczej — i zdziwilibyście się, jak szerokie jest to spektrum, nawet wśród firm, które za pomocą tych narzędzi wysyłają kod na produkcję. Najlepsze wyjaśnienie tych różnic, na jakie trafiłem, pochodzi od Dana Shapiro: to wpis blogowy o pięciu poziomach — od „pikantnego autouzupełniania” po „ciemną fabrykę”. Naprawdę warto zrozumieć, na którym poziomie jesteście teraz i do którego powinniście dążyć. Co ważne, poziom optymalny dla was zmienia się w czasie, w miarę jak budujecie bardziej ustrukturyzowane podejście do kodowania z AI.
W tym materiale chcę prosto omówić każdy poziom i pomóc wam ustalić, gdzie powinniście być dziś. Podzielę się też szczerymi przemyśleniami, zwłaszcza o ostatnich poziomach — szczególnie o ciemnej fabryce. Widzę, że wiele firm rzuca się na nią już teraz; sam zresztą zbudowałem własną. Ale ciemna fabryka, choć potężna, ma sporo wad.
Cały artykuł Shapiro opiera się na analogii do prowadzenia samochodu — w 2013 roku pewna organizacja zdefiniowała pięć poziomów automatyzacji jazdy i da się je bardzo zgrabnie odwzorować na to, jak współpracujemy z asystentami kodowania: na ile się na nich opieramy, a na ile trzymamy ręce na kierownicy. (Informacja dodatkowa: chodzi o klasyfikację poziomów autonomii jazdy SAE, powszechnie używaną w branży motoryzacyjnej.)
Poziom 0: pikantne autouzupełnianie
Pierwszy szczebel to „pikantne autouzupełnianie” — uwielbiam tę nazwę. Tutaj wciąż piszecie każdą linijkę kodu samodzielnie, a agenta używacie jako narzędzia referencyjnego, czegoś w rodzaju ulepszonej wyszukiwarki. To taki mądrzejszy Stack Overflow. Agent nigdy nie ma ostatniego słowa i nie pisze ani linijki kodu, ale stale pytacie go: „jak to zarchitektować?”, „jak napisać tę funkcję?”. W analogii motoryzacyjnej to samochód waszych rodziców — może z automatyczną skrzynią biegów, ale poza tym maksymalnie manualny. Zauważcie, że to w istocie poziom zero, bo agent tak naprawdę niczego za nas nie robi.
Poziom 1: stażysta, czyli tempomat
Poziom pierwszy to „stażysta programistyczny” — odpowiednik tempomatu. To pierwszy stopień autonomii: przynajmniej jeden element auta jest zarządzany za nas. Agent pisze tu kod nieistotny lub szablonowy: konfiguruje początkowe repozytorium, instaluje pakiety, pisze testy jednostkowe, robi proste refaktoryzacje. Nie powierzacie mu niczego, co wymaga prawdziwego rozumowania, ale i tak oszczędzacie sporo czasu.
Poziom 2: junior developer — i tu prawdopodobnie jesteś
Poziom drugi to „junior developer”. Zaczynacie polegać na agencie — czy też na samochodzie — dość mocno, ale tylko w niektórych sytuacjach. To jak autopilot na autostradzie: gdy jednak wjeżdżacie do miasta, gdzie jest mnóstwo skrętów i zasad, przestajecie mu ufać. Robicie dużo pair programmingu, oddajecie sporo nudnej roboty, ale wciąż są rzeczy, przy których nie ufacie agentowi i prowadzicie proces bardzo ręcznie.
Jest spora szansa, że właśnie tu teraz jesteście. Bo jeśli nie macie ugruntowanego systemu korzystania z asystentów AI — i rozwijania go w czasie, o czym zaraz — to pewnie nie ufacie im przy każdym rodzaju zadania. Są rzeczy, przy których myślicie: „szybciej zrobię to sam”, zwłaszcza jeśli jesteście technicznie biegli. A ja naprawdę zachęcam, żeby wyjść poza poziom drugi.
Poziom 3: developer — tu chcę, żebyś był
Poziom trzeci to miejsce, w którym naprawdę chcę was widzieć. Dojść tu łatwo nie jest — ufać agentowi w łatwych rzeczach, jak autopilotowi na autostradzie, potrafi każdy. Ale gdy stworzycie prawdziwy system planowania, implementacji i walidacji, wtedy wchodzicie na poziom trzeci: „developer”. To moment, w którym agent pisze większość waszego kodu — tak przynajmniej mówi artykuł. Ja poszedłbym jednak dalej: na poziomie trzecim, na którym sam głównie operuję, delegujecie agentowi całość kodowania. Ja sam od ponad roku nie napisałem ani jednej linijki kodu — co brzmi szalenie, bo przez lata pisałem kod codziennie. Jako inżynier potrzebowałem czasu, żeby zbudować system i zaufanie pozwalające dojść do poziomu trzeciego.
To jest optymalny punkt równowagi między niezawodnością a autonomią. W analogii samochodowej: to Waymo z kierowcą bezpieczeństwa. (Informacja dodatkowa: Waymo to autonomiczne taksówki należące do Alphabetu; „kierowca bezpieczeństwa” siedzi za kierownicą gotów przejąć kontrolę.) Pozwalacie agentowi — czy samochodowi — prowadzić całkowicie, ale wciąż siedzicie na fotelu kierowcy, jesteście uważni, sterujecie procesem. Kluczowa zasada poziomu trzeciego brzmi: jedynym powodem, dla którego możemy delegować całe kodowanie i temu zaufać, jest to, że „kanapkujemy” implementację między obfite planowanie a obfitą walidację, w których sami bardzo aktywnie uczestniczymy. Delegujecie cały kod, ale zostajecie za kierownicą.
Poziom 4: zespół inżynierski
To zaczyna się zmieniać na poziomie czwartym — „zespole inżynierskim”. Przekazujecie agentowi znacznie większe pakiety pracy do samodzielnego wykonania. Wciąż trzymacie ster, ale „śpicie na długie okresy”: pozwalacie agentowi przemielić większy zakres roboty na podstawie czegoś w rodzaju epika, dokumentu PRD czy specyfikacji. Na poziomie trzecim pracujemy zadanie po zadaniu, planując i walidując razem z agentem; tutaj ustalamy tylko bardzo wysokopoziomowy kierunek na starcie, a walidujemy na samym końcu — na przykład przeglądając zestaw pull requestów. To jeszcze nie ciemna fabryka: fotel kierowcy nadal istnieje, mamy pewną kontrolę nad systemem, tylko korzystamy z niej rzadko.
I właśnie na tym poziomie niezawodność zaczyna gwałtownie spadać — dopóki nie macie zaufanego, naprawdę dobrze ugruntowanego workflow dla kodowania z AI, prowadzącego od pomysłu aż do produkcji. Dojście do tego trwa. Dlatego zalecam, żebyście zostali na poziomie trzecim — przynajmniej na dłuższy czas — budując system, a dopiero potem stopniowo zwiększali autonomię agenta. W istocie chodzi o to, żeby wziąć system, którego byliście aktywną częścią, i stopniowo wyjmować z pętli człowieka, przechodząc na poziomy cztery i pięć.
Poziom 5: ciemna fabryka
Na poziomie piątym to już właściwie nie jest samochód. Na ilustracji z artykułu nie ma kierownicy — nie możemy przejąć sterów, nawet gdybyśmy chcieli. Jest jeszcze konsola w tym pojeździe — czy raczej statku kosmicznym — która pozwala wprowadzać dyrektywy najwyższego poziomu, ale samym procesem rozwoju oprogramowania nie sterujemy w ogóle.
Ciemna fabryka działa tak: na wejściu jest wasza specyfikacja — duży dokument opisujący wszystko, co chcecie zbudować — a na wyjściu jest kod wdrożony na produkcję. To chyba największa różnica między poziomem piątym a czwartym: na czwartym nie ufacie agentowi na tyle, by wdrażał prosto na produkcję; na piątym — tak. I jeśli brzmi to trochę strasznie, to słusznie. Dlatego mówię, że na tym poziomie autonomii trzeba być bardzo ostrożnym. Wystarczy jedna rzecz źle opisana w specu albo jedno błędne założenie agenta, a skutkiem mogą być dziesiątki wdrożeń, które kompletnie rozmijają się z tym, co chcieliście stworzyć.
A jednak — koniec końców ciemna fabryka to ideał. Jeśli wasz biznes dojdzie do punktu, w którym wysyłacie spec i dostajecie wdrożony kod, to jest marzenie. I zaczynamy zbliżać się do momentu, w którym ciemna fabryka staje się realistyczna. Chcę to sformułować bardzo ostrożnie, bo nie chcę, żebyście od razu się na nią rzucali — ale uważam, że z obecnymi narzędziami i modelami da się tam dojść. Na poziom trzeci można wskoczyć bardzo szybko — tego właśnie uczę na moim kanale i w społeczności Dynamous: budowania systemu, w którym jesteście w pętli przy każdym pojedynczym buildzie, ale macie już sporą autonomię, bo całe kodowanie delegujecie agentowi. Zaczynacie tutaj, a potem stopniowo wyjmujecie człowieka z pętli, w miarę jak rośnie zaufanie, że system rozumie waszą bazę kodu i wasze procesy.
Niektóre firmy zaczynają zresztą wychodzić z cienia i opowiadać, że mają działającą ciemną fabrykę. Jednym z przykładów jest StrongDM — podlinkuję artykuł w opisie. Większość firm niczego tak nie dokumentuje, więc na razie krążą raczej pogłoski o tych, którym się to udaje — nawet w bankowości, gdzie kod trafiający na produkcję musi być bezbłędny. To zdecydowanie możliwe, ale potrzebujemy systemu, żeby tam dojść.
Wstawka sponsorska: Sonar i Guitar
Sponsorem dzisiejszego materiału jest Sonar — firma robiąca teraz duże ruchy w obszarze kodowania z AI. Rzeczywistość jest taka, że AI pisze dziś ogromną część nowego kodu i to nie zwolni. Problem w tym, że tradycyjne code review i bramki jakości nigdy nie były projektowane pod taki wolumen i takie tempo: błędy się prześlizgują, błędy AI nawarstwiają się na sobie, a baza kodu szybko robi się krucha. Dlatego Sonar przejął Guitar — narzędzie do AI code review, które faktycznie naprawia kod. To nie kolejny agent rzucony na problem, tylko cały „harness” walidacyjny, który podnosi niezawodność kodu i zapewnia pełną widoczność.
Guitar podłącza się do repozytoriów GitHub lub GitLab i po otwarciu pull requesta przeprowadza kompleksowe code review — a znalezione problemy potrafi też automatycznie naprawić. W pokazanym przykładzie zidentyfikował i naprawił podatność SQL injection. Co najlepsze, każdą poprawkę automatycznie waliduje względem waszego CI. Czyta też za was logi z nieudanych buildów: deduplikuje błędy, pomaga wyłapać niestabilne testy i porządkuje błędy builda i lintera, żebyście nie tonęli w logach. To wszystko wpisuje się w Sonarowy „agent-centric development lifecycle” — framework oparty na trzech filarach: prowadź, weryfikuj, rozwiązuj — a Guitar świetnie pasuje do filaru weryfikacji. Zespoły używające Sonara mają o 44% mniejsze ryzyko awarii produkcyjnych spowodowanych kodem generowanym przez AI. Nie chodzi o zastąpienie ludzkiego osądu — to poważna siatka bezpieczeństwa pod wszystkim, co wysyła wasz agent. Guitar ma 14-dniowy darmowy okres próbny, bez karty kredytowej; link w opisie.
Czym właściwie jest „system” dla kodowania z AI
Sporo myślałem, jak wam zwięźle opisać, czym jest system dla kodowania z AI. Nie chcę tu wchodzić głęboko w inżynierię systemów czy inżynierię kontekstu — chcę dać wam obraz tego, co będziecie budować i rozwijać, żeby z czasem móc ufać agentowi coraz bardziej. Sięgnąłem po parę materiałów z kursu agentic coding w Dynamous.
Zacznijmy od warstwy AI — to komponenty, które budujecie na wierzchu agenta kodującego: reguły, skille i tak dalej, dzięki którym agent rozumie wasze konwencje, kontekst bazy kodu i wasze workflow. Gdy myślimy o inżynierii harnessów — czyli budowaniu systemu dla kodowania z AI — wszystko zaczyna się na „warstwie zero”: wyborze narzędzia. Tej warstwy nie kontrolujecie, ale ją wybieracie. Agent kodujący sam w sobie jest harnessem: opakowuje duży model językowy w narzędzia i instrukcje, które czynią z niego asystenta kodowania. My budujemy warstwę wyżej — i tę już kontrolujemy. Opakowujemy agenta (który opakowuje LLM), dostarczając kontekst już nie o tym, „jak być asystentem kodowania”, ale o tym, jak ma być agentem kodującym konkretnie w naszej bazie kodu, z naszymi procesami.
Składa się na to sześć komponentów. Tworzymy reguły — konwencje, których agent ma przestrzegać. Mamy subagentów — sposób delegowania pracy i zarządzania kontekstem. Mamy skille — spakowane workflow: tak chcemy, żeby agent planował, tak ma implementować, taką procedurę ma przejść na podstawie tego, co mu przekażemy. Nie muszę tu wchodzić w szczegóły wszystkich sześciu komponentów — mam osobny film, który podlinkuję. Ważne, że to są komponenty, które tworzymy, żeby agent rozumiał nasze konwencje i proces; budujemy je i składamy razem w pełny workflow. I to właśnie jest system.
Pętla RPIV: od pomysłu do produkcji
Szybko omówię diagram przepływu. Najpierw budujemy warstwę AI — zarówno dla projektu greenfield, jak i brownfield. Startując od zera, budujemy początkowe reguły i workflow od pomysłu na to, co chcemy stworzyć; pracując na istniejącej bazie kodu — poznajemy kod i go dokumentujemy, spisujemy konwencje, budujemy workflow. Tak czy inaczej wszystko zbiega do tego samego procesu, który nazywam pętlą RPIV. (Informacja dodatkowa: skrót od Research, Plan, Implement, Validate — badaj, planuj, implementuj, waliduj.) Tak buduję każdą nową funkcję i naprawiam każdy błąd w dowolnej bazie kodu.
Zaczynam od researchu — eksploracji, jak zabierzemy się za dany problem. Potem robię ustrukturyzowane planowanie — i znów: mam reguły, subagentów i skille, które napędzają ten wyższy proces. To jest ten system. Powstaje ustrukturyzowany plan, zawierający między innymi strategię walidacji i listę zadań dla agenta. Jak mówiłem — na poziomie trzecim, który rekomenduję, jesteście bardzo aktywną częścią tego etapu: rozmawiacie z agentem, żeby wszystko ustalić, pozwalacie mu „przemaglować” was pytaniami, które usuwają założenia, i dopiero wtedy powstaje finalny plan, który idzie do implementacji. Do niej mamy kolejny skill, kolejny workflow, według którego agent pracuje na stworzonym planie. A na końcu — dużo walidacji: system pozwalający agentowi odpalać testy jednostkowe, a nawet pełne testy end-to-end, plus walidacja ludzka, jeśli chcecie mieć najwyższą niezawodność.
To najszybsze streszczenie pełnego systemu dla kodowania z AI, jakie kiedykolwiek zrobiłem: budujemy komponenty tworzące nasz harness, a potem używamy go w tym przepływie.
Ewolucja systemu: z każdego błędu lekcja
Nie będę tu długo mówić o ewolucji systemu, ale jest jedna kluczowa idea: za każdym razem, gdy agent popełni błąd, warto nie tylko go załatać i iść dalej, ale porozmawiać z agentem o tym, którą część warstwy AI możemy poprawić, żeby ten problem już się nie powtórzył — albo przynajmniej był mniej prawdopodobny. Może da się doszlifować jakiś workflow, może dodać nową regułę adresującą to, co agent zepsuł.
Wracając do artykułu: kiedy docieracie do poziomu trzeciego, właśnie wtedy zaczynacie mieć taki system — dla siebie albo jako standard zespołowy: reguły, skille, całą warstwę AI, złożoną w opisany przepływ, czyli konkretny sposób, w jaki razem z agentem przechodzicie wszystkie kroki od pomysłu do produkcji czy pull requesta. A gdy przy każdej pętli RPIV robicie ewolucję systemu — pytając, jak ulepszyć warstwę AI i proces — z czasem dojdziecie do punktu, w którym przy nowym zgłoszeniu myślicie: „wiem, że mój agent to po prostu wymiecie; nie muszę nawet iterować nad planem ani walidować poza paroma szybkimi kontrolami wyrywkowymi”. Gdy tam dotrzecie, wiecie, że możecie przejść na poziom czwarty, a może i piąty. Budujecie taki „mięsień” zaufania do tego, co system potrafi. Rozwijacie go i zaczynacie powierzać mu wiele zadań działających autonomicznie — to poziom czwarty. A ciemna fabryka wymaga wyniesienia systemu jeszcze dalej, poza to, co pokazałem.
Co naprawdę składa się na ciemną fabrykę
Na koniec: co trzeba zrobić, żeby taki system przekształcić w pełnoprawną ciemną fabrykę? Znalazłem artykuł — podlinkuję w opisie — który bardzo ładnie to ujmuje. Jak sami piszą: ciemna fabryka to nie po prostu „AI pisze kod”. To system z odrębnymi komponentami obsługującymi różne etapy pipeline’u rozwoju oprogramowania. Skoro mamy przejść od ogromnej specyfikacji do wdrożonego kodu, potrzebujemy wielu agentów: do triażu zadań ze specu, do budowania każdego z nich, do przeglądania pull requestów, do zarządzania wdrożeniami, do testów regresyjnych. W ciemnej fabryce jest naprawdę dużo elementów.
Sam zresztą zrobiłem na moim kanale serię livestreamów — jeden podlinkuję — na których budowałem ciemną fabrykę na żywo, używając Archona, mojego open-source’owego buildera harnessów, do stworzenia workflow zarządzających poszczególnymi częściami pipeline’u. Było z tym mnóstwo pracy, a i tak zostawał milion rzeczy do zrobienia, żeby całość była naprawdę niezawodna. To był raczej eksperyment — nazwałem go moim „eksperymentem ciemnej fabryki”.
Wszystko zaczyna się od agenta planującego: gdy duży spec zostanie rozbity na pojedyncze zadania, potrzebny jest agent, który zaplanuje każde z nich — tak jak w systemie, który pokazałem wcześniej: powstaje ustrukturyzowany dokument markdown, plan ataku dla konkretnej funkcji czy błędu. Ten dokument trafia do agenta generującego kod — jest tam handoff, zwykle w postaci pliku markdown przekazywanego kolejnemu agentowi, który wykonuje plan i tworzy pull request. Potem warstwa walidacji, która ten pull request recenzuje. I ważna rzecz: code review nie powinno się odbywać w tym samym oknie kontekstu co implementacja, bo narasta tam mnóstwo uprzedzeń. Dalej system wdrożeniowy — pamiętajmy, bez człowieka w pętli, prosto na produkcję — więc potrzebny jest agent, który tym zarządza, robiąc po drodze na przykład testy regresyjne. I wreszcie warstwa orkiestracji: agent wyższego poziomu, który bierze spec, dzieli go na zadania, zarządza handoffami między agentami i pilnuje, żeby nie było zdublowanej pracy ani agenta, który utknął, czekając na dane, które nigdy nie nadejdą.
Już samo czytanie tej listy pozwala wyobrazić sobie całą złożoność i miliony rzeczy, które mogą pójść źle: agenci mogą odjechać od pierwotnego specu i naprodukować masę bezsensownych zadań; mogą utknąć, czekając na handoff od agenta, który się wykrzaczył. A skoro nie ma człowieka w pętli, ryzykujecie, że te awarie wydarzą się bez większej widoczności — bo cały sens polega przecież na tym, że nie musicie na to patrzeć. Dlatego zanim w ogóle tu dotrzecie, wszystko musi być naprawdę niezawodne. A budowa warstwy orkiestracji na istniejącym systemie to osobny wysiłek inżynieryjny: nie wystarczy doprowadzić system do niezawodności — trzeba jeszcze zbudować na nim kolejną warstwę. To dużo pracy. Ciemna fabryka pozostaje marzeniem, ale tak — wymaga ogromnego nakładu inżynierii.
Zachęcam do przeczytania reszty artykułu — jest tam dużo dobrego, w tym rzeczy, nad którymi pracuję w Archonie, jak węzły deterministyczne i agentowe. Czasem w kroku workflow potrzebna jest zdolność rozumowania LLM-a, a czasem nie — i całość można uczynić bardziej niezawodną, obsługując pewne rzeczy deterministycznie, zwykłym kodem: formatowanie kodu, uruchomienie lintera, wyzwolenie wdrożenia. Nie zawsze potrzebny jest LLM. To jedna z rzeczy wbudowanych w Archona — sama idea inżynierii harnessów sterujących takimi procesami, jak to, co Stripe zrobił ze Stripe Minions. Artykuł omawia też różne tryby awarii, o których mówiliśmy — kaskadowe awarie czy „ogrywanie ewaluacji” (evaluation gaming), czyli bardzo ciekawy przypadek, gdy agent uczy się zdawać testy zamiast rozwiązywać problem. To są rzeczy, które trzeba zaprojektować, żeby ciemna fabryka w ogóle była realistyczna.
Zakończenie
Tak, to potrafi przytłaczać, gdy patrzy się na taką listę i myśli, co naprawdę trzeba zrobić, żeby to było niezawodne. Ale to jest też przyszłość kodowania z AI. Już widzimy firmy, które zaczynają skutecznie to inżynierować, a będzie to tylko coraz bardziej realistyczne w miarę, jak agenci i modele językowe stają się potężniejsi. Sam mocno w to wchodzę i was też do tego zachęcam. Zrobiłem już trochę eksperymentów i chcę nagrać więcej materiałów o budowaniu ciemnej fabryki — dajcie znać w komentarzach, czy jesteście zainteresowani. Jeśli ten materiał się wam przydał i czekacie na więcej treści o inżynierii agentowej — i może o budowaniu ciemnej fabryki — będę wdzięczny za lajka i subskrypcję. Do zobaczenia w następnym filmie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Ustal, na którym poziomie autonomii naprawdę jesteś
Na czym polega: Skala od poziomu 0 (AI jako „mądrzejszy Stack Overflow”) do poziomu 5 (ciemna fabryka) pozwala precyzyjnie nazwać, jak bardzo ufasz agentowi kodującemu i gdzie trzymasz ręce na kierownicy.
Jak stosować: Przejrzyj swoje ostatnie tygodnie pracy: ile kodu napisał agent, a ile ty? Przy jakich zadaniach mu nie ufasz? To wyznacza twój poziom i pokazuje, czego brakuje, żeby wejść wyżej — zwykle brakuje systemu, nie lepszego modelu.
Na co uważać: Poziom optymalny zmienia się w czasie. Nie porównuj się z firmami chwalącymi się ciemnymi fabrykami — bez ich infrastruktury proces skopiujesz tylko powierzchownie.
2.Celem na dziś jest poziom 3, nie maksymalna autonomia
Na czym polega: Poziom 3 („developer”, Waymo z kierowcą bezpieczeństwa) to według autora optymalny punkt równowagi: agent pisze cały kod, a człowiek pozostaje w pętli planowania i walidacji.
Jak stosować: Zamiast pilnować każdej linijki, przenieś swój wysiłek na dwa końce procesu: dopracowany plan przed implementacją i rygorystyczną walidację po niej. Środek — samo pisanie kodu — oddaj agentowi w całości.
Na co uważać: Poziom 3 nie oznacza „puść i zapomnij”. Autor podkreśla, że delegacja całego kodowania jest bezpieczna tylko dlatego, że implementacja jest „skanapkowana” między planowanie i walidację z twoim aktywnym udziałem.
3.Delegacja kodowania jest możliwa tylko dzięki „kanapce” plan–implementacja–walidacja
Na czym polega: Zaufanie do agenta nie bierze się z jego jakości, tylko ze struktury procesu: gruntowne planowanie przed i wielowarstwowa walidacja po implementacji.
Jak stosować: Przed każdym zadaniem twórz ustrukturyzowany plan z listą zadań i strategią walidacji. Po implementacji uruchamiaj testy jednostkowe, testy end-to-end, a na końcu — własny przegląd, jeśli zależy ci na najwyższej niezawodności.
Na co uważać: Pomijanie któregoś końca kanapki (np. „plan w głowie” albo walidacja tylko na oko) to najszybsza droga do sytuacji, w której przestajesz ufać agentowi i cofasz się na poziom 2.
4.Zbuduj warstwę AI: reguły, subagentów i skille
Na czym polega: Agent kodujący to harness opakowujący LLM; ty budujesz warstwę wyżej — reguły (konwencje), subagentów (delegacja pracy i zarządzanie kontekstem) i skille (spakowane workflow, np. „tak u nas planujemy”), które uczą agenta twojej bazy kodu i procesów.
Jak stosować: Zacznij od spisania konwencji zespołu jako reguł, potem opakuj powtarzalne procesy (planowanie, implementacja, review) w skille. W projekcie brownfield najpierw każ agentowi poznać i udokumentować istniejący kod.
Na co uważać: Narzędzia (warstwa zero) nie kontrolujesz — możesz je tylko wybrać. Nie myl konfiguracji narzędzia z systemem: system to twoje komponenty złożone w kompletny workflow od pomysłu do produkcji.
5.Pracuj w pętli RPIV: research, plan, implementacja, walidacja
Na czym polega: Każda nowa funkcja i każdy bugfix przechodzą ten sam cykl: eksploracja problemu, ustrukturyzowany plan, wykonanie planu przez agenta, walidacja wyników.
Jak stosować: Na etapie planowania pozwól agentowi „przemaglować” cię pytaniami — celem jest usunięcie ukrytych założeń, zanim powstanie finalny plan. Plan zapisany jako dokument markdown staje się kontraktem dla etapu implementacji.
Na co uważać: Pokusa skracania pętli („to prosta zmiana, po co plan”) rośnie wraz z zaufaniem do agenta. Skracaj świadomie, w miarę jak system dowodzi niezawodności, a nie z lenistwa.
6.Każdy błąd agenta zamieniaj w ulepszenie systemu
Na czym polega: Ewolucja systemu: zamiast tylko łatać błąd agenta, przeprowadź z nim rozmowę o tym, która część warstwy AI zawiodła — i dodaj regułę lub popraw workflow, żeby błąd się nie powtórzył.
Jak stosować: Po każdej wpadce zadaj agentowi pytanie w stylu: „co w naszych regułach lub skillach powinno się zmienić, żeby to się nie powtórzyło?”. Traktuj to jak retrospektywę — mały, regularny nakład, który kumuluje się w zaufanie.
Na co uważać: To właśnie ten nawyk, powtarzany w każdej pętli RPIV, decyduje o tym, czy kiedykolwiek bezpiecznie wejdziesz na poziom 4. Bez niego twój system nie rośnie — rośnie tylko lista załatanych incydentów.
7.Na poziom 4 przechodź dopiero, gdy walidacja staje się formalnością
Na czym polega: Sygnałem gotowości do większej autonomii jest moment, w którym przy nowym zadaniu wiesz, że agent „to wymiecie” — plan nie wymaga iteracji, a walidacja sprowadza się do kilku kontroli wyrywkowych.
Jak stosować: Buduj „mięsień zaufania” stopniowo: najpierw pojedyncze zadania bez iteracji planu, potem większe pakiety pracy oparte na epiku czy PRD, walidowane zbiorczo na poziomie pull requestów.
Na co uważać: Autor ostrzega wprost: na poziomie 4 niezawodność „zaczyna nurkować”, jeśli workflow nie jest naprawdę ugruntowany. Przeskok z poziomu 2 od razu na 4 pomija budowę systemu, która czyni autonomię bezpieczną.
8.Ciemna fabryka to ideał — ale wejście do niej bez systemu jest niebezpieczne
Na czym polega: Poziom 5 to proces, do którego wchodzi spec, a wychodzi kod wdrożony na produkcję, bez człowieka w pętli. Jeden błąd w specyfikacji lub jedno złe założenie agenta może oznaczać dziesiątki wadliwych wdrożeń.
Jak stosować: Traktuj ciemną fabrykę jako kierunek, nie pierwszy krok: najpierw poziom 3, potem stopniowe wyjmowanie człowieka z pętli tam, gdzie system udowodnił niezawodność. Przykłady jak StrongDM pokazują, że to wykonalne — nawet w regulowanych branżach.
Na co uważać: Brak człowieka w pętli oznacza, że awarie dzieją się bez widoczności — cały sens fabryki polega na tym, że na nią nie patrzysz. Monitoring i niezawodność muszą być gotowe zanim przestaniesz patrzeć.
9.Ciemna fabryka to zestaw wyspecjalizowanych agentów plus orkiestracja
Na czym polega: To nie „AI pisze kod”, tylko pipeline: agent planujący, agent generujący kod, warstwa walidacji recenzująca pull requesty, agent wdrożeniowy z testami regresyjnymi i warstwa orkiestracji dzieląca spec na zadania i zarządzająca handoffami.
Jak stosować: Projektuj handoffy jako dokumenty (np. plan w markdownie przekazywany kolejnemu agentowi) i pilnuj kluczowej zasady: code review nigdy w tym samym oknie kontekstu co implementacja, bo narosłe tam uprzedzenia unieważniają recenzję.
Na co uważać: Orkiestracja to osobny projekt inżynieryjny nadbudowany na już niezawodnym systemie. Typowe tryby awarii: agenci odjeżdżający od specu, zakleszczenia na handoffach po awarii innego agenta, kaskadowe błędy i „ogrywanie ewaluacji” przez agentów.
10.Nie wszystko wymaga LLM-a — miksuj węzły deterministyczne i agentowe
Na czym polega: Część kroków workflow (formatowanie kodu, uruchomienie lintera, wyzwolenie deploymentu) da się obsłużyć zwykłym kodem, deterministycznie — co podnosi niezawodność całości. Rozumowanie LLM-a rezerwuj dla kroków, które go naprawdę potrzebują.
Jak stosować: Przejrzyj swój workflow i dla każdego kroku zadaj pytanie: czy tu potrzebne jest rozumowanie, czy wystarczy skrypt? Wszystko, co ma jednoznaczny wynik, przenieś do kodu — tak działa m.in. Archon autora i podejście Stripe’a ze Stripe Minions.
Na co uważać: Odruch „agent do wszystkiego” wprowadza niedeterminizm tam, gdzie jest zbędny, i mnoży punkty awarii. Każdy krok agentowy to koszt niezawodności — dodawaj go tylko tam, gdzie deterministyczny kod nie wystarcza.