Fabryka oprogramowania AI: czym jest i jak ją prowadzimy

Fabryka oprogramowania AI (AI software factory) to powtarzalny system, w którym agenci AI doprowadzają spisane zadania do sprawdzonego pull requestu, a ludzie wyznaczają cel i decydują, co trafia na produkcję. Agenci budują. Fabryka to wszystko wokół nich: wymaganie, kontrole, podgląd i bramka przeglądu.

Pracujemy jak fabryka oprogramowania: agenci AI wykonują rutynową pracę, seniorzy decydują, co budujemy, i sprawdzają każdą zmianę. Większość naszego kodu pisze AI. Każdą zmianę sprawdza senior i odpowiada za to, co trafia na produkcję. Poniżej wyjaśniamy, co oznacza ten termin, czym różni się jasna wersja od ciemnej, czego potrzebuje fabryka i jak może zacząć zespół od 3 do 30 programistów.

Czym jest fabryka oprogramowania?

Termin ma dwa znaczenia, a wyniki wyszukiwania je mieszają.

Stare znaczenie ma kilkadziesiąt lat. Hitachi nazwało swój dział oprogramowania „software works” już w 1969 roku, a Wikipedia opisuje fabrykę oprogramowania jako „uporządkowany zbiór powiązanych zasobów programistycznych, który pomaga wytwarzać aplikacje”. W praktyce zaczęło to oznaczać firmę, która tworzy oprogramowanie na zamówienie według standardowego procesu: szablony, stałe role, te same kroki w każdym projekcie.

Nowe znaczenie dotyczy agentów AI. CircleCI definiuje ją jako „system, który zamienia intencję inżynierską w oprogramowanie produkcyjne dzięki powtarzalnym, coraz bardziej zautomatyzowanym procesom”. Agenci piszą kod, maszyny go sprawdzają, a ludzie kierują.

Jasna czy ciemna fabryka?

Dan Shapiro zaproponował pięć poziomów AI w programowaniu, od autouzupełniania aż po „dark factory”, nazwaną tak od zakładów, które pracują przy zgaszonym świetle.

Niektóre zespoły mówią, że tak pracują. Simon Willison pisał o zespole AI w StrongDM, którego zasady obejmują „kodu nie mogą pisać ludzie” i „kodu nie mogą sprawdzać ludzie”. Ludzki przegląd zastępują wymaganiami, scenariuszami i rozbudowanymi testami automatycznymi. To poważny eksperyment, który pasuje do zespołów potrafiących mierzyć poprawność niemal wyłącznie maszynowo.

Jasna fabryka ma tę samą automatyzację i dodaje jedno: człowieka, który czyta wynik, zanim trafi na produkcję. To właśnie oznacza tu human in the loop.

Gdzie jesteśmy my? Na pięciu poziomach Dana Shapiro nasza praca dla klientów mieści się między poziomem 3 a 4: agenci piszą kod, a człowiek sprawdza każdą zmianę. Nasz kolega AI doprowadza zadania do pull requestu na poziomie 4, na razie w naszych własnych projektach. Poziom 5, ciemna fabryka, nie jest kierunkiem, w którym chcemy iść.

Dlaczego nie prowadzimy ciemnej fabryki?

Bo oprogramowanie, które budujemy, liczy ceny, wysyła e-maile do klientów i przechowuje dane firmy. Zestaw testów sprawdza to, co ktoś pomyślał, żeby zapisać. Recenzent pyta także, czy zmiana ma sens dla tego biznesu, czy zgadza się z tym, co uzgodniono, i co się stanie, gdy dane będą nieuporządkowane.

Większość naszego kodu pisze AI. Każdą zmianę sprawdza senior i odpowiada za to, co trafia na produkcję. To drugie zdanie to cała różnica między naszą fabryką a ciemną.

Przegląd nie oznacza ręcznego czytania każdej linijki od nowa. Kontrole już się wykonały. Recenzent patrzy na cel, ryzyko, testy i te części, których maszyna nie oceni. Dlatego fabryka potrzebuje małych pull requestów: człowiek dobrze sprawdzi pięćdziesiąt linijek, a dwa tysiące źle.

Czego potrzebuje fabryka oprogramowania AI?

Agenci to łatwa część. Te same modele co wszyscy inni mogą Państwo wynająć już jutro. Fabrykę tworzy linia, po której przesuwa się praca:

• Spisane wymaganie z kryteriami akceptacji. Co ma się zmienić, po czym poznają Państwo, że działa, i co jest poza zakresem. Agent nie czyta w myślach, recenzent też nie. Jak je piszemy, opisujemy w artykule spec-driven development z agentami AI.
• Repozytorium z niezawodną instalacją i kontrolami. Jedno polecenie instaluje, jedno uruchamia testy, jedno buduje. Jeśli nowy programista potrzebuje dnia, żeby uruchomić projekt, agent też sobie nie poradzi.
• Testy, które przed zmianą nie przechodzą, a po niej przechodzą. Nowy test musi być czerwony na starym kodzie, inaczej niczego nie dowodzi. Więcej w artykule red-green TDD z agentami AI.
• Wdrożenia podglądowe. Każdy pull request ma własną działającą wersję, więc recenzent przeklikuje zmianę zamiast ją sobie wyobrażać.
• Bramka przeglądu. Najpierw automatyczny przegląd, potem człowiek. Scala tylko człowiek.
• Małe pull requesty. Jedno zadanie, jedna zmiana, jedna rzecz do sprawdzenia.

Jak łączymy to wszystko, od issue do pull requestu, opisujemy w artykule harness engineering w praktyce. Naszego kolegę AI, agenta, który doprowadza zadania z backlogu do pull requestu, a scala je człowiek, opisuje to case study.

Gdzie fabryka oprogramowania AI się psuje?

Głównie w tych samych miejscach co zespół ludzi, tylko szybciej.

• Niejasne zadania. „Popraw checkout” daje pewną siebie zmianę, o którą nikt nie prosił. Fabryka wzmacnia niejasny cel.
• Niestabilna instalacja. Jeśli testy przechodzą na jednym laptopie, a w CI nie, agent spędza czas na walce ze środowiskiem, a nie z zadaniem.
• Testy pisane po kodzie. Opisują, co kod robi, a nie co powinien robić, i z definicji przechodzą.
• Duże pull requesty. Przegląd zamienia się w przybijanie pieczątki, a człowiek w pętli przestaje nim być.
• Reguły w czyjejś głowie. Konwencje, których nie zapisano w repozytorium, dla agenta nie istnieją. Wspólny plik z regułami rozwiązuje wiele z tego, zob. dobre praktyki Claude Code dla zespołów.

Jak zacząć fabrykę oprogramowania AI w zespole od 3 do 30 programistów?

Proszę zacząć od małej skali i od prawdziwej pracy, a nie od projektu demonstracyjnego. W kolejności, w jakiej zrobilibyśmy to my:

Po kilku tygodniach wiedzą Państwo, gdzie linia się zacina: na wymaganiach, instalacji, testach czy przeglądzie. Proszę najpierw to naprawić, a potem dodać kolejny rodzaj zadań. Fabryka rośnie o jeden niezawodny krok naraz.

Czy Państwa repozytorium jest gotowe na fabrykę oprogramowania AI?

Proszę zaznaczyć, co Państwa zespół ma już dziś.

Chcą Państwo fabryki oprogramowania AI w swoim repozytorium?

Uruchamiamy ją bezpośrednio w repozytorium zespołu w ramach usługi AI-native SDLC dla zespołów deweloperskich: reguły, kontrole, pętlę i bramkę przeglądu, na Państwa prawdziwym backlogu. Wszystko zostaje w Państwa zespole.

Odezwiemy się w ciągu dwóch dni roboczych z kilkoma pytaniami o Państwa pracę. Potem ustalimy, co zrobimy najpierw.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Gdzie dziś zacina się praca w Państwa zespole: na wymaganiach, instalacji, testach czy przeglądzie?

Najczęściej zadawane pytania

Czym jest fabryka oprogramowania AI?

Powtarzalnym systemem, w którym agenci AI doprowadzają spisane zadania do pull requestu przechodzącego automatyczne kontrole, a ludzie wyznaczają cel i decydują, co trafia na produkcję. Fabryka to system wokół agentów: wymagania, niezawodne repozytorium, testy, wdrożenia podglądowe i bramka przeglądu.

Czym jest ciemna fabryka oprogramowania (dark factory)?

Skrajnym końcem skali, w którym żaden człowiek nie pisze ani nie sprawdza kodu: wchodzą wymagania, wychodzi oprogramowanie. Dan Shapiro nazwał ją od fabryk, które pracują przy zgaszonym świetle. Niektóre zespoły twierdzą, że tak pracują. My nie, bo w oprogramowaniu, na którym działa firma, za każdą zmianę odpowiada człowiek.

Czy fabryka oprogramowania to to samo co software house?

W starym znaczeniu mniej więcej tak: firma, która tworzy oprogramowanie na zamówienie według standardowego procesu. Nowe znaczenie opisuje, jak powstaje kod w dowolnym zespole: agenci AI budują, a ludzie wyznaczają cel i robią przegląd.

Czego potrzebuje zespół, zanim uruchomi fabrykę oprogramowania AI?

Spisanych zadań z kryteriami akceptacji, repozytorium, które niezawodnie się instaluje i uruchamia swoje kontrole, testów, które nie przechodzą przed zmianą i przechodzą po niej, wdrożeń podglądowych, bramki przeglądu i małych pull requestów. Bez tego więcej agentów daje tylko więcej niesprawdzonego kodu.

Jak duży musi być zespół?

Nie musi być duży. Zespół od 3 do 30 programistów może zacząć od jednego repozytorium i jednego rodzaju zadań. Bardzo małym zespołom, jedno- lub dwuosobowym, zwykle wystarcza krótki plik z regułami dla agenta, a nie fabryka.