O czym jest ten film
- „Fabryka oprogramowania” to system, który przyjmuje zadania, przydziela je agentom programistycznym i pilnuje dalszego przebiegu pracy.
- W pokazanym rozwiązaniu zadanie zaczyna się od zgłoszenia w GitHubie oznaczonego etykietą
ready. - Dyspozytor wybiera wolnego agenta Codex lub Claude Code. Autor może też wskazać rodzaj agenta etykietą.
- Każdy agent działa na osobnej maszynie wirtualnej Upstash, więc praca trwa również po zamknięciu laptopa.
- Agent przygotowuje zmianę i otwiera pull request, który człowiek może sprawdzić, skomentować, odrzucić albo scalić.
- Repozytoria projektów przekazują zgłoszenia do centralnego repozytorium fabryki przez GitHub Actions.
- Konfiguracja wymaga między innymi klucza Upstash, tokenu GitHub z dostępem do wybranych repozytoriów oraz danych uwierzytelniających używanych agentów.
- Autor pokazuje osobny próbny przebieg, a następnie sprawdza działanie systemu na rzeczywistym zgłoszeniu.
- Obrazy bazowe maszyn pozwalają przygotować agentom wspólne narzędzia, umiejętności i zasady pracy.
- Fabrykę można rozbudować o kolejne maszyny i repozytoria, pamiętając o zmianie uprawnień tokenu GitHub.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od zgłoszeń, z których już korzystasz
Na czym polega: W pokazanym rozwiązaniu zwykłe zgłoszenie w GitHubie uruchamia pracę agenta po dodaniu etykiety ready.
Jak stosować: Opisz konkretną zmianę w repozytorium, oznacz zgłoszenie jako gotowe i śledź jego stan przez kolejne etykiety oraz komentarze.
Na co uważać: W publicznym repozytorium zgłoszenia mogą tworzyć także inne osoby. Ustal, czy każde z nich powinno móc uruchomić pracę agentów.
2.Oddziel przydzielanie zadań od pisania kodu
Na czym polega: Fabryka przyjmuje zgłoszenie i wybiera wykonawcę; samą zmianę wprowadza agent programistyczny.
Jak stosować: W dyspozytorze określ zasady wyboru wolnego agenta. Na początek wystarczy prosty program, bez dodatkowego modelu do oceny każdego zgłoszenia.
Na co uważać: Jeśli nie ma wolnego agenta, zadanie musi poczekać. Sprawdź, czy mechanizm ponawiania prób działa zgodnie z oczekiwaniami.
3.Dobieraj agenta do rodzaju pracy
Na czym polega: System może korzystać z kilku narzędzi programistycznych. W przykładzie autor używa Codexa i Claude Code.
Jak stosować: Pozwól wskazać agenta etykietą, a dla zgłoszeń bez takiej etykiety ustaw prostą regułę przydziału. Bardziej rozbudowaną klasyfikację dodaj, gdy będzie potrzebna.
Na co uważać: Oceny mocnych stron poszczególnych modeli w materiale są opinią autora. Sprawdzaj je na własnych zadaniach.
4.Zachowaj przegląd zmian przez człowieka
Na czym polega: Agent kończy pracę pull requestem albo dopisuje komentarz, jeśli napotka przeszkodę lub potrzebuje decyzji projektowej.
Jak stosować: Przejrzyj proponowaną zmianę, wyniki sprawdzeń i opis pull requestu. Następnie poproś o poprawki, zamknij propozycję albo ją scal.
Na co uważać: Sam fakt, że agent otworzył pull request, nie oznacza, że rozwiązanie jest poprawne lub zgodne z zamiarem.
5.Uruchamiaj agentów w odizolowanych środowiskach
Na czym polega: Każdy wykonawca działa w osobnej maszynie wirtualnej, z własnymi zasobami, poza laptopem autora.
Jak stosować: Przygotuj oddzielne środowisko dla każdego agenta i udostępnij mu tylko dostęp potrzebny do zadania.
Na co uważać: Treść zgłoszenia może zawierać instrukcje próbujące wpłynąć na agenta. Izolacja ogranicza możliwe szkody, ale nie zastępuje kontroli uprawnień i przeglądu kodu.
6.Przyznaj tokenowi dostęp tylko do potrzebnych repozytoriów
Na czym polega: Token GitHub pozwala fabryce czytać kod oraz pracować ze zgłoszeniami i pull requestami.
Jak stosować: Wybierz konkretne repozytoria, nadaj wymagane uprawnienia i ustaw termin ważności tokenu. Sekrety wpisuj do przeznaczonego na nie lokalnego pliku .env.
Na co uważać: Po dodaniu nowego projektu trzeba rozszerzyć listę repozytoriów dostępnych dla tokenu. Nie wklejaj sekretów do rozmowy z agentem dla samej wygody.
7.Najpierw sprawdź połączenie, potem wykonanie zadania
Na czym polega: Autor najpierw testuje utworzenie maszyn i przekazanie zgłoszenia między repozytoriami, a dopiero później pozwala agentowi zmienić kod.
Jak stosować: Utwórz małe zgłoszenie testowe, sprawdź przebieg GitHub Actions i komentarze, a następnie uruchom właściwą pracę agenta.
Na co uważać: Pomyślny test przekazania zgłoszenia potwierdza tylko ten etap. Osobno sprawdź, czy agent potrafi wykonać zmianę i otworzyć pull request.
8.Przygotuj wspólny obraz środowiska pracy
Na czym polega: Obraz bazowy, nazywany w materiale „snapshotem”, służy do tworzenia maszyn z już zainstalowanymi narzędziami i instrukcjami.
Jak stosować: Umieść w nim potrzebne umiejętności agenta, narzędzia przeglądarkowe, serwery MCP lub plik AGENTS.md, a potem twórz nowe maszyny z tego obrazu.
Na co uważać: Zmiana obrazu nie aktualizuje automatycznie maszyn, które już działają. W pokazanym procesie autor usuwa stare maszyny i tworzy je ponownie.
9.Zwiększaj liczbę agentów zgodnie z rzeczywistą potrzebą
Na czym polega: Autor zaczyna od czterech maszyn — dwóch dla Codexa i dwóch dla Claude Code — a później zwiększa ich liczbę do dziesięciu.
Jak stosować: Dobierz liczbę wykonawców do liczby równoległych zadań i limitu konta. Obserwuj, czy zgłoszenia czekają na wolnego agenta.
Na co uważać: Większa liczba maszyn ułatwia równoległą pracę, ale zwiększa też liczbę zmian wymagających przeglądu.
10.Dodając projekt, zaktualizuj oba końce połączenia
Na czym polega: Nowe repozytorium musi być dostępne dla tokenu GitHub i mieć mechanizm wysyłający gotowe zgłoszenia do fabryki.
Jak stosować: Dodaj repozytorium do uprawnień tokenu, poproś agenta o podłączenie projektu i scal przygotowany przez niego pull request z konfiguracją wyzwalacza.
Na co uważać: Jeśli token nie obejmuje nowego repozytorium, samo polecenie wydane agentowi nie wystarczy. Po podłączeniu wykonaj próbę na prostym zgłoszeniu.
Redakcyjne tłumaczenie
Fabryka obok kodu
Od pewnego czasu eksperymentuję z fabrykami oprogramowania. Zbudowałem własną, która działa na GitHubie. Podoba mi się pomysł zespołu agentów programistycznych, ale nie chciałem instalować kolejnego narzędzia uruchamianego z wiersza polecenia ani obsługiwać osobnej aplikacji. Wolałem mieć cały system tam, gdzie jest kod.
Teraz wystarczy, że utworzę zgłoszenie i oznaczę je jako gotowe. Fabryka przydzieli zadanie agentowi. Mam w niej około dziesięciu wykonawców: część korzysta z Codexa, część z Claude Code. Mogą pracować nad różnymi projektami. System zmienia również etykiety zgłoszeń, więc od razu widać, nad czym właśnie pracuje.
Pokażę to na przykładzie. Oznaczam zgłoszenie numer 34 jako gotowe i wybieram dla niego Codexa. Po chwili w repozytorium fabryki widać, że zadanie zostało przydzielone, a na liście agentów jeden z nich jest zajęty tym zgłoszeniem. Gdy skończy, otworzy pull request. Będę mógł go przejrzeć i, jeśli zmiana mi odpowiada, scalić.
Czym właściwie jest fabryka oprogramowania?
Dla wielu osób to kolejny krok w pracy z agentami programistycznymi. Zamiast pilnować każdej sesji osobno, tworzymy grupę agentów czekających na zadania. Możemy przygotować na przykład dziesięciu wykonawców. Każdy z nich dostaje pracę, wprowadza zmianę, sprawdza ją zgodnie z przyjętymi zasadami i na końcu otwiera pull request albo publikuje kod.
Człowiek nadal może uczestniczyć w tym procesie. W dużych fabrykach przegląd zmian również bywa jego zadaniem. W moim przykładzie agent nie dostaje swobody samodzielnego wprowadzania wszystkiego do projektu: końcowa decyzja o scaleniu pull requestu należy do mnie.
Warto rozróżnić fabrykę od agenta. Fabryka sama nie pisze kodu. To program zarządzający przebiegiem pracy. Odbiera informację o zadaniu — może nią być wiadomość na Slacku lub Telegramie albo zgłoszenie w GitHubie — ocenia, co należy zrobić, i przydziela pracę wolnemu agentowi.
Typowy przebieg wygląda tak: najpierw pojawia się zgłoszenie, potem następuje jego ocena i przydział. Agent wprowadza zmianę, uruchamia testy lub inne kontrole, a następnie przekazuje wynik. System czeka już na następne zadanie. Można w nim dodać tyle etapów wymagających decyzji człowieka, ile potrzeba: przed zmianą architektury, przed zmianą naruszającą zgodność z wcześniejszą wersją, podczas obsługi incydentu czy po prostu przed scaleniem pull requestu.
Na etapie oceny zgłoszenia dałoby się użyć modelu językowego. Mógłby rozpoznać, czy chodzi o błąd, nową funkcję czy dokumentację, i na tej podstawie wybrać agenta. Ja poszedłem prostszą drogą: napisałem mechanizm, który pobiera zadanie i przydziela je dostępnemu wykonawcy. Jeśli żaden nie jest wolny, próbuje ponownie. Jeśli użytkownik wskazał etykietą Codexa albo Claude Code, system uwzględnia ten wybór. To tylko dwa przykłady — można podłączyć również innych agentów.
Po zakończeniu pracy agent otwiera pull request. Jeśli napotka problem albo potrzebuje decyzji projektowej, może zamiast tego dopisać komentarz do pierwotnego zgłoszenia. Człowiek przegląda wynik i decyduje, czy scalić zmianę, poprosić o poprawki, czy zamknąć propozycję.
Po co korzystać z różnych agentów?
Można wybrać jedno narzędzie do wszystkich zadań, ale mieszany zespół pozwala dobierać wykonawcę do rodzaju pracy. Według moich doświadczeń Claude Fable dobrze radzi sobie ze złożonym kodem, a GPT-6 Astra z pracą dotyczącą grafiki 3D. Dyspozytor mógłby więc odczytać zgłoszenie i przydzielić je Codexowi, gdy chodzi o elementy 3D, albo agentowi Claude, gdy zadanie wymaga skomplikowanego programowania. Do drobnej poprawki dokumentacji można użyć szybszego i tańszego modelu.
Każdy agent w moim rozwiązaniu działa we własnym, odizolowanym środowisku. Ma to znaczenie dla bezpieczeństwa. Zgłoszenie może zawierać złośliwe instrukcje skierowane do modelu. Agent uruchomiony na osobnej maszynie nie ma swobodnego dostępu do plików i sekretów na moim laptopie, co ogranicza skutki takiej próby.
Osobne maszyny rozwiązują też problem zasobów. Każdy wykonawca ma własny przydział sprzętu — przykładowo dwa procesory i 4 GB pamięci — więc dziesięciu agentów nie musi rywalizować o moc jednego komputera. Maszyny pozostają dostępne, gdy zamknę laptopa. Mogę dodać zgłoszenie przez telefon, a praca będzie trwała dalej.
Co będzie potrzebne?
Zaczynamy od co najmniej jednego repozytorium GitHub, którym fabryka ma się zajmować. Może to być istniejący projekt albo prosta aplikacja testowa. Repozytorium może być prywatne lub publiczne. Przy publicznym trzeba pamiętać, że inne osoby również mogą zakładać zgłoszenia. W razie potrzeby można tak zmienić etap ich oceny, by system przyjmował tylko zadania utworzone przez nas. W pokazie użyję dwóch repozytoriów: demonstracyjnego projektu RTS i aplikacji z listą zadań.
Potrzebujemy również maszyn dla agentów. Używam usługi Upstash Boxes; w tym przykładzie wystarcza jej bezpłatny plan. „Box” to niewielka maszyna wirtualna z Linuksem, na której można uruchomić Claude Code lub Codexa.
Na koniec potrzebna jest sama fabryka: program odbierający zgłoszenia, przydzielający je agentom i śledzący cały proces. Poproszę agenta programistycznego, żeby przygotował ją za mnie, a jej kod umieszczę w osobnym repozytorium GitHub. Automatyzacja będzie działać za pośrednictwem GitHub Actions.
Przygotowanie tego rozwiązania wymagało ode mnie przeczytania dokumentacji Upstash, GitHub Actions oraz kilku innych materiałów. Dlatego opracowałem umiejętność agenta — zestaw instrukcji i odsyłaczy — która pomaga zbudować taką fabrykę. Link do repozytorium z moimi umiejętnościami znajduje się w opisie filmu. W katalogu skills jest instrukcja create-upstash-software-factory.
Opisuje ona agentowi, jak tworzyć maszyny Upstash, instalować na nich Codexa i Claude Code, dobierać modele oraz poziomy wysiłku, a także jak zorganizować przyjmowanie zgłoszeń i zwracanie pull requestów. Obejmuje również konfigurację GitHub Actions, dzięki której repozytoria projektów mogą powiadamiać fabrykę o zadaniach, a fabryka może aktualizować zgłoszenia. Jeśli chcecie zrozumieć szczegóły, możecie poprosić własnego agenta, by przeanalizował tę instrukcję krok po kroku.
Tworzenie fabryki
Kopiuję adres repozytorium z umiejętnościami, tworzę nowy folder dla fabryki i proszę agenta o zainstalowanie wskazanej instrukcji. Następnie uruchamiam ją poleceniem /create-upstash-software-factory.
Agent będzie szukał dokumentacji potrzebnej do pracy z Upstash Boxes. Polecam mu narzędzie Context7, które pomaga znaleźć aktualne materiały. Jeśli go nie skonfigurujecie, agent może poszukać dokumentacji w internecie.
Najpierw wybieram repozytoria, którymi ma zajmować się fabryka. Potem określam wykonawców i sposób ich uwierzytelniania. Wybieram Claude Code używany w ramach mojej subskrypcji oraz Codexa. Można też podać klucz API albo poprosić o obsługę innych dostawców.
Nowe repozytorium fabryki nazywam software-factory i ustawiam jako prywatne. Nie widzę powodu, by udostępniać jego konfigurację publicznie. Agent pyta również o limit maszyn na koncie Upstash i liczbę wykonawców. Bezpłatny plan w pokazanej konfiguracji pozwala utworzyć do dziesięciu maszyn, ale na początek wybieram cztery: dwie dla Codexa i dwie dla Claude Code.
Kolejne pytanie dotyczy zadań bez etykiety wskazującej rodzaj agenta. Mogę dać pierwszeństwo Claude Code, Codexowi albo rozdzielać pracę między nimi. Wybieram równomierny podział.
Agent pyta też o narzędzie do obsługi przeglądarki. Moje projekty są aplikacjami przeglądarkowymi. Maszyny Upstash mają Chromium, ale agent potrzebuje dodatkowego narzędzia, takiego jak agent-browser, żeby samodzielnie otworzyć aplikację i obejrzeć wynik swojej pracy. Włączam tę możliwość.
Po udzieleniu odpowiedzi agent tworzy pliki fabryki i wysyła je do GitHuba. Teraz potrzebuje trzech sekretów. Wpisuję je bezpośrednio do lokalnego pliku .env, zamiast wklejać je do rozmowy.
Pierwszy to klucz API Upstash Boxes. Tworzę go w ustawieniach usługi, w sekcji kluczy API, i zapisuję w .env. Dzięki niemu fabryka będzie mogła zarządzać maszynami agentów.
Drugi sekret to token GitHub. W ustawieniach konta przechodzę do narzędzi deweloperskich i tworzę token typu fine-grained. Nadaję mu nazwę software-factory, ustawiam siedmiodniowy termin ważności i wybieram tylko repozytoria, których ma dotyczyć: repozytorium fabryki oraz projekty oddawane pod jej opiekę. Przyznaję uprawnienia do odczytu i zapisu zawartości repozytoriów, zgłoszeń oraz pull requestów. Potem zapisuję token w .env. Gdy zechcę dodać następny projekt, będę musiał dopisać go także do listy repozytoriów dostępnych dla tokenu.
Trzeci sekret to token OAuth Claude Code, dzięki któremu agenci mogą korzystać z mojego uwierzytelnienia w tej usłudze. Uzyskuję go poleceniem wskazanym przez agenta i również zapisuję w .env. Tokeny użyte podczas nagrania usunę po zakończeniu pokazu.
Informuję agenta, że plik jest uzupełniony. Teraz wybieram modele i poziomy wysiłku dla wykonawców: Claude Opus z wysokim poziomem wysiłku oraz GPT-6 Astra z wysokim poziomem rozumowania.
Test połączenia i uruchomienie wyzwalaczy
Agent tworzy dwie próbne maszyny w Upstash. W ten sposób sprawdza, czy potrafi utworzyć środowisko i uruchomić w nim każdego z wybranych wykonawców. Po teście maszyny są usuwane. Gdy połączenie działa, agent przygotowuje fabrykę w GitHubie i prosi o zastosowanie konfiguracji wyzwalaczy.
Każde repozytorium projektowe musi wiedzieć, dokąd wysłać informację o nowym zgłoszeniu oznaczonym jako gotowe. Dlatego agent otwiera w tych repozytoriach pull requesty z odpowiednią konfiguracją. Sprawdzam je i scalam. Od tej chwili projekty mogą przekazywać zadania do centralnej fabryki.
Tworzę małe zgłoszenie testowe: dodanie jasnego i ciemnego wyglądu aplikacji. Nadaję mu etykietę ready. W repozytorium fabryki, w zakładce GitHub Actions, widzę uruchomiony proces. Na tym etapie sprawdzam jedynie połączenie między repozytorium projektu a fabryką; agent programistyczny jeszcze nie zmienia kodu.
Potwierdzam agentowi, że zgłoszenie dotarło. Próbny przebieg zakończył się powodzeniem, więc agent wyłącza tryb testowy. Jeden z jego kroków wymaga ręcznego zatwierdzenia polecenia w systemie uprawnień Claude Code. Po zatwierdzeniu zdejmuję etykietę ready ze zgłoszenia i dodaję ją ponownie, aby uruchomić właściwą pracę.
Fabryka przyjmuje zadanie, a w Upstash widać zajętego wykonawcę. Etykieta zgłoszenia zmienia się z ready na factory running. Gdy agent kończy, pojawia się factory review. W komentarzu widzę, że zadanie przydzielono wykonawcy Claude02, oraz znajduję odnośnik do utworzonego pull requestu.
Otwieram propozycję zmiany. Jej opis wskazuje, że scalenie zamknie zgłoszenie numer 52, i przedstawia szczegóły wykonanej pracy. Przeglądam ją i scalam. Agent sprawdza jeszcze dzienniki, aby potwierdzić, że cały proces zadziałał. Proponuje następnie próbę z wieloma zgłoszeniami i kilkoma repozytoriami równocześnie — taki test można przeprowadzić we własnej konfiguracji.
Wspólne środowisko dla agentów
Maszyny Upstash są na początku proste: działają na nich Linux oraz zainstalowany Codex lub Claude Code. Często chcemy jednak, żeby każdy agent otrzymał dodatkowe narzędzia i zasady pracy. Nie trzeba konfigurować każdej maszyny osobno. Można przygotować obraz bazowy, z którego będą powstawały kolejne środowiska.
Mój agent utworzył już dwa takie obrazy: jeden dla Codexa, drugi dla Claude Code. Początkowo zawierają przede wszystkim instalację odpowiedniego narzędzia. Proszę go więc o przygotowanie nowych wersji z dodatkowymi umiejętnościami, na przykład frontend-design i agent-browser. W ten sam sposób można dodać serwery MCP lub plik AGENTS.md z instrukcjami dla agenta.
Po utworzeniu nowych obrazów trzeba jeszcze zastąpić stare maszyny. W pokazanej konfiguracji agent nie może sam usuwać istniejących maszyn ani obrazów w Upstash, więc robię to ręcznie. Następnie proszę go o ponowne utworzenie wykonawców z nowych obrazów. Nowe maszyny dostają już przygotowane narzędzia.
Przy okazji zwiększam liczbę wykonawców z czterech do dziesięciu, dzieląc ich między Codexa i Claude Code. Agent tworzy sześć dodatkowych maszyn; pojawiają się kolejno na liście Upstash.
Dodawanie następnego repozytorium
Podłączenie kolejnego projektu zaczyna się od uprawnień GitHuba. Otwieram ustawienia wcześniej utworzonego tokenu software-factory i dodaję nowe repozytorium do listy tych, do których token ma dostęp. Następnie otwieram projekt fabryki w Claude Code i proszę o dołączenie wskazanego repozytorium.
Agent potwierdza, że token pozwala mu dotrzeć do projektu. Jeśli na tym etapie pojawia się błąd, trzeba sprawdzić listę repozytoriów przypisanych do tokenu. Podobnie jak wcześniej, agent otwiera pull request dodający mechanizm wysyłania gotowych zgłoszeń do fabryki. Po przejrzeniu scalam go.
Na próbę tworzę w nowym projekcie zgłoszenie dotyczące jasnego i ciemnego wyglądu. Dodaję etykietę ready oraz etykietę wskazującą Codexa, ponieważ aplikacja wykorzystuje elementy 3D. Fabryka podejmuje zadanie: zgłoszenie dostaje oznaczenie factory running, komentarz informuje o przydzieleniu go wykonawcy Codex01, a w Upstash widać, że ten agent pracuje. Przebieg można też śledzić w GitHub Actions.
Jeśli chcecie szerzej poznać pracę z agentami programistycznymi, prowadzę społeczność Agentic Labs w serwisie Skool. Są tam kursy, w tym „Agentic Coding Masterclass”, podczas którego budujemy aplikacje między innymi z płatnościami i uwierzytelnianiem użytkowników, oraz spotkania na żywo. Dziękuję Upstash za sponsorowanie tego materiału.