O czym jest ten film
- Premiera GPT-6 Astra i gorączka wokół AGI — nawet Jensen Huang z Nvidii ogłasza, że ogólna sztuczna inteligencja już nastąpiła; autor podchodzi do tych deklaracji sceptycznie.
- Praktyczne porównanie modeli — benchmarki stawiają Astrę obok Fable 5.1, ale w tygodniowych testach autora Astra wygrywa większość zadań i rzadziej niż Opus 5 wymyśla dziwne założenia.
- Koncepcja fabryki oprogramowania („ciemnej fabryki”): w pełni samodzielne rusztowanie, które z PRD lub zgłoszenia na GitHubie wytwarza zweryfikowany, gotowy do scalenia kod.
- Kompletny samouczek wdrożenia zdalnego — krok po kroku, w przeważającej części przy pomocy agenta kodującego (Claude Code albo Codex).
- Cała fabryka pracuje na GPT-6 Astra uruchomionej przez Codexa.
- Współpraca z Hostinger: plan KVM2, kod rabatowy oraz wtyczka MCP, którą agent zarządza instancją, SSH, firewallem i DNS-em.
- Granice automatyzacji: poświadczeń nie oddajemy agentowi — logowanie do GitHuba i Codexa (przez kod urządzenia) wykonujemy sami.
- Architektura pracy fabryki: zgłoszenie → triage względem misji i reguł → priorytetyzacja → pełny przegląd → automatyczne scalenie albo eskalacja do człowieka.
- Rolę silnika przepływów pełni Archon — open source’owy projekt autora.
- Status przedsięwzięcia: wczesna alfa, bez gwarancji pełnej niezawodności, ale — zdaniem autora — już warta uruchomienia.
Redakcyjne tłumaczenie
Premiera GPT-6 Astra i spór o AGI
GPT-6 Astra właśnie się pojawiła, a razem z nią — jak głosi panująca narracja — mamy AGI. Wczoraj sam Jensen Huang, szef Nvidii, oświadczył wprost, że dzięki Astrze ogólna sztuczna inteligencja stała się faktem. Nie warto jednak w całości dawać wiary tej wrzawie; ja zdecydowanie nie daję. Muszę natomiast uczciwie przyznać, że im dłużej korzystam z Astry, tym bardziej sam się przekonuję. Nie do tezy, że osiągnęliśmy AGI — ale do tego, że ten model wyraźnie wyprzedza wszystkie pozostałe duże modele językowe i różnica nie jest kosmetyczna.
Astra w praktyce: mniej tłumaczenia się z modelem
Sama tablica wyników benchmarków sugerowałaby, że Astra i Fable 5.1 są praktycznie równorzędne — i oba modele robią wrażenie. Ja jednak przez cały tydzień katowałem je testami, mocno i na różne sposoby, i w większości przypadków to Astra wychodziła na prowadzenie. Pierwszy raz mam wrażenie, że model naprawdę rozumie, co mam na myśli, i że muszę o wiele mniej czasu poświęcać na wyjaśnianie swoich intencji. Przy innych modelach — w ostatnich miesiącach najbardziej doskwierał mi Opus 5 — irytuje, jak często zakładają od siebie rzeczy, o których nie było mowy. W Astrze widzę to znacznie rzadziej. Oczywiście miewa gorsze momenty — i właśnie dlatego do AGI jeszcze nie doszliśmy.
Zawsze zresztą, gdy pojawia się model wyraźnie silniejszy od poprzedników, pierwszą rzeczą, którą robię, jest wystawienie go na próbę w najbardziej samodzielnym przepływie kodowania, jaki uda się poskładać. I tak dochodzimy do fabryki oprogramowania: daję Astrze wolną rękę — niech buduje, ile wlezie, a ja patrzę, co z tego wyjdzie. W tym tygodniu zrobiła przy jej użyciu kilka naprawdę znakomitych rzeczy i właśnie to chcę Wam pokazać.
Po co komu „ciemna fabryka”
Idea fabryki oprogramowania — nazywam ją także „ciemną fabryką” — sprowadza się do zbudowania w pełni samodzielnego rusztowania (ang. harness, czyli szkielet narzędzi i reguł wokół modelu). Na wejściu podajesz dokument wymagań produktowych (PRD), czyli opis tego, co chcesz zbudować; na wyjściu dostajesz kod gotowy do wdrożenia. Tak brzmi obietnica.
(Informacja dodatkowa: termin „ciemna fabryka”, z ang. dark factory, pochodzi z przemysłu i oznacza zakład pracujący bez udziału ludzi.)
Gdy zacząłem z tym eksperymentować na początku roku, sprawa brzmiała mało realistycznie: ani modele językowe, ani nasze własne rusztowania nie dorosły jeszcze do poziomu, przy którym można by na tym polegać. Dziś — przede wszystkim dzięki GPT-6 Astra — widzę już światełko w tunelu i zaczynam wierzyć, że to może stać się naturalnym sposobem tworzenia oprogramowania. Jeszcze tam nie jesteśmy, ale dokładnie w tym kierunku buduję.
Co znajdziecie w tym materiale
Fabrykę rozwijam jako projekt o otwartym kodzie źródłowym i wraz z jej rozwojem powstanie więcej materiałów — o tym, jak działa w środku i jak sprawić, by rozsądnie gospodarowała tokenami, bo za sprawną automatyzacją kryje się sporo inżynierii. Dziś natomiast pokażę coś innego: jak zaskakująco prosto przenieść fabrykę na serwer zdalny, tak by pracowała całą dobę i w każdej chwili była gotowa przyjąć dowolny PRD lub zgłoszenie (issue) i oddać w pełni sprawdzony kod.
Od razu przyznaję: do AGI wciąż sporo brakuje, więc fabryka nie będzie niezawodna w stu procentach i dla każdego kodu. Jesteśmy jednak na tyle blisko, że opłaca się własną instancję postawić i poeksperymentować. Stąd ten zwięzły przewodnik — krok po kroku, naprawdę szybko, z agentem kodującym w roli wykonawcy. A że fabryka wybudowała mi już sporo fajnych rzeczy — pracuję na niej nad swoimi projektami open source, na przykład Archonem, i buduję gry (jedna z nich zaraz dostanie ode mnie znacznie więcej czasu) — kolejnych materiałów będzie tylko przybywać. Część znajdziecie na kanale już dziś. Na razie jednak: wdrażamy.
Start: repozytorium i jeden prompt do agenta
Początek jest banalny. Wchodzicie do repozytorium (link w opisie filmu) i wysyłacie przygotowany prompt do swojego agenta kodującego. Reszta dzieje się sama: agent stawia całość i przeprowadza z Wami wywiad, zbierając kontekst potrzebny do tego, żeby fabryka budowała dokładnie to, co chcecie. Działa to zarówno dla zupełnie nowego projektu, w którym macie wyłącznie PRD jakiegoś MVP, jak i dla istniejącego kodu, na który chcecie fabrykę nałożyć.
Testy dobrze jest zaczynać na własnej maszynie — tak najczęściej robiłem ja. Ale to, do czego naprawdę dążymy, to fabryka zdalna: działająca 24/7, zawsze gotowa. Jestem głęboko przekonany, że przyjdzie czas, w którym każdy człowiek i każda firma będzie miała taką fabrykę w chmurze, czekającą na zadania — na przykład w postaci zgłoszeń na GitHubie.
Serwer w chmurze: Ubuntu, u mnie Hostinger
Do demonstracji musiałem wybrać konkretną platformę i wybrałem Hostinger — moim zdaniem najlepsze miejsce na VPS-y dla agentów, aplikacji webowych, no i fabryk. Część kroków będzie więc specyficzna dla Hostinger, bo chcę przy okazji pokazać, jak prostym narzędziem jest ich serwer MCP, dzięki któremu agent kodujący wdraża wszystko za Was. Zasadniczy wymóg jest jeden: działająca instancja Ubuntu w chmurze, gotowa hostować całość.
Film powstał zresztą przy wsparciu Hostinger, więc mam dla Was także zniżkę: przez link z opisu wybieracie plan — polecam KVM2, do fabryki w zupełności wystarczy — i wpisujecie kod „ColeMedin”. Po jego użyciu rabat dokłada się do promocyjnej ceny i obejmuje dwuletni plan hostingu VPS. Ja mam już swoją instancję, świeżo utworzoną i kompletnie pustą — od zera, celowo, buduję na niej fabrykę na potrzeby tego materiału. Jeśli szukacie taniego i mocnego hostingu, to dobra opcja; jeśli wolicie innego dostawcę, też nic nie stoi na przeszkodzie — agent dostosuje konfigurację.
Wywiad konfiguracyjny zamiast manuala
Kroków jest sporo, ale obejmują kompletne wdrożenie — niczego nie pominąłem. Przeważająca część to po prostu prompty do agenta kodującego. Najpiękniejsze w tym wszystkim jest to, ile pracy można zlecić asystentowi: nie tylko pisanie kodu, ale i całą konfigurację otoczenia.
Największa ściuga (cheat sheet) jest taka: bierzecie URL tej ściągi (link w opisie), wklejacie go swojemu agentowi — niezależnie od tego, z którego korzystacie; ja siedzę w Claude Code, ale fabrykę wdrożę przez Codexa z GPT-6 Astra — i piszecie: „pomóż mi to postawić”. To wszystko. Jedyna rzecz, na którą trzeba uważać: uruchomcie agenta w katalogu, w którym ma powstać nowe repozytorium GitHuba — albo w istniejącym, jeśli fabrykę nakładacie na gotowy projekt.
Agent najpierw upewni się, że Wasza maszyna ma komplet narzędzi do wdrożeń zdalnych. Potem zapyta o docelowy serwer VPS: domyślnie zaproponuje Hostinger (tak mam zbudowane demo), ale spokojnie można wskazać własny serwer albo innego dostawcę — konfiguracja dostosuje się do wyboru. Ja idę w Hostinger. Następnie zapyta, w jakim repozytorium GitHuba fabryka ma pracować. Możecie utworzyć nowe repozytorium na bazie PRD; ja, żeby przyspieszyć demonstrację, pracuję na istniejącym kodzie — mniej konfiguracji na starcie. Posłuży mi prosta aplikacja do skracania adresów, napisana specjalnie na dzisiejszy przykład.
Dwa agenty kodujące, które przetestowałem z fabryką, to Claude Code i Codex; można spróbować czegoś innego, ale te właśnie przećwiczyłem najmocniej. Ze względu na rozgłos towarzyszący premierze GPT-6 Astra i bardzo dobre wyniki, które z nią dostaję, całość przeprowadzę na Codexie. Ostatnie z pytań wstępnych: czy repozytorium zawiera działającą aplikację, czy tylko PRD? U mnie — działająca aplikacja, ale równie dobrze można ruszyć z niczego. Po przesłaniu odpowiedzi agent dokończy wywiad, doprecyzowując pozostałe szczegóły.
Pytania celowo są proste — służą zbudowaniu rdzennych plików kontekstowych fabryki. Jak dokładnie działają, tłumaczyłem w innych materiałach (link niżej); dziś skupiamy się wyłącznie na tym, żeby postawić wszystko od zera.
Wtyczka Hostinger (MCP) w akcji
Aby agent mógł pracować ze zdalną instancją, potrzebuje odpowiednich narzędzi. W Hostinger wystarczy jedna prosta wtyczka — coś podobnego mają zresztą niemal wszystkie platformy, choć zarządzanie instancjami w Hostinger jest wyjątkowo bezproblemowe. Uruchamiam instalację:
plugin install hostinger
Wtyczkę instaluję dla całego konta użytkownika — można też tylko dla pojedynczego projektu, ale ja wolę mieć ją pod ręką zawsze. Po chwili jest zainstalowana i aktywna. Poleceniem /mcp upewniam się, że agent ją widzi, po czym się loguję: wystarczy kliknięcie i potwierdzenie w przeglądarce — gotowe. Od tej pory agent może zarządzać wszystkim w moim Hostinger.
(Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard, którym modele językowe podłączają się do zewnętrznych narzędzi i usług — tutaj do panelu hostingu.)
Wracam do Claude Code (wszystko można równie dobrze robić w Codexie — po prostu w Claude Code czuję się najlepiej) i proszę: „wypisz moje instancje w Hostinger”. To taki wstępny sprawdzian poprawności. Agent pobiera dane konta i pyta: nowa instancja czy istniejąca? Tu ważna rzecz — wtyczka z założenia nie umie zakładać instancji za Was i dobrze: nie chciałbym, żeby miała taką władzę. Serwer stawiacie więc sami, a agentowi podajecie dwa parametry: identyfikator maszyny i publiczny adres IP. Oba kopiujecie z panelu.
Z takimi danymi agent przeprowadza już pełną konfigurację przez SSH i wtyczkę — łącznie z firewallem i instalacją wszystkich składników fabryki — aż dojdzie do miejsca, w którym potrzebne są Wasze poświadczenia. I tu, słusznie, automatyzacja się kończy.
Dwie rzeczy robisz sam: logowanie do GitHuba i Codexa
Zostają dokładnie dwa kroki do wykonania osobiście, wewnątrz instancji: uwierzytelnienie GitHuba i uwierzytelnienie Codexa. Po drodze agent może się parę razy zatknąć i poprosić o pomoc — po prostu odpowiadajcie na jego pytania i wykonujcie polecenia, o które prosi. Wiem, że w tym fragmencie przewodnik robi się ogólnikowy, ale to zamierzone: proces ma być elastyczny zależnie od agenta i hostingu, więc u Was może przebiegać odrobinę inaczej. W każdym razie agent sam wypisze, co dokładnie uruchomić.
Otwieram więc nowy terminal — na Windowsie najlepiej PowerShell — loguję się przez SSH do instancji i przechodzę przez polecenia jedno po drugim. Najpierw GitHub: system przenosi pod adres URL i każe wpisać kod; tak łączy się zdalna maszyna z kontem. Sprawdzam, czy zalogowanie się udało, i przechodzę do Codexa. Korzystam z trybu logowania kodem urządzenia i podobnie jak przed chwilą wpisuję kod w przeglądarce. Jedna rzecz wymaga podkreślenia: w ustawieniach ChatGPT, w sekcji poświęconej bezpieczeństwu i logowaniu, trzeba wcześniej zaznaczyć opcję pozwalającą Codexowi na autoryzację kodem urządzenia. Bez tego logowanie w środowisku zdalnym robi się uciążliwe; z nią jest najprościej, jak się da. Link do ustawień wrzucam w opisie.
Po zalogowaniu robię szybki test:
codex exec "say hi"
Możliwe, że trzeba będzie dorzucić odpowiednią flagę — agent i tak poda właściwe polecenia, a ja będę na bieżąco aktualizował prompt w repo. Istotne jest jedno: odpowiada GPT-6 Astra, bo o to w końcu chodzi — to ona ma napędzać fabrykę. Skoro model się odezwał, konfiguracja stoi. Instancja ma GitHuba, ma Codexa i jest gotowa na instalację fabryki oraz repozytorium. Zbliża się meta.
Wracam do głównego agenta i piszę krótko: „gotowe”. Teraz wie, że logowanie zakończone, i bierze się do instalacji.
Osiem minut później: fabryka stoi
Wracam po około ośmiu minutach, a agent w tym czasie zdążył bardzo dużo: zainstalował fabrykę oprogramowania, doinstalował Archona — to on po cichu uruchamia przepływy pracy — potwierdził, że Codex działa, skonfigurował całość i pobrał repozytorium, na które nakładam fabrykę.
(Informacja dodatkowa: Archon to rozwijany przez Cole’a Medina projekt open source do budowania agentów AI; w fabryce pełni rolę silnika przepływów pracy.)
Na koniec agent zadał kilka pytań, żeby przetestować całość od początku do końca: na jakiej nazwie hosta zamontować aplikację (to już kwestia indywidualna) i na jakim porcie. A potem przyszło pytanie najważniejsze. Okazuje się bowiem, że ta sama ściąga, którą daliśmy agentowi, prowadzi nie tylko przez instalację fabryki, ale i przez jej przetestowanie: jakie pierwsze zgłoszenie albo PRD podać systemowi, żeby sprawdzić, że wszystko działa od końca do końca? Można wpisać cokolwiek — ja przyjmuję podpowiedź agenta i wybieram zadanie wprost z misji projektu. Wysyłam.
Agent tworzy zgłoszenie w repozytorium GitHuba (przez GitHub CLI), a następnie obserwuje, jak fabryka doprowadza je aż do pull requesta — zweryfikowanego i gotowego do scalenia. Jest i wisienka na torcie: dzięki wtyczce Hostinger agent potrafi zaktualizować ustawienia DNS, więc jeśli macie w Hostinger domenę, zajmie się i tym.
Jak pracuje fabryka: od zgłoszenia do scalonego kodu
Pokażę jeszcze szybko, jak całość wygląda od strony wejścia. PRD rozbijamy na zgłoszenia albo tworzymy zgłoszenia bezpośrednio — to zawsze jest droga, którą zadania trafiają do systemu. Zgłoszenie podchwytuje przepływ sortujący — triage: analizuje kontekst, porównuje go z regułami fabryki, misją projektu i pozostałymi plikami kontekstowymi, po czym rozstrzyga, czy odrzucić zadanie, czy przepuścić je całą drogą do pull requesta. Przy okazji nadaje priorytety. Na wyjściu za każdym razem pojawia się pull request po pełnym przeglądzie: jeżeli trzeba, trafia do człowieka (eskalacja); w większości przypadków — bo o samodzielność przecież chodzi — jest scalany automatycznie. Mamy więc dosłownie: zgłoszenie na wejściu, zweryfikowany i scalony kod na wyjściu.
U mnie próba przebiegła wzorowo: zgłoszenie utworzone do testu przeszło triage ze statusem „archon ready”, a chwilę później pojawił się pull request. Resztę przepuściłem poza kadrem — to bardzo prosty test, ale właśnie o to chodzi: chcemy tylko potwierdzić, że uruchamianie działa i że przepływy współpracują z naszym logowaniem agenta. Teraz Wasza kolej: zakładajcie prawdziwe zgłoszenia i rozwijajcie aplikację fabryką.
Gdy test wypadnie pomyślnie, zamykacie sesję agenta kodującego. Od tej chwili fabryka pracuje zdalnie, całą dobę, gotowa przyjąć każde zgłoszenie na GitHubie do wszystkiego, co chcecie dalej dobudowywać.
Wczesna alfa — ale dobry kierunek
Jeśli szliście ze mną krok po kroku, macie teraz własną fabrykę oprogramowania AI, pracującą 24/7 na GPT-6 Astra. Można nią budować naprawdę świetne rzeczy. Włożyłem już dużo pracy w to, żeby rusztowanie było mocne i niezawodne, ale wciąż nazwałbym to wczesną alfą — sporo jeszcze szlifuję, więc kolejne materiały nadciągną. Jeśli podobał Wam się ten film i czekacie na więcej o inżynierii agentowej i fabryce oprogramowania, będę wdzięczny za łapkę i subskrypcję. Do zobaczenia następnym razem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nowy, mocniejszy model sprawdzaj od razu w najtrudniejszym trybie
Na czym polega: Autor za każdym razem, gdy wychodzi model wyraźnie silniejszy od poprzedników, testuje go w najbardziej samodzielnym przepływie kodowania, jaki potrafi złożyć — a nie w luźnej rozmowie.
Jak stosować: Gdy pojawi się kolejny przełomowy model, przepuść go przez swój najbardziej wymagający pipeline (u autora: fabrykę oprogramowania) i porównuj wyniki z bieżącym zestawem na tych samych zadaniach.
Na co uważać: Prosty czat z modelem nic nie mówi o jego przydatności w automatyzacji — dopiero praca bez nadzoru obnaża słabe punkty.
2.Benchmarki stawiają modele na równi — praktyka rozstrzyga inaczej
Na czym polega: Tabele wyników sugerowały równorzędność Astry i Fable 5.1, ale w tygodniowych testach na własnych zadaniach Astra wygrywała większość starć.
Jak stosować: Zbuduj mały zestaw swoich typowych zadań (5–10) i przepuszczaj przez niego każdego nowego modelu, zanim zmienisz narzędzie pracy.
Na co uważać: Różnice w codziennym użytkowaniu — choćby częstotliwość dziwnych założeń modelu — nie zawsze widać w rankingach; nie równaj też skoku jakości z ogłoszeniami AGI.
3.O budowie oprogramowania myśl jak o fabryce: zgłoszenie wchodzi, scalony kod wychodzi
Na czym polega: „Ciemna fabryka” to w pełni samodzielne rusztowanie: na wejściu PRD lub zgłoszenie na GitHubie, na wyjściu pull request po pełnym przeglądzie, często scalany automatycznie.
Jak stosować: Zacznij od jednego, dobrze określonego obszaru (MVP z PRD albo istniejąca aplikacja) i podawaj zadania wyłącznie przez zgłoszenia, żeby cała praca szła jednym torem.
Na co uważać: Nie wszystko nadaje się do automatycznego scalania — kod krytyczny dla produkcji trzymaj za regułami eskalacji do człowieka.
4.Najpierw test lokalnie, ale celuj w wersję zdalną 24/7
Na czym polega: Autor testuje fabrykę na własnej maszynie, ale prawdziwa wartość to instancja w chmurze, przyjmująca zgłoszenia o każdej porze.
Jak stosować: Po lokalnej walidacji przenieś fabrykę na VPS z Ubuntu; od tego momentu „praca” nad projektem zaczyna się od założenia zgłoszenia, nie od otwierania edytora.
Na co uważać: Maszyna działająca stale to większa powierzchnia ataku — zadbaj o firewall (agent może go skonfigurować) i pilnuj, by żadne sekrety nie trafiły do logów.
5.Jedna ściąga i jedno zdanie zastępują cały manual
Na czym polega: Całe wdrożenie uruchamia wklejenie agentowi kodującemu URL-a ze ściągą i prośba „pomóż mi to postawić”; resztę załatwia wywiad konfiguracyjny.
Jak stosować: Otwórz agenta w katalogu docelowego repozytorium (nowego albo istniejącego) i odpowiadaj na pytania — od serwera, przez repozytorium, po wybór agenta wykonawczego.
Na co uważać: Agent po drodze może się zatknąć i poprosić o pomoc; przewiduj przerwy i przed startem upewnij się, że katalog roboczy jest właściwy.
6.Odpowiedzi z wywiadu stają się regułami fabryki
Na czym polega: Proste pytania agenta budują rdzenne pliki kontekstowe — misję i reguły, na których opiera się triage zgłoszeń.
Jak stosować: Opisz misję projektu i zasady przyjmowania zadań konkretnie i bez sprzeczności; wracaj do nich zawsze, gdy fabryka źle priorytetyzuje.
Na co uważać: Rozmyta misja to złe decyzje triage — system ocenia zadania według tego, co mu wpisano, a nie według tego, co miałeś w głowie.
7.Poświadczeń nie oddajemy agentowi — dwa logowania robisz sam
Na czym polega: Automatyzacja kończy się w miejscu, gdzie potrzebne są dane logowania: do GitHuba i do Codexa uwierzytelniasz się ręcznie, kodem urządzenia, wewnątrz instancji.
Jak stosować: Zaloguj się przez SSH i wykonaj polecenia wypisane przez agenta; wcześniej w ustawieniach ChatGPT (bezpieczeństwo i logowanie) włącz autoryzację kodem urządzenia dla Codexa.
Na co uważać: Bez tej opcji logowanie zdalne robi się uciążliwe; po konfiguracji zweryfikuj łączność krótkim testem (codex exec "say hi"), zanim polecisz dalej.
8.Wtyczka MCP hostingu niech zrobi brudną robotę — ale w granicach
Na czym polega: Wtyczka Hostinger pozwala agentowi zarządzać instancją, DNS-em i konfiguracją, ale celowo nie pozwala zakładać serwerów.
Jak stosować: Zainstaluj wtyczkę, zaloguj ją w przeglądarce, poproś o listę instancji i podaj identyfikator maszyny oraz publiczny adres IP — resztę agent ogarnia sam.
Na co uważać: Sam serwer zakładasz wyłącznie ręcznie; traktuj to jako zaletę, nie niedogodność — to bezpieczniejszy podział ról między człowiekiem a agentem.
9.Fabrykę testuj od razu przejściem całej ścieżki
Na czym polega: Ta sama ściąga prowadzi także przez pierwszy test end-to-end: od założenia zgłoszenia, przez triage, aż po zweryfikowany pull request.
Jak stosować: Zaraz po instalacji wybierz małe, bezpieczne zadanie (może pochodzić wprost z misji projektu), pozwól agentowi założyć zgłoszenie przez GitHub CLI i obserwuj, aż PR dojdzie do scalenia.
Na co uważać: Prosty test dowodzi tylko, że uruchamianie i logowanie działają — o jakości decyzji fabryki przesądzą dopiero prawdziwe zadania.
10.To wciąż wczesna alfa — pilnuj eskalacji i szlifuj reguły
Na czym polega: Autor wprost nazywa projekt wczesną alfą: rusztowanie jest już mocne, ale wciąż poddawane udoskonaleniom, a niezawodność nie jest pełna.
Jak stosować: Uruchom fabrykę w trybie 24/7, ale z zapasem nadzoru: przeglądaj eskalowane pull requesty, analizuj odrzucone zgłoszenia i na tej podstawie poprawiaj reguły oraz misję.
Na co uważać: Nie powierzaj od razu krytycznego kodu produkcji; autonomię rozszerzaj stopniowo, w miarę jak system zdobywa zaufanie na Twoich zadaniach.