Fabryka oprogramowania AI: czego wymaga i gdzie ma granice

Co rozumiemy przez autonomiczną fabrykę oprogramowania

Pod tym pojęciem rozumiemy proces, w którym agenci kodujący prowadzą jasno określone zadania od issue do zmergowanej zmiany, według zasad spisanych przez twój zespół. Zadanie opisuje pisemna specyfikacja, agent pracuje w izolowanym środowisku, a o merge'u decydują deterministyczne kontrole i ludzie. Większość fabryki to wszystko, co dzieje się wokół agenta: przyjmowanie zadań, kolejka, środowiska, bramki, polityka merge'a i informacja zwrotna.

Starsze znaczenia tego pojęcia

Termin jest starszy niż agenci kodujący. Departament Obrony USA opisuje software factory jako połączenie ludzi, narzędzi i procesów, które w sposób ciągły dostarcza oprogramowanie, a pipeline'y CI/CD pełnią w nim rolę linii montażowych. Niektóre firmy usługowe IT nazywają tak uporządkowany model outsourcingu programowania. Jeszcze wcześniej, między końcem lat 60. a końcem lat 70., Hitachi, Toshiba, NEC i Fujitsu tworzyły fabryki oprogramowania, żeby ujednolicić procesy i upowszechnić wśród pracowników sprawdzone narzędzia i metody.

Fabryka w znaczeniu agentowym, po angielsku nazywana AI software factory, zachowuje pipeline oraz ustandaryzowany proces i dodaje agentów, którzy piszą zmiany. Dlatego najtrudniejszym problemem staje się weryfikacja: fabryka musi sprawdzać pracę, której powstawania nikt nie obserwował.

Dark factory w publicznej dyskusji

Niektóre publikacje idą dalej. W styczniu 2026 roku Dan Shapiro opisał skalę poziomów programowania wspieranego przez AI, której najwyższy poziom nazywa dark factory: to czarna skrzynka zamieniająca specyfikacje w oprogramowanie, nazwana tak od fabryk obsługiwanych przez roboty, w których ludzie nie są potrzebni. W lutym 2026 roku firma StrongDM opisała software factory swojego zespołu AI, w której specyfikacje i scenariusze sterują agentami, a zasady mówią wprost, że ludzie ani nie piszą kodu, ani nie robią jego review. Walidacja opiera się tam na scenariuszach end-to-end, często trzymanych poza bazą kodu jak zbiór holdout, oraz na behawioralnych klonach zewnętrznych usług, od których zależy oprogramowanie.

Czego fabryka nie obiecuje

Nie budujemy dark factory i nie obiecujemy produkcji bez ludzi. W typach zadań, które do tego pasują, agenci przejmują dużą część pisania kodu. Ludzie nadal wyznaczają kierunek, biorą na siebie ryzyko każdego typu zadań i odpowiadają za to, co trafia na produkcję, łącznie z incydentami i revertami.

• Które typy zadań fabryka może przejmować, a których nie
• Specyfikacja każdego zadania, napisana lub zatwierdzona przez człowieka
• Polityka merge'a, jej właściciel i każda jej zmiana
• Review zmian w harnessie, w bramkach i w samej polityce
• Wyrywkowy przegląd zmergowanej pracy, także tam, gdzie merge następuje po samych automatycznych kontrolach
• Decyzja o wstrzymaniu fabryki

Autonomia może rosnąć po jednym typie zadań naraz. Jeśli aktualizacje patchowe zależności przez uzgodniony czas przechodzą review bez uwag, właściciel może pozwolić, żeby trafiały do merge'a po zaliczeniu kontroli. Ta decyzja jest zapisana w kodzie, ma wskazanego właściciela i da się ją cofnąć jedną zmianą.

Etapy, które przychodzą wcześniej

Na ścieżce, którą opisujemy, fabryka oprogramowania jest ostatnim z czterech etapów. W agentic coding agenci pracują u boku każdego inżyniera, w ramach budżetu i ze wspólnym harnessem w każdym repozytorium. Na etapie optymalizacji każda zmiana tej konfiguracji, od domyślnego modelu po plik z instrukcjami, jest mierzona na twoim własnym kodzie. Fabryka uruchamia tę samą konfigurację bez człowieka, który pilnuje każdego uruchomienia, więc dziedziczy każdą lukę pozostawioną przez wcześniejsze etapy.

Pominięcie etapu zwykle kończy się porażką w rozpoznawalny sposób. Bez wspólnego harnessu agenci nie potrafią zbudować i przetestować kodu z czystego checkoutu, a fabryka produkuje wiarygodnie wyglądające zmiany, których nikt nie umie zweryfikować. Bez pomiarów nikt nie powie, czy zmiany z fabryki kosztują mniej niż praca inżyniera, czy wymagają więcej poprawek, więc fabryka albo działa bez kontroli, albo zostaje wyłączona po pierwszym złym tygodniu.

Raport DORA 2025, przedstawiony przez Google Cloud we wrześniu 2025 roku, nadal wskazał negatywny związek między wdrażaniem AI a stabilnością dostarczania oprogramowania. Autorzy piszą, że bez dobrych testów automatycznych, dojrzałej kontroli wersji i szybkich pętli informacji zwrotnej większa liczba zmian prowadzi do niestabilności. Fabryka z założenia zwiększa liczbę zmian, więc te mechanizmy muszą działać, zanim ruszy.

AI w SDLCWdrażanie agentów kodujących

Elementy fabryki oprogramowania AI

W agentowej fabryce oprogramowania agent jest najmniejszym elementem. Każde zadanie przechodzi przez te same stanowiska w tej samej kolejności, a każde stanowisko potrzebuje właściciela w twoim zespole.

1. 1

   Przyjmowanie zadań z pisemną specyfikacją

   Zadanie trafia do fabryki jako issue ze specyfikacją: oczekiwane zachowanie, pliki w zakresie, sposób weryfikacji i to, co jest poza zakresem. Kod sprawdza, czy zadanie się kwalifikuje, na podstawie etykiet, ścieżek i typu zadania, a issue bez specyfikacji zostają u ludzi.

2. 2

   Kolejka i orkiestracja

   Kolejka przechowuje zadania, które się kwalifikują. Orkiestrator startuje uruchomienia, ponawia je w ustalonych granicach i zatrzymuje każde, które przekroczy limit czasu lub budżetu.

3. 3

   Izolowane środowisko dla każdego uruchomienia

   Każde uruchomienie dostaje świeżą przestrzeń roboczą, dane uwierzytelniające ograniczone do zadania i tylko taki dostęp do sieci, jakiego potrzebuje. Nic nie przechodzi z jednego uruchomienia do następnego.

4. 4

   Harness

   Instrukcje, polecenia build i test, narzędzia oraz uprawnienia decydują, co agent widzi i co wolno mu zrobić. W uruchomieniach bez nadzoru uprawnienia przejmują rolę, którą inaczej pełniłby obserwujący inżynier.

5. 5

   Bramki weryfikacyjne

   Testy, ewaluacje dopasowane do zadania i review wykonane przez osobną sesję agenta w świeżym kontekście sprawdzają dokładnie kandydujący commit. Ta sesja dostaje specyfikację, diff i wynik testów, bez historii rozmowy, w której powstała zmiana.

6. 6

   Polityka merge'a w deterministycznym kodzie

   Program porównuje zrecenzowany commit z kandydującym, sprawdza wymagane wyniki i albo prosi człowieka o zatwierdzenie, albo sam wykonuje merge, jeśli typ zadań został do tego dopuszczony. Agent nie ma udziału w tej decyzji. W serwisie GitHub ochrona gałęzi może wymagać zatwierdzających review, zaliczonych status checks na aktualnej gałęzi i merge queue, a jej reguły mogą obejmować także administratorów.

7. 7

   Informacja zwrotna do specyfikacji i harnessu

   Każde odrzucone lub nieudane uruchomienie dostaje zapisaną przyczynę, na przykład niejasną specyfikację, brakujący kontekst, słaby test albo błędne uprawnienie. Poprawka trafia do szablonu specyfikacji, do harnessu albo do nowej kontroli.

Kontrola kosztów, obserwowalność i audyt

• Limity na uruchomienie, na typ zadań i na dzień, egzekwowane poza agentem
• Koszt zaakceptowanej zmiany, liczony z ponowieniami, porzuconymi uruchomieniami i czasem review
• Log każdego uruchomienia: dane wejściowe, polecenia, wywołania narzędzi, wyniki i decyzja polityki
• Ślad audytowy od każdego merge'a do issue, specyfikacji, kontroli i osoby zatwierdzającej

# Illustrative only: one task type, not a specific tool's format
task_type: dependency-patch-update
eligibility:
  labels: [factory, dependencies]
  allowed_paths: [package.json, pnpm-lock.yaml]
  blocked_paths: [.github/, infra/, AGENTS.md]
  max_files_changed: 4
runs:
  max_parallel: 2
  timeout_minutes: 30
  budget_per_run: from measured baseline
gates:
  - build_and_unit_tests
  - integration_tests
  - fresh_context_review
  - reviewed_commit_equals_candidate
merge:
  mode: human_approval    # the owner may switch to checks_only later
  approvers: [payments-maintainers]
on_failure: record_cause_and_requeue_once

Spec driven developmentCode review z AIBezpieczeństwo agentów AI

Równoległe uruchomienia i gotowe workflowy

Fabryka zyskuje większość przepustowości dzięki temu, że kilku agentów pracuje jednocześnie, i właśnie tam najszybciej rosną koszty i obciążenie review. Równoległe uruchomienia pomagają, gdy pracę da się czysto podzielić: niezależne zadania z kolejki albo kilka prób tego samego zadania, z których zostaje najlepsza. Niewiele dają, gdy części zależą od siebie, a przy słabych bramkach każde dodatkowe uruchomienie oznacza dodatkowe review.

Gotowe workflowy przenoszą te wzorce do narzędzi, których inżynierowie już używają. pstack, plugin do Cursora autorstwa Lauren Tan, opublikowany w repozytorium cursor/plugins na licencji MIT, łączy kilka z nich. Jego skille potrafią uruchomić kilka prób tego samego zadania i wszczepić najmocniejsze fragmenty w jedną bazę, rozdzielić pracę między równoległych wykonawców zwracających jeden raport albo kazać recenzentom na różnych modelach atakować diff bez wprowadzania w nim zmian. Skill konfiguracyjny zapisuje regułę, która przypisuje model do każdej roli. Jeden z playbooków prowadzi niezależne pull requesty aż do merge'a: każdy pull request ma jednego agenta jako właściciela, który merguje dopiero po czystym werdykcie równoległych weryfikatorów i wyraźnej zgodzie osoby uruchamiającej playbook.

Wszystko to są instrukcje dla agenta, które same niczego nie wymuszają. To, czy coś trafi do merge'a bez człowieka, zależy od ochrony gałęzi, wymaganych zatwierdzeń, CI i danych uwierzytelniających agenta. Liczbę równoległych wykonawców ustala się dla zadania albo wyprowadza z samej pracy, więc limity równoległych uruchomień i wydatków muszą wynikać z twojej konfiguracji.

• Limit jednoczesnych uruchomień na repozytorium i na zespół
• Model przypisany do roli, wybrany na podstawie wyników na twoich zadaniach
• Koszt zaakceptowanej zmiany dla każdego workflowu, porównany z pojedynczym uruchomieniem agenta
• Limit liczby kandydujących zmian, które recenzent ma przeczytać

Workflowy pstackpstack w CursorKoszty workflowów wieloagentowych

Jaka praca nadaje się na początek

Zacznij od typów zadań, które występują często, są dobrze opisane i dają się sprawdzić maszynowo. Błędny wynik powinien być tani do wykrycia i tani do wycofania.

• Aktualizacje zależności, z przeczytanymi release notes i pełnym przebiegiem testów
• Mechaniczne migracje, na przykład zmieniona nazwa API albo nowy format konfiguracji
• Pokrycie testami kodu, którego zachowanie jest już uzgodnione
• Dobrze opisane utrzymanie: uwagi lintera, ostrzeżenia o przestarzałych API, drobne błędy z testem, który je odtwarza

Pozostała praca zostaje u inżynierów, którzy nadal mogą korzystać z agentów interaktywnie. Niejasna praca produktowa wymaga kogoś, kto odkrywa wymagania w trakcie budowania. Zmiany krytyczne dla bezpieczeństwa, dotyczące uwierzytelniania, autoryzacji, kryptografii albo obsługi sekretów, wymagają człowieka, który weźmie na siebie ryzyko. Decyzje architektoniczne kształtują wszystko, co fabryka zrobi później, więc należą do ludzi, którzy będą utrzymywać efekt.

Lista kontrolna gotowości i co mierzyć

Przed pierwszym uruchomieniem bez nadzoru sprawdzamy repozytorium, w którym fabryka ma pracować. Każdy z poniższych punktów powinien być spełniony.

• Czysty checkout buduje się i testuje jednym poleceniem, w środowisku, którego używa agent
• Testy są na tyle szybkie i stabilne, że niepowodzenie coś znaczy
• Pliki harnessu są w kontroli wersji i mają właściciela, a ich zmiany przechodzą review
• Issue wybranego typu zadań są pisane według szablonu specyfikacji
• Ochrona gałęzi i wymagane kontrole obowiązują wszystkich, także administratorów i konta botów
• Wydatki są przypisywane do uruchomień i ograniczane poza agentem
• Wskazana osoba może wstrzymać fabrykę i wie, jak to zrobić

Co mierzyć

• Zaakceptowane zmiany według typu zadań i odsetek uruchomień, które kończą się taką zmianą
• Czas review na zaakceptowaną zmianę
• Poprawki i reverty w uzgodnionym okresie po merge'u
• Błędy, które przedostały się na produkcję ze zmian z fabryki
• Koszt zaakceptowanej zmiany, z ponowieniami, porzuconymi uruchomieniami i czasem review

Śledź też wskaźniki dostarczania, które twój zespół już mierzy, na przykład change fail rate i deployment rework rate z DORA. Jeśli przepustowość rośnie, a te wskaźniki się pogarszają, fabryka tylko przesuwa problemy na później.

Zacznij od jednego repozytorium, jednego typu zadań i jednej kolejki

1. 1

   Wybierz typ zadań

   Wybierz z listy powyżej typ, który często występuje w jednym repozytorium. Napisz dla niego szablon specyfikacji i zasady kwalifikacji.

2. 2

   Uruchom go pod nadzorem

   Pozwól fabryce otwierać pull requesty, a review każdego z nich zostaw ludziom, tak jak dotąd. Zapisuj, dlaczego każde uruchomienie zostało zaakceptowane, poprawione albo odrzucone.

3. 3

   Usuń przyczyny

   Każde odrzucenie przełóż na zmianę w szablonie specyfikacji, w harnessie albo w kontroli. Uruchom te same zadania ponownie, żeby potwierdzić poprawkę.

4. 4

   Ustal politykę merge'a

   Kiedy wyniki utrzymują się przez uzgodniony czas, właściciel decyduje, czy ten typ zadań może trafiać do merge'a po zaliczeniu kontroli, czy nadal wymaga zatwierdzenia przez człowieka. W obu przypadkach decyzja jest zapisana w kodzie.

5. 5

   Dodaj kolejny typ zadań

   Dopiero wtedy dodaj drugi typ zadań albo drugie repozytorium, każde z własnymi limitami i pomiarami.

Runmill, publiczny projekt naszego założyciela, stosuje zasadę, której trzymamy się u klientów: agent proponuje, a decydują deterministyczne kontrole i ludzie. Bierze kwalifikujące się issue z Linear i uruchamia na nim Claude Code lub Codex w izolowanej przestrzeni roboczej. Dokładnie ten kandydujący commit musi przejść wymagane kontrole i review w świeżym kontekście, zanim zostanie otwarty pull request w serwisie GitHub. O pushach, pull requestach i merge'ach decyduje deterministyczny kod, nigdy agent, a automatyczny merge jest w tym developer preview eksperymentalny.

Runmill w serwisie GitHub

Jak pomagamy

Pracujemy w twoich repozytoriach z inżynierami, którzy będą odpowiadać za fabrykę. Najpierw sprawdzamy, na którym etapie ścieżki jest twój zespół, bo fabryka zbudowana na niezmierzonej konfiguracji dziedziczy jej luki. Potem razem z twoim zespołem platformowym konfigurujemy od początku do końca jeden typ zadań: szablon specyfikacji, harness, izolowane uruchomienia, bramki, politykę merge'a w kodzie, limity kosztów i pomiary.

Co zostaje w twoim zespole

• Szablony specyfikacji i zasady kwalifikacji dla każdego typu zadań
• Pliki harnessu i polityka merge'a w kontroli wersji, każde z właścicielem
• Runbooki do wstrzymywania fabryki, zmiany limitów i dodawania typów zadań
• Pomiary dla każdego typu zadań, w tym koszt zaakceptowanej zmiany

Warsztaty prowadzimy zdalnie albo na miejscu w Niemczech i w Polsce, po angielsku, niemiecku lub polsku, jako sesje zespołowe na twoich własnych repozytoriach. Potem twój zespół platformowy może prowadzić fabrykę i dodawać kolejne typy zadań bez nas.

Harness engineeringEwaluacje na twoich repozytoriachOptymalizacja kosztów LLM