O czym jest ten film
- Fabryka oprogramowania AI to najbardziej autonomiczna forma kodowania z pomocą AI: człowiek planuje z agentem wydanie, a podział na zadania, implementację i wdrożenie realizuje zautomatyzowana pętla.
- W skali przedsiębiorstwa sama fabryka nie wystarczy — potrzeba wokół niej warstwy z zabezpieczeniami, kontekstem i pełną widocznością. Autor znalazł ją w platformie Port (materiał powstał we współpracy z firmą).
- Twardym warunkiem autora było zachowanie własnego harnessu — szkieletu sterującego pętlą inżynierską — bez przepisywania go pod platformę.
- Cztery filary tej warstwy: rejestr agentów i umiejętności, jezioro kontekstu, wspólne standardy dla każdej fabryki oraz mechanizmy kontroli pilnujące zgodności z tymi standardami.
- Pętla inżynierska krok po kroku: plan wydania (PRD) → podział na 10–20 ticketów z mapowaniem zależności → dla każdego zadania plan, implementacja i testy „jak użytkownik” → przegląd kodu przez osobnego agenta → scalenie na gałąź stagingową → walidacja całego wydania partią → produkcja.
- Rejestr umiejętności: każdy krok pętli napędza rozbudowana, wersjonowana umiejętność; kluczowe jest utrzymywanie jednej wersji i zarządzanie jej cyklem życia (certyfikacja, publikacja, wycofanie).
- Agenci są traktowani jak role w organizacji (planista, agent dzielący backlog), każda z przypisaną platformą, modelem, uprawnieniami, właścicielem i statusem zatwierdzenia.
- Jezioro kontekstu dostarcza fabryce wiedzy, której nie ma w kodzie: właściciele aplikacji, domeny, poziomy usługi i decyzje, gdzie potrzebna jest zgoda człowieka — z Jiry, Slacka, SharePointa, GitHuba i CI.
- Karta gotowości ocenia dojrzałość repozytorium do autonomii (właściciel, README, szablon PR, zielone CI na głównej gałęzi), a każdy scalony PR sprawdzany jest ponownie — spadek uruchamia przepływ zatwierdzany przez człowieka i fabryka sama naprawia problem.
- Filozofia „człowieka w pętli”: autor celowo odszedł od „ciemnej fabryki” działającej bez żadnego nadzoru i włącza autonomię tylko tam, gdzie standardy na to pozwalają.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zanim zabierzesz się za warstwę zarządczą, dopracuj samą pętlę
Na czym polega: Autor wyraźnie rozdziela dwa etapy dojrzałości: najpierw prosta pętla inżynierska (plan → implementacja → walidacja), dopiero potem infrastruktura zarządcza wokół niej. Fabryka bez pętli to tylko zestaw narzędzi; pętla bez warstwy zarządczej przestaje się skalować przy wielu aplikacjach.
Jak stosować: Jeśli dopiero budujesz fabrykę, trzymaj się samego rdzenia i świadomie odłóż rejestry oraz karty gotowości. Momentem przejścia na wyższy poziom jest ten, w którym prowadzisz więcej niż jedną–dwie fabryki albo tracisz widoczność tego, kto i co zmienił.
Na co uważać: Nadmierna infrastruktura na starcie to najczęstszy sposób utknięcia w konfigurowaniu zamiast w dostarczaniu; ale odwlekanie warstwy zarządczej w dużej skali kończy się fabryką bez nadzoru, którą trudno audytować.
2.Jeden proces, jedna wersja — rejestr umiejętności zamiast kopiowania
Na czym polega: Każdy krok pętli (planowanie, implementacja, testy, przegląd kodu) napędza rozbudowana „umiejętność” — dopracowana definicja procesu, a nie kilka linijek promptu. Gdy umiejętności rozjeżdżają się między fabrykami, przestajesz mieć pewność, że wszystkie fabryki robią to samo i w ten sam sposób.
Jak stosować: Trzymaj umiejętności w centralnym rejestrze z wersjonowaniem i właścicielem; zmiany publikuj i rozprowadzaj jedną wersję do wszystkich fabryk. Liczbę różnych wersji tej samej umiejętności traktuj jak wskaźnik zadłużenia — powinna być jak najniższa, najlepiej równa jeden.
Na co uważać: Wersje rozjeżdżają się niezauważalnie, bo każda fabryka „dorabia” lokalne poprawki. Zaplanuj cykl życia (certyfikacja, publikacja, odrzucanie, wycofywanie), zanim rejestr zamieni się w muzeum starych wariantów.
3.Traktuj agentów jak role organizacyjne, nie jak narzędzia
Na czym polega: W fabryce autor wyodrębnia role — planistę budującego plan wydania, agenta dzielącego go na tickety — a każda ma przypisaną platformę (np. Claude Code, Codex), model, uprawnienia i status zatwierdzenia. To dokładnie ten sam sposób, w jaki opisuje się stanowiska w zespole.
Jak stosować: Prowadź rejestr agentów z metadanymi: czym dany agent się zajmuje, na jakiej platformie działa, co wolno mu dotykać, kto jest właścicielem i czy zmiany wymagają aprobaty. Nową fabrykę projektuj od zestawu ról, a nie od pojedynczego „agenta do wszystkiego”.
Na co uważać: Przypisanie uprawnień do ról jest równie ważne jak u ludzi: agent z nadmiernymi uprawnieniami może scalać i wdrażać zmiany, których nikt nie zamierzał zatwierdzić.
4.Daj agentom własne tożsamości, a nie pożyczone konta
Na czym polega: Gdy agenci działają na pożyczonych credentialach programisty — choćby jego koncie GitHub — po awarii na produkcji nie da się ustalić, czy odpowiada za nią człowiek, czy jego agent. W skali przedsiębiorstwa to podważa rozliczalność całego procesu.
Jak stosować: Przypisuj agentom odrębne tożsamości i rejestruj właścicieli komponentów. Przy analizie incydentu sprawdzaj, czyja tożsamość — ludzka czy agentowa — stoi za danym commitem.
Na co uważać: Rozliczalność działa tylko przy konsekwencji: jeden agent uruchomiony „na szybko” na prywatnym koncie psuje całość historii audytu.
5.Proces nie zna biznesu — zbuduj jezioro kontekstu
Na czym polega: Pętla inżynierska (agenci plus umiejętności z rejestru) to wyłącznie proces. O powodzeniu fabryki decyduje jednak wiedza, której w kodzie nie ma: kto jest właścicielem aplikacji, do jakiej domeny należy, jak szeroki byłby zasięg szkód przy błędzie, czy scalenie wymaga zgody człowieka.
Jak stosować: Podłącz fabrykę do źródeł, w których ta wiedza żyje — GitHub, CI, Jira, Slack, SharePoint — i trzymaj ją w jednej, wspólnej warstwie kontekstu, z której korzystają wszystkie fabryki.
Na co uważać: Nie wszystko da się wywnioskować z repozytorium. Decyzje o poziomie autonomii scalania podejmuj na podstawie metadanych biznesowych (poziom usługi, domena, właściciel), a nie domysłów.
6.Niech plan wydania powstaje na danych z jeziora kontekstu
Na czym polega: Zanim plan trafi do fabryki, autor rozmawia z agentem o wydaniu — a agent przez serwer MCP pobiera z jeziora kontekstu fakty: właścicieli repozytoriów, szablony startowe, poziom gotowości repo. Dokument wymagań (PRD) powstaje więc na fundamencie danych, nie pamięci.
Jak stosować: W fazie planowania podłączaj agenta do rejestru kontekstu przez MCP i wymagaj, by przed spisaniem planu wskazał właścicieli, szablon i dojrzałość repo.
Na co uważać: Plan napisany w próżni generuje tickety, które fabryka potem bezowocnie odrabia — to najdroższy moment na oszczędzanie kontekstu.
7.Wprowadź kartę gotowości repozytorium do autonomii
Na czym polega: Zanim włączysz pełną automatyzację, przechodzi się listę warunków: czy repo ma właściciela, README, szablon PR, skonfigurowane CI i czy CI przechodzi na głównej gałęzi. Autor używa poziomów brąz–srebro–złoto i dopiero „złoto” oznacza gotowość.
Jak stosować: Dla każdego repo, które ma stać się fabryką, przechodź taką listę kontrolną; niezaliczone punkty traktuj jako listę zadań do odhaczenia przed włączeniem samodzielności.
Na co uważać: Zewnętrzna platforma sprawdzi tylko warunki ogólne — własna pętla może wnosić dodatkowe wymogi (np. konkretne testy), więc listę trzeba samodzielnie uzupełnić.
8.Standardy muszą być żywe: oceniaj każdy scalony PR
Na czym polega: Karta gotowości nie jest jednorazowym egzaminem — platforma ocenia każde scalenie na nowo. W demonstracji celowo zepsute CI natychmiast degraduje repo ze złota na srebro, uruchamia przepływ, który (po aprobacie człowieka) zakłada zgłoszenie, a fabryka w kolejnym obiegu sama naprawia CI — i repo wraca do złota.
Jak stosować: Spraw, by spadek standardów kończył się automatycznym zgłoszeniem do fabryki z szybką aprobatą człowieka. Repozytorium staje się wtedy samonaprawiające się.
Na co uważać: Samonaprawianie działa tylko wtedy, gdy zielone CI rzeczywiście dowodzi zdrowia aplikacji; niestabilne testy (tzw. flaky) będą generować fałszywe alarmy i wypalać zaufanie do mechanizmu.
9.Testuj wydanie partią na stagingu i iteruj przez zgłoszenia
Na czym polega: Pojedynczy ticket przechodzi pełny cykl — plan, implementacja, testy tak, jak zrobiłby je użytkownik, przegląd kodu przez osobnego agenta, CI — ale scalanie idzie na gałąź wdrażaną na staging i dopiero tam całe wydanie sprawdza się naraz. Uwagi wracają do fabryki jako nowe zgłoszenia.
Jak stosować: Nie łącz z produkcją wprost z pętli. Zbieraj cały release na stagingu, testuj jak użytkownik, a znalezione braki zgłaszaj jako tickety — zwykle wystarczą dwie–trzy iteracje.
Na co uważać: Pętla musi uwzględniać mapowanie zależności między zadaniami, inaczej równoległe obiegi będą się wzajemnie blokować lub nadpisywać.
10.Autonomia w granicach rozsądku, nie „ciemna fabryka”
Na czym polega: Pierwsza wersja fabryki autora działała bez żadnego udziału człowieka: bez planowania, bez stagingu, wdrażała prosto na produkcję i mogła modyfikować własny szkielet sterujący. Celowo od tego odszedł: punkty kontroli (właściciele, planowanie, aprobaty) są wbudowane od początku, a usuwa się je dopiero tam, gdzie to bezpieczne.
Jak stosować: Wbuduj nadzór tam, gdzie koszt błędu jest wysoki (scalanie, zmiany CI, sam szkielet sterujący), a po nabraniu zaufania rozluźniaj wybrane punkty.
Na co uważać: Pełna automacja bez widoczności brzmi kusząco, ale oznacza, że nie wiesz, czym właściwie zarządzasz. Skracanie pętli aprobat ma sens tylko przy dojrzałych standardach.
Redakcyjne tłumaczenie
Dlaczego sama fabryka to za mało
Fabryka oprogramowania AI to mój zdecydowanie największy projekt — poświęciłem jej w tym roku setki godzin. Zaszło już tak daleko, że pomagam firmom wdrażać podobne systemy: nie po to, żeby zastępować całą ich inżynierię, lecz żeby wybrane zespoły i wybrane aplikacje pracowały w trybie fabryki. I właśnie przy tych wdrożeniach stało się dla mnie jasne, że fabryka sama w sobie nie wystarczy. Na poziomie przedsiębiorstwa albo po prostu przy dużej liczbie aplikacji potrzebne jest coś w rodzaju otoczki, która zapewni jej zabezpieczenia, kontekst i pełną widoczność tego, co się w niej dzieje.
Fabryka oprogramowania AI to najbardziej autonomiczna forma kodowania z pomocą AI, jaka istnieje. Człowiek pozostaje w pętli na etapie, w którym komunikujemy, czego chcemy: wspólnie z agentem planujemy wydanie, a dopiero potem plan trafia do harnessu — szkieletu wykonawczego, który rozbija go na zadania i realizuje je w pętli. To nie jest czarna skrzynka, bo ten szkielet sami projektujemy i kontrolujemy. Gdy jednak fabryka naprawdę się rozrośnie, właśnie on potrzebuje wsparcia w ogarnięciu całości.
(Informacja dodatkowa: „harness” — dosłownie „uprząż” — w inżynierii oprogramowania oznacza oprzyrządowanie przeprowadzające zadania przez kolejne etapy; tu: zautomatyzowany proces programistyczny, w którym człowiek nadzoruje punkty decyzyjne.)
Szukam opakowania, które nie zmusi mnie do przepisywania fabryki
Taką otoczkę mógłbem zbudować sam. Ale sprawa jest, jak zaraz zobaczysz, znacznie bardziej złożona, niż wygląda na pierwszy rzut oka — a ja nie chcę skupiać się na tej części. Wolę pracować nad samą pętlą inżynierską, w której dzieje się rzeczywisty rozwój. Dlatego przez ostatni czas szukałem wszędzie platformy, która da mi tę warstwę, a przy tym pozwoli prowadzić własny szkielet wykonawczy. I znalazłem dokładnie to, czego szukałem: Port.
Port daje mi warstwę kontekstu, widoczności i zabezpieczeń ponad moimi fabrykami. Bezpośrednio integruje się z pull requestami, obserwuje wszystko, pokazuje przegląd kondycji repozytorium — i wiele więcej, co zaraz zobaczysz. A ja przez cały czas wciąż prowadzę swoją fabrykę. Pokażę, jak to wszystko działa — nie jako podręcznik obsługi Portu, ale jako opis pojęć, które zaczynają naprawdę mieć znaczenie, gdy fabryk jest wiele: kto odpowiada za które komponenty i jak zbudować jedną, centralną warstwę kontekstu dla wszystkich fabryk naraz.
Dla mnie to był twardy warunek: po pracy włożonej w szkielet wykonawczy nie zamierzam go przepisywać pod platformę. Architekturę, którą pokazałem w jednym z poprzednich filmów (odsyłam do niego w materiale źródłowym), stosuję w niezmienionej postaci. Port dokładnie dołącza do niej opakowanie — i to załatwia cztery rzeczy, o których rozmawiamy dzisiaj: rejestr agentów i umiejętności, jezioro kontekstu, standardy wspólne dla każdej fabryki oraz mechanizmy kontroli, które pilnują, by każda fabryka trzymała się tych standardów w miarę ich ewolucji.
Najważniejsze, co możesz stąd wynieść, to nauka od Portu: co naprawdę trzeba mieć, żeby fabryka oprogramowania urosła do skali przedsiębiorstwa i z jakich elementów się składa. Port radzi sobie z tym znakomicie — nie bez powodu z nimi współpracuję i tak bardzo chcę połączyć swoją fabrykę z ich platformą. Oni po prostu robią to dobrze; miałem już rozmowy o tym, jak wkomponować moją fabrykę w Port, i teraz wdrażam ustalenia w życie. Całość traktuj jako źródło inspiracji.
(Informacja dodatkowa: Port to komercyjna platforma typu internal developer portal — wewnętrznego portalu dla zespołów programistycznych; w prezentowanej architekturze pełni rolę warstwy zarządczej wokół fabryk AI.)
Fundament: jak działa pętla inżynierska
Zacznijmy od fundamentu — od samej fabryki, czyli rdzennej pętli inżynierskiej. To przygotuje grunt pod Port i komponenty, które kładę na wierzchu. I od razu jedno zastrzeżenie: jeśli dopiero wdrażasz albo budujesz fabrykę, trzymaj się prostoty i samej pętli. Ale prędzej czy później każdy będzie musiał skalować — i wtedy istotne staną się takie elementy jak rejestr agentów i umiejętności czy wspólne źródło kontekstu. Do tego dojdziemy, lecz najpierw sama pętla.
Fabrykę zawsze zaczynam od zaplanowania kolejnego wydania. W świeżym projekcie to plan dowodu koncepcji; w rozwijanym systemie — plan kolejnego dużego kawałka pracy, kolejnej partii zadań, jakkolwiek to nazwiesz: czegoś, co da się rozbić na 10–20 ticketów. W tym planowaniu bierzemy z agentem bardzo czynny udział — tworzymy na przykład dokument wymagań produktowych (PRD). Forma jest umowna; chodzi o to, żeby do pętli fabryki wchodził konkretny, ustalony kontekst. Agent weźmie ten plan i sam rozbije go na zadania, a przy okazji zmapuje zależności — które obiegi może puścić równolegle, a które muszą poczekać na skończenie innych ticketów.
Każde zadanie z tego podziału przechodzi przez rdzenną pętlę inżynierską, którą u mnie cyklicznie uruchamia zwykłe zadanie cron. W każdym obiegu pętla najpierw wybiera następny ticket — według priorytetów i mapy zależności — a potem przeprowadza go przez pełny cykl „planuj, wdrażaj, sprawdzaj”. Najpierw planuje wokół tego, co ticket opisuje: błędu albo nowej funkcji. Potem implementuje zgodnie z planem. Na końcu następują bardzo gruntowne testy — aplikacja jest weryfikowana dokładnie tak, jak zrobiłby to użytkownik: jaki obrót sprawy użytkownika przechodzimy, żeby nową funkcję sprawdzić. Następnie pętla uruchamia osobnego agenta, który robi przegląd kodu pull requesta. Dopiero gdy wszystkie kontrole CI są zielone, a przegląd wypada pomyślnie, następuje scalenie.
I od razu ważna uwaga: scalenie zwykle nie idzie wprost na produkcję — w fabrykach oprogramowania nie wierzę w taki model. Zmiany trafiają na gałąź, z której wdraża się środowisko stagingowe. Całe wydanie to wiele pętli przechodzących kolejno przez wszystkie tickety, aż wszystko ląduje na stagingu — i dopiero tam weryfikujemy całość partiami. Nie musimy siedzieć nad przeglądem kodu i testami każdego pojedynczego zgłoszenia; sprawdzamy wszystko naraz. Jeśli w którejś funkcji, w czymkolwiek, co mieliśmy zbudować, coś nie gra — wysyłamy to jako nowe zgłoszenia do fabryki. Ona sama podchwytuje nasze uwagi i je realizuje. Zwykle wystarczą dwie–trzy iteracje, a gdy na stagingu wszystko wygląda dobrze — wdrażamy na produkcję.
To był rzut oka na całą pętlę; znacznie więcej szczegółów znajdziesz we wcześniejszym filmie. Skoro już wiesz, jak działa, możemy przejść do problemów, które pojawiają się, gdy fabrykę naprawdę skalujemy i prowadzimy kilka naraz.
Co psuje się przy skali: odpowiedzialność i tożsamości
W Porcie pokażę cztery rdzenne komponenty — żeby zobaczyć, co naprawdę trzeba mieć, żeby fabryka skalowała się dalej (platforma pomaga zresztą w znacznie większej liczbie spraw). Skalowanie fabryki to bowiem mnóstwo dodatkowych zagadnień. Weźmy odpowiedzialność: fabryka pracuje z wieloma agentami, a te często korzystają z naszych pożyczonych credentiali — choćby konta GitHub. Gdy potem coś pada na produkcji i dochodzimy do commita z konkretnego konta, nie wiadomo, czy zrobił to inżynier, czy jego agenci. Dlatego Port przypisuje osobne tożsamości wszystkim agentom pracującym w fabrykach. A skoro mowa o agentach — to prowadzi nas prosto do pierwszego komponentu: rejestru.
Rejestr umiejętności: jeden proces, jedna wersja
Port nazywa siebie harnessem wokół twojej fabryki oprogramowania — warstwą odpowiedzialną za orkiestrację, kontekst, nadzór i pomiar. W moim rozumieniu rejestr to pierwszy wielki element tej układanki. I zacznę od umiejętności, bo mają fundamentalne znaczenie: każdy pojedynczy krok mojej pętli inżynierskiej napędza jakaś umiejętność. Nie mam tu kilku linijek promptu — mam rozbudowaną umiejętność definiującą dokładny proces dla każdego etapu. Cała moja ufność wobec fabryki bierze się stąd, że mnóstwo czasu poświęcam na projektowanie szkieletu, a umiejętności i agenci to jego bardzo duża część.
Rejestr umiejętności daje centralne miejsce na każdą umiejętność używaną w dowolnej z moich fabryk — i pokazuje, ile różnych wersji prowadzę. Ta liczba nie powinna rosnąć, bo oznaczałaby, że umiejętności rozjechały się między fabrykami. Staram się utrzymywać jedną wersję każdej umiejętności i rozprowadzać ją z rejestru.
W środowisku demonstracyjnym widać to jeszcze wyraźniej: przypisywanie właściciela i statusu publikacji, pełen cykl życia umiejętności — ponawianie certyfikacji, wprowadzanie aktualizacji, odrzucanie publikacji, stopniowe wycofywanie przestarzałych wersji. Zarządzanie cyklem życia umiejętności jest równie ważne jak samo ich posiadanie. Dokładnie to samo robimy z agentami.
Rejestr agentów: role, platformy, uprawnienia
Umiejętności to po prostu nasze procesy pracy. Agenci natomiast to role w fabryce. Mamy planistę, który na początku pomaga zbudować wydanie; mamy agenta dzielącego backlog, który bierze plan i rozbija go na tickety. Dla każdego agenta określamy platformę, na której działa — jedną część fabryki poprowadzę Claude Code, inną mogę np. Codex. Określamy model, uprawnienia (czego agent może dotknąć, a czego nie) i status zatwierdzenia. Powstaje rejestr wszystkiego, co napędza szkielet wykonawczy.
Nadal to ja definiuję agentów i umiejętności — dokładnie tak, jak chcę, by moja fabryka działała. Port jedynie pomaga w zarządzaniu i bardzo ułatwia ponowne użycie: przy każdej fabryce sięgam po gotowe elementy z rejestru. W moim koncie jest to zakładka z rejestrem agentów; w środowisku demonstracyjnym widać dodatkowo, jak to wygląda przy większej liczbie platform uruchomieniowych — gdy część fabryki działa np. w GCP Vertex AI albo AWS Bedrock, co jest typową praktyką dużych organizacji. I podobnie jak przy umiejętnościach mamy cykl życia agentów: tworzenie nowych, awansowanie wersji, zmiany uprawnień. W organizacji powinna być osoba, która tym zarządza — z myślą o poszczególnych fabrykach.
Jezioro kontekstu: proces nie zna biznesu
Kolejny komponent — jezioro kontekstu — to prawdopodobnie moja ulubiona część Portu, choć podoba mi się całość. Zauważ bowiem: pętla inżynierska, złożona z agentów i umiejętności pobieranych z rejestru, to naprawdę tylko proces. Z kontekstem biznesowym nie ma nic wspólnego — a bez niego fabrykom trudno zapewnić sukces. Dlatego podłączamy je do repozytoriów GitHub i do CI, ale też do platform typu Jira czy Slack. Wtedy fabryka ma kontekst biznesowy — wie choćby, kto odpowiada za budowane aplikacje i funkcje.
W środowisku demonstracyjnym Port pokazuje bardzo dobry przykład bogatego jeziora kontekstu. Fabryka pracująca nad planem wyższego poziomu, a potem nad pojedynczymi ticketami, potrzebuje mnóstwa informacji, których nie wyczyta z samego kodu. Potrzebuje dodatkowej wiedzy biznesowej — ze Slacka, SharePointa, Jiry. Na przykład: czy przed zatwierdzeniem scalenia wymagana jest zgoda człowieka? Niektóre rzeczy chcesz prowadzić bardziej autonomicznie, inne wymagają większego nadzoru, bo przy błędzie szkody byłyby szerokie. Tego nie zawsze da się ustalić z kodu — zwłaszcza metadanych takich jak poziom usługi czy domena biznesowa. „Ta funkcja dotyczy marketingu, a tu jest właściciel, do którego kierujemy prośbę o zgodę.” Nie chodzi o to, by fabryka pracowała w całkowitej izolacji — ma sama rozpoznawać miejsca, w których potrzebny jest człowiek. Właśnie tym Port pomaga zarządzać przez jezioro kontekstu.
Port ma oczywiście też bardzo bogate dane o samym kodzie — pull requesty, status fabryki, CI. Teraz jednak chcę pokazać raczej kontekst biznesowy, który wciągamy zwłaszcza na początku, przy planowaniu.
Planowanie wydania zasilone kontekstem
Nawet gdy rozmawiam z agentem i ustalam plan, zanim wyślę go do fabryki, korzystam z Portu — właśnie dzięki jezioru kontekstu. Sam prompt nie jest tu istotny: po prostu ustalam z agentem, co chcę zbudować, a serwer MCP Portu pobiera w tle kluczowe informacje z jeziora — właścicieli repozytoriów, szablony do rozpoczęcia pracy, poziom gotowości repo. Kontekstu jest tu mnóstwo, a serwer MCP można dostroić: co pobierasz, czego szukasz, które platformy podłączasz — GitHub, Jira, Slack. Istotne jest to, że po tych zapytaniach agent po prostu lepiej pomaga zaplanować przebieg fabryki i dokładnie to, co będziemy budować.
W ten sposób ustalam właścicieli, zespół fabryki i repozytoria na poziomie brązowym (o poziomach gotowości za chwilę). Wszystko to wchodzi do rozmowy z agentem, wspartej kontekstem z Portu — i tak powstaje PRD. To jest nasz plan i to właśnie on trafia do fabryki.
Dwa dni i dwadzieścia pull requestów: fabryka w praktyce
Przy okazji: nic z tego nie jest teorią. Zbudowałem już wiele aplikacji swoją fabryką i Portem. Dzisiejsze demo — jedna z nich: zespołowa baza wiedzy, centralne miejsce, w którym ludzie szukają odpowiedzi w wielu repozytoriach. Nie jest to najbardziej wyszukana aplikacja, ale zbudowałem ją w zaledwie dwa dni — fabryką z Portem, całkowicie bez mojego udziału po spisaniu PRD. Pod maską to aplikacja RAG: zadaję pytania do centralnej bazy wiedzy, ona przeszukuje całość i podaje cytowania źródeł. Wygląda naprawdę przyzwoicie — a jak na puszczenie maszynerii na dwa dni, robi wrażenie.
(Informacja dodatkowa: RAG, czyli retrieval-augmented generation — technika, w której model odpowiada na podstawie dokumentów pobranych z zewnętrznego źródła wiedzy, cytując je przy okazji.)
A w Porcie mam pełny wgląd we wszystko. Wszystkie utworzone pull requesty — łącznie dwadzieścia dla tego wydania, którego dotyczył PRD — widać wraz ze statusem; można wejść głębiej w szczegóły. I dochodzimy do karty gotowości.
Karta gotowości: czy repozytorium nadaje się do autonomii
Karta gotowości (scorecard) pokazuje, czy repozytorium jest naprawdę przygotowane, by stać się w pełni samodzielną fabryką — i jest to standard, który można nałożyć na każdą fabrykę. W praktyce to test dojrzałości: czy repo jest gotowe na fabrykę, a my na taki poziom autonomii? Port nie sprawdzi wszystkiego, bo pętlę inżynierską wnosi się własną, ale zweryfikuje rzeczy ogólne: czy repo ma zdefiniowanego właściciela (co, jak pamiętamy, jest częścią jeziora kontekstu), czy ma README, szablon PR i workflow CI, oraz czy CI przechodzi na głównej gałęzi. Gdy wszystko jest odhaczone — jesteśmy na złocie i można wprowadzić fabrykę do tego repozytorium.
W pozostałych repo, tych jeszcze nie złotych, zwykle tak właśnie zaczynamy: dostajemy listę rzeczy do załatwienia, zanim będzie można po prostu włączyć samodzielność.
Standardy, które pilnują same siebie
Ten zestaw standardów to jednak nie tylko lista kontrolna na start. Port ocenia według niego każde scalenie pull requesta. Gdy na przykład CI przestaje przechodzić, od razu wiadomo, że trzeba zareagować: pojawia się raport w Porcie, a nawet rusza przepływ (workflow), w którym możemy zatwierdzić reakcję — utworzenie zgłoszenia w fabryce, tak jak przy każdej innej pracy, żeby naprawić problem w samym kodzie.
Przygotowałem demo pokazujące, jak to wygląda; nagrałem je wcześniej, by szybko zaprezentować kartę gotowości i mechanizmy kontroli działające razem — to dwa ostatnie duże komponenty. W Porcie można bowiem budować takie przepływy do zarządzania jeziorem kontekstu, fabrykami — wszystkim. Ten tutaj służy do naprawiania karty gotowości, gdy pojawi się problem.
W nagraniu celowo psuję CI w swoim repozytorium. Port automatycznie to wykrywa, co uruchamia przepływ: proponuje mi (muszę zatwierdzić) utworzenie zgłoszenia, które rozwiąże problem padającego CI. Trochę to wyreżyserowane, bo widać, że commit robię specjalnie, coś by zepsuć. Ale w prawdziwym kodzie CI sypie się nieustannie — zawsze są testy, które kaprysią, i rzeczy pękające przy zmianach. Chcemy, żeby Port to wyłapywał; właśnie to pokazuję. W CI pojawia się więc błąd backendu. Wracam do Portu i proszę: poziom spadł ze złota na srebro — gotowość obniżona, bo CI nie przechodzi. W wykonaniu przepływu widać, że czeka na naszą zgodę: wykrył awarię i komunikuje, że chce utworzyć zgłoszenie w GitHubie, żeby fabryka automatycznie podjęła temat i naprawiła CI. Mamy więc coś w rodzaju samodoskonalenia, prowadzonego za rękę przez Port.
Zatwierdzam — co oznacza automatyczne utworzenie zgłoszenia w GitHubie. Przeskakuję tam: zgłoszenie istnieje, więc następny obieg pętli je podejmie i sam naprawi CI. Przewijam nagranie: pętla już to zrobiła, zmiana jest scalona, CI zielone. Wracam do Portu — z powrotem ze srebra na złoto, bo CI przechodzi.
Czyli autonomia z człowiekiem w pętli, przynajmniej na potrzeby tej szybkiej aprobaty. Poza tym, że zatwierdzamy jednym kliknięciem, wszystko doskonali się samo: fabryka potrafi wykryć padające CI i sama je naprawić. Zwłaszcza gdy twoje CI jest na tyle rozbudowane, że zielony wynik daje ci pewność, iż aplikacja jest zdrowa — to naprawdę ważny dodatek, dzięki któremu repozytorium staje się samonaprawiające.
Człowiek w pętli, czyli pożegnanie z „ciemną fabryką”
Tym sposobem omówiliśmy wszystkie cztery główne części Portu, o których chciałem opowiedzieć — te, które pomagają fabrykom dojrzewać. A najważniejsze w tym wszystkim jest jedno: człowiek w pętli. Głęboko szanuję sposób, w jaki Port wplotł człowieka w całą otoczkę, i w pełni się z nim utożsamiam. Bo gdy zaczynałem budować fabrykę, była to raczej to, co nazywam „ciemną fabryką” — bez żadnego człowieka w pętli. Bez wspólnego planowania z agentem na początku. Bez stagingu: wdrożenia szły prosto na produkcję. Bez pytania o zgodę, gdy coś zmieniała w CI — mogła regulować własny szkielet, dosłownie mogła wszystko, a my nie mieliśmy żadnego wglądu. I celowo od tego odszedłem. Nadal chcę, by proces był jak najbardziej samodzielny, ale w granicach rozsądku: muszą istnieć punkty, w których człowiek uczestniczy. Filozofia Portu przy całej tej otoczce jest taka: budujemy właścicieli, budujemy kontekst — planujemy, otrzymujemy zgodę przy pracy ze standardami, bo człowiek w pętli jest potrzebny — a potem usuwamy go tam, gdzie uznamy to za zasadne. Ale w przeważającej mierze nie będziemy po prostu pracować „z zgaszonym światłem”, jak ja kiedyś w mojej ciemnej fabryce.
(Informacja dodatkowa: „ciemna fabryka” — termin zapożyczony z przemysłu: zakład tak zautomatyzowany, że może działać bez ludzi, a więc także bez włączonego światła.)
Na koniec
Mam nadzieję, że ten materiał był dla ciebie użyteczny — że dał inspirację i pomysły, jak naprawdę skalować fabryki oprogramowania, a Port okaże się dla ciebie dobrą opcją. Dodać wypada, że film powstał we współpracy z Portem; platforma jest darmowa do 15 miejsc, bez podawania karty płatniczej, więc możesz ją od razu wypróbować na swoich repozytoriach (link znajdziesz w opisie filmu). Dzięki Port za współpracę. Jeśli te pomysły wydały ci się wartościowe i chcesz śledzić moje materiały o inżynierii agentowej i rozbudowie fabryki oprogramowania, polubienie i subskrypcja bardzo mi pomogą. Do zobaczenia w następnym filmie.