O czym jest ten film
- „Ciemna fabryka” to najwyższy, piąty poziom autonomii w kodowaniu z AI: wrzucasz ogólny opis dużego celu, a system sam planuje, buduje, testuje i wdraża na produkcję. Cole Medin budował taki system publicznie od początku roku — i teraz ogłasza: ten model nie działa.
- Powód numer jeden: modele coraz lepiej piszą kod, ale nie proporcjonalnie lepiej rozumieją ludzkie intencje. Wąskim gardłem staje się komunikowanie, czego naprawdę chcemy.
- Autor odrzuca też popularny kontrargument, że agenty kiedyś będą znać nasze potrzeby lepiej niż my sami i całkowicie przejmą rozwój oprogramowania.
- Powód numer dwa: utrzymywalność kodu. Agenty „rozłazią” bazę kodu, więc człowiek musi zostać w procesie — do tych samych wniosków niezależnie doszli Cole Medin i Dex Horthy (głośny wykład o porażkach fabryk software’owych).
- Działająca alternatywa to „fabryka software’owa AI”: pojedyncze wydania planowane wspólnie z agentem, a potem w pełni autonomiczne wykonanie całej partii zgłoszeń.
- Planowanie (PRD, architektura) jest celowo poza fabryką; epik powinien mieć rozmiar około 10–20 zgłoszeń i oprócz zakresu jasno definiować, czego świadomie nie budujemy.
- Scenariusze holdout — testy, których agent-wykonawca nie zna — chronią przed implementacjami „szytymi pod testy”; autor tłumaczy to ugodową naturą modeli.
- Pętla główna: zgłoszenie → etykieta rezerwacji → triaż (prosty czy złożony) → budowanie → walidacja „jak użytkownik” i przegląd kodu → scalanie do stagingu wyłącznie przy zielonym CI.
- Agent-menedżer co 2–3 godziny nadzoruje wszystkie przebiegi, może przejąć utknięty przepływ i wezwać człowieka; poszczególne węzły używają różnych modeli, żeby oszczędzać tokeny.
- Finał z człowiekiem: własne testy na stagingu, uwagi zgłaszane jako nowe issues (fabryka sama je podchwytuje), dopiero potem produkcja — i kolejne wydanie w tym samym rytmie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Deleguj wydanie, nie całą aplikację
Na czym polega: Ciemna fabryka zakładała jeden wielki opis całej aplikacji i pełną samodzielność agenta od początku do końca — co zmuszało model do zgadywania intencji. Fabryka software’owa oddaje agentom tylko wykonanie: zakres kolejnego wydania planujesz razem z nimi, dzielisz na zgłoszenia, a dopiero potem system działa sam.
Jak stosować: Planowanie (PRD, dokument architektury) zostaw poza systemem wykonawczym, we własnym, wypracowanym procesie. Do fabryki kieruj gotowy epik: w projekcie od zera — dowód koncepcji jako pierwsze wydanie, na istniejącym kodzie — mały epik. Punkt odniesienia: 10–20 zgłoszeń.
Na co uważać: Za duży epik to powrót do problemów ciemnej fabryki (agent znów zgaduje, czego chcesz), za mały — tracisz czas na ciągłym planowaniu i przełączaniu kontekstu.
2.Wąskim gardłem jest intencja, nie moc modelu
Na czym polega: Nowsze generacje modeli coraz sprawniej piszą kod, ale wcale nie proporcjonalnie lepiej rozumieją, czego człowiek naprawdę chce. Ludzie nigdy nie opiszą w pełni precyzyjnie ani funkcji, ani sposobu utrzymywania bazy — i to, a nie jakość generacji, staje się głównym ograniczeniem.
Jak stosować: Inwestuj w punkty, w których człowiek weryfikuje zamiar: przegląd podziału epiku na zgłoszenia przed startem oraz własne testy na stagingu po zbudowaniu. Udział człowieka traktuj jak zestaw przełączników, nie stały etap — wydanie z wymogami regulacyjnymi wymaga więcej kontroli niż czyszczenie backlogu błędów.
Na co uważać: Nie odkładaj porządkowania wymagań „do czasu lepszych modeli” — to ograniczenie leży po stronie komunikacji, nie technologii.
3.Nie wychodź z kodu całkowicie
Na czym polega: Agenty mają dziwny sposób „dbania” o bazę kodu — struktura im się rozłazi, gdy nikt tego nie pilnuje. To główna teza wykładu Dexa Horthy’ego o porażkach fabryk software’owych; on sam, podobnie jak autor, zaczął od ciemnej fabryki i musiał dodać człowieka z powrotem do procesu.
Jak stosować: Zostaw sobie (lub dedykowanemu agentowi przeglądowemu, ale pod ludzkim nadzorem) klasyczny code review z naciskiem na prostotę i utrzymywalność — nie tylko „czy działa”.
Na co uważać: Całkowite wyłączenie się z kodu mści się szybko: po kilku wydaniach baza rozrasta się na tyle, że każda kolejna iteracja robi się droższa i wolniejsza.
4.Część testów trzymaj w tajemnicy (holdout)
Na czym polega: Modele są z natury ugodowe: jeśli znają scenariusze testowe, zaprojektują implementację tak, by je przechodzić. Powstaje kod „dobry dla testów”, a nie naprawdę dobry. Scenariusze holdout definiuje się z góry, ale ujawnia dopiero na etapie walidacji — po zbudowaniu.
Jak stosować: W dokumencie epiku prowadź osobną listę takich scenariuszy, niedostępną dla wykonawcy; walidator uruchamia je na końcu, najlepiej testując aplikację tak, jak zrobiłby to użytkownik.
Na co uważać: Ukryte scenariusze muszą weryfikować zamiar (to, czego naprawdę chciał zamawiający), a nie tylko literę wymagań — inaczej holdout niczego nie wyłapie.
5.Zapisz, czego nie budujecie — i zablokuj ten plik
Na czym polega: Poza zakresem konkretnego epika fabryka korzysta ze stałego kontekstu (u autora: mission.md / engineering.md plus reguły globalne): rzeczy nigdy niepożądane w kodzie i ogólny kierunek działania agenta. To działa jak poręcze — i właśnie dlatego agent nie może tego edytować.
Jak stosować: W przeglądach kodu sprawdzaj, czy pliki kontekstu nie zostały zmodyfikowane. Fabryka nie może sobie sama przepisywać uprawnień i zasad zachowania.
Na co uważać: Sekcja „poza zakresem” w epiku i plik misji to dwie różne rzeczy — pierwsza dotyczy wydania, druga całej bazy. Plik misji aktualizuj wyłącznie ręcznie.
6.Triażuj złożoność i dobieraj model do węzła
Na czym polega: Nie każde zgłoszenie zasługuje na pełny, wieloetapowy przepływ — trywialne zadanie na 20–30 minut lepiej puścić skróconą ścieżką. Decyzję podejmuje na starcie lekki triaż (u autora: Jev). Różne węzły mogą używać różnych modeli i dostawców: planowanie na najsilniejszych (Opus 5.5, GPT-6 Astra), proste kroki na tańszych (Sonnet 5.5).
Jak stosować: Zmapuj węzły pętli i przydziel im modele według rzeczywistej potrzeby rozumowania; po każdym wydaniu audytuj zużycie tokenów. Przy dobrym doborze setki przebiegów tygodniowo nie zbliżają się do limitów API.
Na co uważać: Oszczędności nie mogą obejmować węzłów krytycznych dla niezawodności (walidacja, przegląd). Zły triaż oznacza przepłacanie za proste zadania albo zbyt mało rygoru przy złożonych.
7.Walidacja i przegląd kodu to dwie różne rzeczy
Na czym polega: Walidacja to testowanie działającej aplikacji jak użytkownik — klikanie, wpisywanie tekstu, sterowanie interfejsem — i zastępuje ręczne testy. Przegląd to analiza samego kodu: prostota, utrzymywalność, poprawność implementacji. Uwagi z obu etapów wracają do wykonawcy (już uproszczoną ścieżką) z limitem ponowień.
Jak stosować: Daj otoczce narzędzia do sterowania aplikacją (automatyzacja UI, API) i skaluj głębokość przeglądu do złożoności implementacji. Scalanie do stagingu tylko przy zielonym CI i pozytywnym przeglądzie.
Na co uważać: Bez limitu ponowień fabryka zapętli się w nieskończoność na jednym zgłoszeniu; a pominięcie któregoś z dwóch etapów przepuszcza inną klasę błędów.
8.Zależności i rezerwacje: fundament równoległości
Na czym polega: Przy dzieleniu epiku fabryka mapuje zależności etykietami w GitHubie — co można załatwić równolegle, a co wymaga kolejności. Każdy przebieg pętli rezerwuje zgłoszenie etykietą „claim”, żeby równoległe wątki nie wzięły tego samego tematu.
Jak stosować: Zależności opisuj maszynowo (etykiety), a nie tylko w dokumencie — pętla ma z nich odczytywać kolejność. Równoległość uruchamiaj tam, gdzie praca jest naprawdę niezależna.
Na co uważać: Źle zmapowane zależności to konflikty i scalanie zmian w złej kolejności; kosztują więcej niż sam zysk z równoległości.
9.Postaw nadzorcę z widokiem na całość
Na czym polega: Pojedynczy przebieg pętli nie wie, co robią pozostałe: czy zmieniają się zależności, czy któreś zgłoszenie utknęło na limicie ponowień. Agent-menedżer (u autora: uruchamiany co 2–3 godziny) patrzy na wszystko z lotu ptaka — może przekierować zgłoszenia, przejąć utknięty przepływ i go dokończyć albo zaalarmować człowieka.
Jak stosować: Wydziel osobnego agenta z dostępem do statusów wszystkich przebiegów i progiem alarmowym. Alerty odbieraj w swoim głównym asystencie (u autora: agent „drugi mózg” w Claude Code).
Na co uważać: To nadzorca, a nie zwolnienie z odpowiedzialności — od czasu do czasu trzeba będzie wejść i uratować przepływ ręcznie.
10.Człowiek wraca na stagingu — uwagi w paczkach
Na czym polega: Zamiast wprost na produkcję (jak w ciemnej fabryce), wszystko trafia na staging, gdzie człowiek sam weryfikuje, czy zbudowano to, co chciał. Uwagi zgłasza jako zwykłe issues — fabryka sama je podejmuje i przerabia. Dopiero gdy paczka funkcji „siedzi”, wchodzi produkcja i kolejne wydanie.
Jak stosować: Testuj całe partie naraz i oddawaj uwagi zbiorczo (4–5 zgłoszeń), zamiast komentować pojedyncze zmiany — to częściowo rozwiązuje wąskie gardło ludzkiego przeglądu na końcu.
Na co uważać: Pominięcie etapu staging i własnej weryfikacji znów czyni z tego ciemną fabrykę — ze wszystkimi jej wadami.
Redakcyjne tłumaczenie
Koniec marzenia o ciemnej fabryce
„Ciemna fabryka” to najbardziej autonomiczna forma inżynierii agentowej. Wrzucamy do niej dokument wysokiego poziomu — epik albo opis wydania — a ona sama wymyśla, jak wszystko zbudować i sprawdzić, po czym wysyła prosto na produkcję. Gdyby dało się na czymś takim polegać, byłby to wymarzony sposób tworzenia każdego oprogramowania. Ale — mówiąc nieco teatralnie dla efektu — moje marzenie właśnie się rozbiło. Eksperymentując z własną ciemną fabryką, doszedłem do wniosku, że po prostu tak się tego nie robi. Natomiast to, na co zamieniłem ten pomysł i co u mnie realnie działa, wcale nie odbiega daleko od pierwotnej idei. Autonomii nie tracę aż tak dużo — i o tym właśnie chcę opowiedzieć. Droga do obecnego punktu była fascynująca i nazbierałem mnóstwo lekcji: o tym, dlaczego ciemna fabryka nie działa i dlaczego to, co buduję teraz, działa.
(Informacja dodatkowa: „ciemna fabryka” (ang. dark factory) to pojęczenie z przemysłu — tak nazywa się zakład działający całkowicie bezobsługowo, „przy zgaszonych światłach”. W kontekście AI oznacza proces developmentu bez udziału człowieka.)
Zastrzegam od razu: ciemna fabryka nie zadziałałaby nawet przy AGI i najlepszych modelach świata. Potrzebny jest system raczej o kształcie, który zaraz pokażę. Wiem, że wygląda skomplikowanie, ale rozbiorę go na proste elementy. Warto zrozumieć ten rodzaj przepływu, bo — powiedzmy sobie szczerze — sposób, w jaki pracujemy z agentami kodującymi, zmieni się już w ciągu najbliższych sześciu miesięcy. Im lepsze stają się modele i ich otoczki, tym więcej samodzielności musimy im oddawać, jeśli wdrażanie ma być szybsze. Jestem przekonany, że w ciągu najbliższych lat każda osoba i każda firma zmierzy do systemu o takim kształcie. A nawet jeśli nie zamierzasz dziś stawiać pełnej fabryki software’owej AI — tak, to co innego niż ciemna fabryka — warto zobaczyć cały proces. Wplecione są w niego lekcje, które przeniesiesz do zwykłej, codziennej pracy z agentami. Tak zresztą wygląda konwergencja całej branży: współpracując z firmami i rozmawiając z ludźmi budującymi własne systemy, widzę, że wszystkie z czasem robią się coraz bardziej podobne. To przyszłość i kolejny krok inżynierii agentowej.
Dlaczego ciemna fabryka nie działa
Zanim przejdę dalej, muszę wyjaśnić, dlaczego ciemna fabryka zawodzi — choć bardzo bym chciał, żeby było odwrotnie. Cel jest prosty: maksymalna samodzielność agentów kodujących. To nie jest vibe coding, bo ogromny wysiłek inżynierski wkładamy z góry w harness — otoczkę, czyli rusztowanie reguł i narzędzi, w którym pracuje agent. W trakcie wykonania ufamy mu, ale tylko dlatego, że wcześniej zgotowaliśmy mu grunt: z dokładnością definiujemy proces, przez który przechodzi, budując oprogramowanie.
Swoją fabrykę zacząłem mniej więcej na początku roku jako publiczny eksperyment. Obserwowanie jej w akcji przypomina patrzenie na schnącą farbę — czekamy, aż przebiegi zmielą pracę. Cały wysiłek i tak idzie z góry w otoczkę, i to właśnie ją pokazywałem w filmach i transmisjach na żywo. Była to świetna zabawa i fabryka wyszła całkiem udana. Główną inspiracją był dla mnie wpis Dana Shapiro o pięciu poziomach autonomii w kodowaniu z AI. Większość z nas funkcjonuje na co dzień na poziomie trzecim, może czwartym; piąty — ciemna fabryka software’owa — to ostateczna forma samodzielności. Shapiro posługuje się analogią samochodową: w ciemnej fabryce nie ma nawet kierownicy. Podajesz punkt docelowy — czyli to, co chcesz zbudować — ale nic nie mówisz o trasie. I brzmi to jak marzenie: „Hej Claude, hej Codex, oto wielka aplikacja do zbudowania. Zróbcie ją, nie stójcie, dopóki nie skończycie — i ani jednego błędu”. No, mniej więcej tak to brzmi. Teoretycznie wydawałoby się, że wraz z ulepszaniem się modeli ten poziom kiedyś stanie się praktyczny. Tylko że jest z tym jeden duży problem.
Wąskie gardło: nasza intencja
Problem dotyczy dokładnie tego, o czym opowiadałem w poprzednim odcinku. Lepsze modele coraz sprawniej budują oprogramowanie, ale nie stają się proporcjonalnie lepsze w rozumieniu nas samych i naszych zamiarów. Wąskim gardłem staje się uzyskanie tego, czego faktycznie chcemy — bo ludzie nigdy nie zakomunikują idealnie ani funkcji, które chcą mieć, ani tego, jak baza kodu ma być utrzymywana. Wiem, że brzmi to banalnie, ale ciemna fabryka jest wadliwa u samych fundamentów: modele mogą być potężne, jak chcą, i tak nie nauczą się czytać nam w myślach.
Słyszałem też argument — przyznaję, intrygujący — że modele staną się tak dobre, iż ich pomysły i intencje przewyższą nasze, więc całkowicie oddamy im rozwój oprogramowania. Ja w to po prostu nie wierzę. Zawsze będziemy musieli trzymać kierownicę, bo niezależnie od siły modeli to my najlepiej znamy problemy, nad którymi pracujemy, i potrzeby naszych klientów. A żeby naprawdę utrzymać kierownicę, musimy też zostać przy utrzymywaniu bazy kodu. Nie możemy z kodu całkiem zniknąć — agenty bowiem w dziwny sposób opiekują się bazą: struktura im się rozłazi.
Lekcja Dexa Horthy’ego: utrzymywalność
To zresztą główna teza Dexa Horthy’ego, który kilka miesięcy temu wygłosił bardzo popularny wykład o tym, dlaczego fabryki software’owe zawodzą. Agenty nie potrafią utrzymywać bazy kodu tak, jak robią to ludzie — więc nadal musimy uczestniczyć w tym procesie. Dex przeszedł zresztą tę samą drogę co ja: zaczął od ciemnej fabryki i musiał nieco cofnąć, dodając więcej człowieka w pętli, żeby całość była realistyczna. Kiedy mówi „fabryki software’owe zawodzą”, mam wrażenie, że ma na myśli to, co ja nazywam ciemną fabryką — czyli właśnie system, który nie działa. Wziąłem wszystkie te lekcje — to ważny wstęp — i przelałem je do rozwiązania, które mam dziś, a które sprawdza się u mnie znakomicie. Sedno: jak utrzymać człowieka w procesie przy zachowaniu maksymalnej samodzielności maszyny; jak nadal pomagać w utrzymywaniu kodu; jak pilnować, żeby agenty nie zbłądziły, mieliąc kolejne zgłoszenia. Wszystko to jest wbudowane.
Fabryka software’owa zamiast ciemnej fabryki
Między fabryką software’ową a ciemną fabryką jest jedna duża różnica. Nie chcę przesadnie przywiązywać wagi do definicji, ale tutaj widzę naprawdę istotne rozróżnienie. Pokażę je na uproszczonym obrazie mojej fabryki, a potem wejdę w szczegóły, żeby było widać, gdzie wbudowano niezawodność i udział człowieka.
Różnica — poza oczywistym człowiekiem w pętli, do którego wrócę na końcu — dotyczy zakresu pracy wpuszczanego do systemu i tego, ile planowania robimy wspólnie z agentem. W ciemnej fabryce jesteśmy maksymalnie z boku: tworzymy jeden ogólny dokument opisujący wielką aplikację i oczekujemy, że fabryka rozbije go na zgłoszenia i ogarnie je po kolei albo częściowo równolegle. Sedno w tym, że od momentu przekazania ogólnego opisu wszystko dzieje się bez nas. Pozwalaliśmy nawet agentowi domyślać się fragmentów naszej intencji — a to jest dokładnie ów problem: nie chcemy, by agent zgadywał, czego chcemy, nawet przy bardzo zdolnym modelu.
W fabryce software’owej podajemy systemowi pojedyncze wydania. Nadal pozwalamy mu samodzielnie przemielić całą masę zgłoszeń, ale zamiast „zbuduj wszystko, start” najpierw wspólnie ustalamy: jaki jest następny zakres pracy i jak pociąć go na zgłoszenia — a dopiero potem fabryka bierze temat i działa autonomicznie. Sama pętla pozostała ta sama: sposób, w jaki obsługuję pojedyncze zgłoszenie z GitHuba czy zadanie z Jiry, z bardzo podobnym budowaniem i walidacją — zgłoszenie jako wejście, pull request jako wyjście. To, co się zmieniło, dzieje się przede wszystkim przed pętlą i po niej — i to czyni fabrykę niezawodniejszą, a człowieka zostawia w grze.
Przy okazji: zostanę na poziomie ogólnym. Spędziłem nad tym systemem setki godzin budowania i testowania; mógłbym wejść w najdrobniejsze detale, ale wolę zainspirować was procesem i pokazać, co realnie działa w branży. Jeśli chcesz, żebym któryś element omówił w osobnym filmie — daj znać w komentarzach.
Sekcja sponsorska: Port
Wielkie podziękowania dla Port za wsparcie tego odcinka. To platforma, która pomaga zespołom prowadzić własną fabrykę software’ową AI. Bo sprawa wygląda tak: wszystko, co pokazuję, działa dla prawdziwych zespołów inżynierskich — sam to zbudowałem. Ale gdy zaczynasz wdrażać fabryki w organizacji z setkami usług i wieloma zespołami, gdzie ludzie i agenty otwierają mnóstwo pull requestów, potrzebujesz czegoś do ogarnięcia tego wszystkiego — w istocie zarządzanej fabryki. Twoje agenty muszą wiedzieć, kto za co odpowiada i jakie obowiązują standardy, a ty musisz na bieżąco widzieć, co agenty dostarczają. I tu wchodzi Port: spina całe środowisko w jednym miejscu, które nazywa „jeziorem kontekstu” — usługi, właścicieli, dokumentację i standardy w jednym katalogu. Można też podpiąć agentów przez serwer MCP (Model Context Protocol) Portu; w Claude Code zrobiłem to jedną komendą. Od razu mój agent może odpytać o wszystkie moje fabryki, sprawdzić, kto czym się zajmuje, pobrać kontekst o gotowości danego wątku i o tym, które testy nie przechodzą — fabryki zawsze przecież sprawdzamy względem jakiegoś standardu. A ponieważ każdy pull request trafia do katalogu, mogę pytać agenta o statystyki: ile PR-ów scala w miesiącu każda fabryka, ile średnio trwają przebiegi. Takie dane są bezcenne, gdy chcesz fabryki z czasem ulepszać. Da się też ustawić uprawnienia — mój podpięty agent ma wyłącznie dostęp do odczytu. Port jest darmowy do piętnastu miejsc, bez podawania karty, i można go wypróbować na własnych repozytoriach; link w opisie.
Krok pierwszy: planowanie wydania — celowo poza fabryką
Zanim ruszy pętla główna, mamy dwa kroki: planujemy większy obszar pracy na najbliższe wydanie, a potem dzielimy go na zgłoszenia — porcje, z których każda przejdzie przez pełną pętlę.
Pierwszy krok, planowanie, celowo zostawiłem poza fabryką. Nic w otoczce nie będzie Cię przez niego prowadzić, bo zakładam, że masz już własny sposób planowania z agentem — mam go ja, ma niemal każda firma, z którą pracuję. Nie chcę tego wymuszać wewnątrz fabryki; planowania chcę dotykać osobiście i w całości. Tworzysz więc PRD, dokument architektury — cokolwiek robisz na co dzień — i to staje się wejściem do systemu. Planujemy kolejne wydanie.
Sedno różnicy wobec ciemnej fabryki: nie próbujemy zbudować całej aplikacji na raz. W projekcie od zera („greenfield”) pierwszym wydaniem ma być po prostu dowód koncepcji, który fabryka zbuduje. W projekcie na istniejącym kodzie („brownfield”) — bo fabryka świetnie działa też nałożona na żywą bazę — definiujesz po prostu mały epik.
(Informacja dodatkowa: epik — w metodykach zwinnych duży pakiet pracy, który tnie się na mniejsze zgłoszenia lub zadania; termin znany m.in. z Jiry.)
Wiem, że „mały” epik to pojęcie gumowe — każda organizacja inaczej tnie pracę na epiki i wydania, i to naprawdę zależy od Was. Moja szacunkowa reguła: epik powinien rozpaść się na 10–20 zgłoszeń. Wiem, że to szeroki przedział — każde zgłoszenie będzie miało inną wielkość — ale lepiej ocenić nie umiem. Z czasem, pracując z fabryką, sam wyrobisz sobie wyczucie rozmiaru, który u Ciebie działa. Ważne, by epik opisywał i to, co budujemy, i to, czego konkretnie nie budujemy. Sekcja „poza zakresem” bardzo pomaga fabryce trzymać kurs, gdy mieli kolejne zgłoszenia.
Scenariusze holdout: testy, których wykonawca nie zna
Druga rzecz definiowana z góry — charakterystyczna dla fabryki, ale użyteczna w każdej pracy z agentami kodującymi — to scenariusze holdout. Zasada prosta: to testy, które uruchomimy po zakończeniu implementacji, ale agent-wykonawca nie wie, jakie są. Informację celowo przed nim ukrywamy — dzięki temu nie ma stronniczości: nie może dopasować implementacji tak, żeby przechodziły nasze scenariusze. To bardzo podniosło niezawodność mojej fabryki, bo agenty są z natury ugodowe: jeśli znają scenariusze testowe, spróbują dobrać implementację właśnie pod nie. Często oprogramowanie nie jest wtedy naprawdę dobre — jest dobre wyłącznie dla tych testów. Dlatego wykonawca nie może wiedzieć, co go czeka.
Całość — zakres, wyłączenia, holdouty — ląduje w dokumencie: tworzysz swój zwykły PRD czy dokument architektury, a fabryka pomaga Ci go pociąć na zgłoszenia. Przy okazji robi mapowanie zależności: co da się załatwić równolegle, co na co czeka — żeby przebiegi wykonywały się we właściwej kolejności. Fabryka ustawia to wszystko etykietami w GitHubie i tak przygotowuje pętlę główną do sukcesu.
Ile człowieka w pętli? Tyle, ile wymaga wydanie
Tu nie ma sztywnego udziału człowieka. W mojej fabryce to raczej zestaw przełączników: mogę przeglądać PR-y przed scaleniem do stagingu albo nie; mogę sprawdzać podział na zgłoszenia przed startem budowania albo nie. Każdy ma inne potrzeby, a dużo zależy od złożoności konkretnego wydania. Bywa wydanie z wymogami regulacyjnymi i compliance, gdzie wszystko musi grać — wtedy chcę przejrzeć i podział, i końcowe PR-y, a mimo to system sam mieli zgłoszenia, gdy już je utworzę. Bywa i tak, że po prostu sprzątamy duży backlog błędów — wtedy mogę spokojnie zaufać: niech sam dzieli na zgłoszenia i scala prosto do środowiska stagingowego. Potrzeby są dynamiczne i udział człowieka nie zawsze musi siedzieć w tym samym miejscu — dlatego zbudowałem fabrykę bardzo elastyczną.
Uwierzcie, że chętnie pokazałbym ją w akcji: przebiegi, plany, podziały, listy zgłoszeń. Nagrałem taką wersję odcinka i zrobiła się potwornie długa — więc na razie zostaję przy dużym obrazie, a szczegółom poświęcę osobne filmy. Sedno: po planowaniu i podziale mamy listę zgłoszeń w GitHubie, które po prostu przemielimy pętlą główną, robiącą całe planowanie i walidację.
Pętla główna: od zgłoszenia do pull requesta
Zbliżmy się. Punkt startu: zgłoszenie z GitHuba. Wiele przebiegów może działać równolegle, bo znamy zależności — wiemy, co da się załatwić jednocześnie. Każde przejście wybiera jedno zgłoszenie i od razu znaczy je etykietą rezerwacji („claim”), żeby żaden równoległy wątek go nie porwał. Potem podejmowana jest decyzja na starcie. Zauważyłem bowiem już w pierwszej wersji, nawet tej ciemnej, że gdy każdy temat szedł przez kompleksowy przepływ, trafiały się trywialne zgłoszenia na 20–30 minut, którym cały ten rytuał był zbędny. Teraz o tym, czy mamy prosty temat (krótsza ścieżka budowania), czy złożony (z etapami iteracji), decyduje z góry Jev — i nie ma znaczenia, którą drogą poszło budowanie, bo na końcu i tak czeka walidacja oraz przegląd kodu, przy czym te etapy również wiedzą, ile mogą poświęcić czasu zależnie od złożoności implementacji.
Bo przegląd i walidacja to dwie różne rzeczy. Walidacja: w ramach otoczki daję agentowi narzędzia do testowania aplikacji tak, jak zrobiłby to użytkownik — klika przyciski, wpisuje tekst w pola, cokolwiek dotyczy danej aplikacji. Zastępuje to dużą część mojego ręcznego testowania — o to przecież chodzi, by było autonomicznie. Potem przegląd kodu: skoro wiemy, że aplikacja działa, sprawdzamy, czy kod jest prosty i utrzymywalny, czy implementacja jest poprawna — klasyczne decyzje inżynierskie, klasyczny code review. Wszystko, co którykolwiek z etapów uzna za błędne, wraca do wykonawcy z poprawkami — i nawet po złożonej implementacji poprawki idą już prostą ścieżką. Oczywiście są limity ponowień, żeby fabryka nie wpadła w nieskończoną pętlę. Gdy przeglądy i ewentualne iteracje się skończą, pull request może zostać scalony do gałęzi wchodzącej do środowiska stagingowego — i to wyłącznie, gdy CI (ciągła integracja) przechodzi na zielono, a skontrolowany kod jest dobry.
Agent-menedżer i chroniony kontekst
Nad całym procesem czuwa agent-menedżer, uruchamiany okresowo — u mnie co dwie, trzy godziny — który przegląda powodzenie wszystkich przebiegów łącznie. To najnowszy element fabryki. Zanim go dodałem, agenty w ogóle się ze sobą nie komunikowały: pojedyncze przejście nie wiedziało, że zależności się zmieniają albo że jakiś pull request kompletnie utknął — na przykład że osiągnięto limit ponowień i agent faktycznie nie daje rady. Potrzebny był byt, który patrzy na cały proces i może na nowo poukładać zgłoszenia albo przejąć czyjś przepływ i go dokończyć. To bardzo podniosło niezawodność — także dlatego, że ustawiłem go tak, by alarmował mnie, kiedy naprawdę muszę wejść do systemu. Bo choć chcemy autonomii, to nie jest już ciemna fabryka: godzimy się, że od czasu do czasu trzeba będzie przejrzeć podział albo uratować przepływ. Zdarza się. Zwykle, gdy menedżer alarmuje, pomaga mi mój główny agent w Claude Code — mój „drugi mózg”.
W walidacji aplikacji wchodzą, rzecz jasna, scenariusze holdout. Częścią fabryki jest też kontekst rdzeniowy — nazywam go mission.md albo engineering.md. Mieszczę tam rzeczy poza zakresem, których nigdy nie chcę budować, oraz ogólny kierunek, w jak agent ma działać w mojej bazie; do tego dochodzą reguły globalne. I dbam o to, żeby fabryka nigdy nie edytowała tych plików — to element mojego przeglądu: nie chcę, by mogła zmieniać własne uprawnienia i zachowanie.
Ostatnia rzecz: w każdym z tych węzłów używam różnych modeli, a nawet różnych dostawców, bo fabrykę zrobiłem bardzo oszczędną pod względem tokenów. Nie wszędzie potrzebujemy maksimum rozumowania. Do sporej części planowania używam Opusa 5.5 albo GPT-6 Astra; ale w wielu pojedynczych węzłach wystarczy mniej — Jev wybiera zadanie, a do prostych tematów idzie po prostu Sonnet 5.5. Nawet przy samym wdrażaniu tych węzłów nie potrzebuję najlepszego modelu. Dużo w tym kierunku eksperymentowałem — tygodniowo mielę setki przebiegów i nie zbliżam się do limitów.
Człowiek wraca: staging, zbiorcze uwagi, produkcja
Ostatnia część procesu to moment, w którym wracamy, żeby przejrzeć wyniki. W pętli głównej budujemy wszystkie zgłoszenia epika i scalamy je do środowiska stagingowego. I to tutaj sprawdzamy wszystko sami — potrzebujemy bowiem kroku weryfikacji własnej intencji. Testujemy osobiście, a jeśli coś jest nie tak — coś nie zostało zbudowane tak, jak naprawdę chcieliśmy — wystarczy założyć w repozytorium nowe zgłoszenie, a fabryka podchwyci je automatycznie, dokładnie tak samo jak przy pierwotnym podziale epika. Testowanie całej paczki funkcji i oddawanie uwag zbiorczo robi się dzięki temu proste: tworzysz cztery, pięć zgłoszeń — ile trzeba — fabryka je przemieli, a ty znów testujesz staging. Kiedy jest dobrze, wdrażamy na produkcję.
Ciemna fabryka szła praktycznie od razu na produkcję; w fabryce software’owej przekonałem się, że ten dodatkowy etap ma kluczowe znaczenie. Zyskujemy prawdziwego człowieka w pętli, a jednocześnie przeglądamy wiele naraz — więc przynajmniej częściowo rozwiązujemy wąskie gardło ludzkiego przeglądu na końcu. Gdy jesteśmy zadowoleni z tego, co trafiło na produkcję, po prostu przechodzimy do następnego wydania i powtarzamy: planowanie, pętla główna, staging, produkcja. I to tyle — taka w dużym skrócie jest fabryka software’owa AI.
Jak już mówiłem: dajcie znać, jeśli chcecie, żebym któryś fragment omówił osobno. Mam nadzieję, że wynosicie stąd inspirację — tak dla własnych przepływów kodowania z agentami, jak i do budowy własnej fabryki. To naprawdę przyszłość inżynierii agentowej. Jeśli doceniacie ten odcinek i czekacie na więcej o fabryce i kodowaniu z AI — łapka w górę i subskrypcja bardzo pomagają. Do zobaczenia w następnym odcinku.