O czym jest ten film
- „Fabryka oprogramowania” to metafora taśmy montażowej: agenci AI produkują aplikacje według powtarzalnego procesu — szybko, ale bez spadku jakości.
- To nie produkt ani konkretne narzędzie, lecz sposób pracy: proces, umiejętności i wiedza domenowa zapisane w kilku plikach Markdown. Całość jest niezależna od modelu i środowiska, w którym pracujesz.
- Fundamentem jest plik AGENTS.md, dołączany do kontekstu każdej rozmowy z agentem — większość ludzi marnuje go na opisywanie kodu, zamiast definiować procedury.
- Krok 1 — izolacja: każda nowa funkcja rusza w osobnym drzewie roboczym gita (worktree) odgałęzionym od main, dzięki czemu wiele agentów pracuje równolegle bez nadpisywania sobie plików.
- Krok 2 — budowanie: umiejętność „code structure” wymusza architekturę warstwy serwisów, czytelną zarówno dla programisty, jak i dla innych agentów.
- Krok 3 — dowód: umiejętności „evidence-driven testing” i „przed/po” każą agentowi pokazać nagranie, zrzuty ekranu albo wyniki testów — bo „działa” bywa równoznaczne z „agent tak twierdzi”.
- Krok 4 — wdrożenie: pętla z agentem do przeglądu kodu (np. Greptile) z oceną pewności; agent sam wraca do budowania, aż ocena sięgnie 5/5. Człowiek klika „merge”.
- Isenberg podsumowuje całość analogią fizycznej fabryki: osobne stanowisko dla zamówienia → taśma montażowa → kontrola jakości → wysyłka.
- Dla osób nietechnicznych przeglądanie pull requestów staje się jak przewijanie relacji: zrzut „przed”, zrzut „po”, decyzja.
- Bonus: automatyczny przegląd kodu (Greptile, CodeRabbit) powinien być standardem — a niektóre startupy to dziś w istocie agent plus kilka plików Markdown.
Redakcyjne tłumaczenie
Wstęp
Greg: Czym są fabryki oprogramowania i dlaczego temat hulają po sieci? Z grubsza: to koncepcja, w której agenci AI tworzą oprogramowanie bez pośpiechu i bez bałaganu — na wzór fabryki, czyli taśmy montażowej. Z tą różnicą że zamiast produktów fizycznych składasz aplikacje. I to jest właśnie marzenie: fabryka wytwarza wartościowe oprogramowanie, a ty odpalasz kolejne aplikacje, które przynoszą przychód i realnie komuś pomagają. Moim zdaniem brzmi to całkiem nieźle.
W dzisiejszym odcinku gości u mnie Mike, który klarownie tłumaczy cały proces. Po obejrzeniu będziesz umieć postawić własną fabrykę oprogramowania. Jest powód, dla którego ta idea święci triumfy — spotkamy się na końcu.
(Informacja dodatkowa: transkrypcja automatyczna zniekształca imię gościa — pojawia się zarówno jako „Ross Mike”, jak i „Mickey”; dla spójności w całym tekście używamy formy „Mike”.)
[Przerwa sponsorska: odcinek promuje Brex — firmowe karty z wysokimi limitami, bankowość i asystenta AI ogarniającego biurową papierologię, np. raporty z wydatków. Według Grega korzystają z niego m.in. Vercel, OpenAI i Anthropic. Link w opisie.]
Czym jest fabryka oprogramowania
Greg: Mike, witaj z powrotem. Czego słuchacze nauczą się w tym odcinku?
Mike: Zrozumieją, co oznacza to dziwaczne hasło „fabryka oprogramowania”, i pokażę, jak działa moja. To prostsze, niż myślisz — i całkowicie niezależne od modelu oraz od środowiska pracy. Żeby mieć fabrykę oprogramowania, nie musisz kupować żadnego produktu. Będzie prosto i przyjemnie.
Greg: Czyli wytłumaczysz, co to jest, dlaczego to ważne, jak to działa i jak o tym myśleć. Na koniec każdy będzie mógł uruchomić własną fabrykę — a komuś się to nie spodoba, ten po prostu przejdzie dalej.
Mike: Sto procent. Przy okazji tego terminu zakwitło sporo startupów i nie chcę nikomu umniejszać, ale fabryka oprogramowania jest w pełni niezależna od narzędzia i modelu. Nie ma znaczenia, na jakim modelu pracujesz ani w jakim środowisku — to po prostu musi działać. Bo fabryka oprogramowania to przede wszystkim czyjś sposób pracy: umiejętności i wiedza o branży, spakowane w konkretne „skille” używane w procesie wytwarzania.
Chcę, żeby każdy przypomniał sobie ostatnią aplikację, którą budował. Pewnie wszedłeś w Codexa, Claude Code, Cursora — cokolwiek — i po prostu pisałeś: „chcę to zbudować”. Agent to złożył. Zobaczyłeś efekt, nie przypadł ci do gustu, kazałeś poprawić. Może tym razem zagrało: wdrożyłeś na Vercela albo na produkcję i po sprawie, albo dalej iterowałeś. I to jest cały proces.
Istota fabryki oprogramowania polega na tym, żeby na każdym etapie tego procesu wycisnąć z modelu maksimum i uzyskać najlepszy możliwy rezultat — a przy tym pracować szybko. Skoro mówimy „fabryka”, to musi być struktura, tempo i taśma, która pozwala wypuszczać produkt najszybciej, jak się da, bez gubienia jakości. I to by była moja długa i rozdęta definicja fabryki oprogramowania. Mam nadzieję, że nikogo po drodze nie zgubiłem.
Greg: Znakomicie. Rozumiem — ale czemu to w ogóle ma znaczenie?
Dlaczego to ma znaczenie
Mike: Bo możliwości modeli stale rosną. Mamy znakomite modele, jak GPT-6 Astra. Dobra fabryka pozwala je usystematyzować i wykorzystywać bardzo sprawnie, zamiast bez końca klepać prompty i odbijać piłeczkę w dialogu z agentem. Zamiast o tym mówić — pokażę ci po prostu moją.
(Informacja dodatkowa: nazwy modeli — GPT-6 Astra, Fable, Astro, GPT-5.6 Soul — podajemy za nagraniem.)
Moje skille są dostępne za darmo, bez żadnych opłat. Ale nie chcę, żebyś mnie kopiował w ciemno. Przemyśl to, zrozum proces i dopiero potem zastosuj u siebie.
Fundament: plik AGENTS.md
Mike: Moja fabryka to jakieś pięć, sześć plików. Pierwszy to AGENTS.md. Dla tych, którzy nie wiedzą: to pojedynczy dokument, plik Markdown, dołączany do rozmowy z agentem przy każdej wiadomości. Piszę „cześć” — i zanim to „cześć” dotrze do agenta, agent dostaje najpierw zawartość AGENTS.md. A fajne w tym pliku jest to, że mogę nim dyktować, jak agent ma się zachowywać.
Robiliśmy niedawno film, w którym mówiłem, że AGENTS.md większości ludzi jest bezużyteczny — bo opisują w nim, jak wygląda kod, czyli rzeczy, które agent i tak odczyta z repozytorium. W moim pliku siedzi natomiast prosty proces pracy. Agent nie ma go we krwi, więc trzeba mu go jasno wytłumaczyć. Przeprowadzę cię przez każdy krok.
Krok 1. Izolacja — każda funkcja dostaje własne stanowisko
Mike: Pierwszy krok: izolacja. Jest skille „new feature” i robi on dokładnie tyle: każda nowa funkcja startuje w świeżym drzewie roboczym gita (worktree) odgałęzionym od głównej gałęzi, żeby agenty mogły pracować równolegle bez konfliktów. Nigdy nie budujemy na main.
A skoro jestem u Grega, to tradycyjnie nie obejdzie się bez diagramów — będziemy rysować. Przedstawmy sobie drogę aplikacji „Greg i Mike”: tu zaczęliśmy promptować, tu weszliśmy na produkcję, dziś mamy tysiące klientów. Większość ludzi pracuje z agentami liniowo: jedna funkcja, potem następna, potem kolejna. A gdy spróbujesz kilku naraz, zaczynają się konflikty: „agent mi usunął plik”, „agent mi nadpisał plik”.
Co robi izolacja? Powiedzmy, że Greg mówi: „nie podoba mi się nasza strona główna”, a ja na to: „nasze wywołania API mogłyby być szybsze”. Gdy Greg rusza ze swoją funkcją, agent — zgodnie z moim AGENTS.md — tworzy nową gałąź. Gałąź to kopia-wklejka dokładnego momentu, w którym znajduje się aplikacja. Greg pracuje na nowym worktree, czyli mówiąc obrazowo: na kopii aplikacji. Wyobraź sobie, że ktoś kopiuje blok tekstu do nowego dokumentu, pracuje na tym dokumencie, a w pewnym momencie wkleja go z powrotem do pierwotnego. Dokładnie to robi Greg: ma nowy dokument i robi w nim swoją funkcję. A ja mam swój. Możemy pracować równocześnie albo osobno — każdy na swojej gałęzi.
I teraz najładniejsze: ja, Greg i ktoś trzeci — albo ty sam z pięćdziesięcioma agentami — możemy pracować nad wieloma funkcjami i żaden agent nie wejdzie drugiemu w pole. Bo jak widzisz wpisy w stylu „pracowałem nad tym, a agent mi masowo poniszczył pliki”, to niemal zawsze dlatego, że ktoś kazał agentom robić różne funkcje na tej samej gałęzi. Agent zrobi dokładnie to, co mu każesz. Kazałeś odświeżyć stronę główną, ale kazałeś też przyspieszyć API. Agent rozgląda się i stwierdza: „te strony wołają API fatalnie, skasuję je i napiszę od nowa” — a tam akurat ktoś dłubał przy designie. I tak rodzą się problemy.
Izolacja pozwala mi pracować nad wieloma funkcjami równolegle, bez ryzyka, że jeden agent nadepnie na robotę drugiego. To pierwszy krok mojego procesu — agentowi nie przychodzi on naturalnie, więc właśnie dlatego ma sens w AGENTS.md. Domykając wątek: gdy kończę, scalam zmiany z powrotem; Greg może to zrobić przede mną albo po mnie. Scalamy do głównego dokumentu i konfliktów nie ma, bo najpierw każdy robił na kopii. Dzięki temu mogę szybko wypuszczać zmiany z wieloma agentami naraz.
Mogę pokazać mój terminal: cztery karty, cztery różne funkcje tej samej aplikacji. Jeden agent robi klienta poczty, drugi środowisko Linuksa, trzeci odświeża stronę główną. Mogę nad tym spokojnie pracować, nie tracąc izolacji. Do tego po scaleniu worktree jest usuwany — sprzątanie dzieje się samo, nie będę w to wchodził. Zatrzymam się tu. Pytania, Greg?
Greg: Jasne jak słońce. Ja to widzę tak: gdybyś miał zespół inżynierów budujących aplikację, to oczywiste jest, że nie kazalibyście wszystkim pchać wprost na main. To nie ma sensu. Jestem nietechniczny i nagle cała masa takich jak ja zaczęła budować aplikacje — i właśnie wpada na ten problem. Ty to rzuciłeś mimochodem, „czasem agenty nadpiszą pliki”, ale prawda jest brutalniejsza: w dziewięćdziesięciu pięciu procentach przypadków agenty coś popsują albo nadpiszą. Więc dla mnie wszystko się klei. I to jest zresztą szersza myśl: jak ułożyć współpracę z agentami tak, żeby przypominała pracę zespołu.
Mike: No właśnie — „zespół” to lepsza nazwa niż „izolacja”. Bo to w gruncie rzeczy to samo.
Greg: Dlatego ja tu jestem od marketingu, a ty od inżynierii.
Mike: „Izolacja” brzmi jak odżywka białkowa. Ale tak to działa: wielu agentów, wiele zadań, wszyscy naraz i bez wchodzenia sobie w drogę.
Greg: W linku niedługo zmiana nazwy.
Krok 2. Budowanie — reguły pisania kodu
Mike: Krok drugi: samo budowanie. Ten skille udostępniałem już dawno temu, teraz jest częścią mojego procesu: „code structure”, czyli struktura kodu. O modelach jeszcze pomówimy, ale jedno już teraz: modele świetnie odwalają robotę — tylko nie zawsze najlepiej. Zwłaszcza w pisaniu kodu. Fable to pierwszy model, który pisze kod tak, że mówię sobie: hm, to jest lepiej niż u niejednego z najlepszych inżynierów, których widziałem. A jednak nawet Astro — mój ulubiony, koń roboczy, najmocniejszy model — podejmuje czasem opłakane decyzje jakościowe. I nie chodzi o brak możliwości: model ma po prostu odhaczyć zadanie, a jeśli da się je załatwić po łebkach, zostanie załatwione po łebkach.
Skille „code structure” każe pisać w tzw. architekturze warstwy serwisów. Nie będę zanudzać teorią — chodzi o to, żeby kod był tak ułożony, iż gdyby trzeba było wprowadzić człowieka, zatrudniony programista błyskawicznie wejdzie w temat; sam programista też się połapie. A już na pewno inne agenty: wracają do takiego kodu i mówią „aha, wszystko tu logiczne”. Miałem GPT-5.6 Soul, który napisał działający kod — robił to, co miał robić. Potem poprosiłem Fable o przegląd i Fable mówi: „to jest obrzydliwe”. Duplikacje, funkcje porozrzucane na wszystkie strony, martwy kod. Czyli: działa, ale nie znaczy, że jest dobrze napisany. Ten skille daje agentowi wytyczne, jak pisać.
Wróćmy do diagramu: robię nową funkcję. Najpierw izolacja, potem budowanie — i mam nadzieję, że dostrzegasz już tę fabryczną logikę. Konkretny przykład: budowałem aplikację — repozytorium skilli, do którego różni moi agenci mają się podłączać i zapisywać swoje umiejętności. Kazałem agentowi to zrobić. Podczas pisania kodu nieprzerwanie sięgał do „code structure” — i wyszło coś, co ja jako programista jestem w stanie przejrzeć. A gdyby, nie daj Boże, przyszło kogoś wynająć do przeglądu, to nie będzie to jedna wielka breja, w której się gubi albo zlicza cię na kasę. Kod jest napisany tak, że programista go zrozumie. Zauważyłem też, że agent bez żadnej znajomości tego kodu ogarnia go bez trudu.
Podsumowując: najpierw izolacja — wybaczcie nazwę — potem budowanie. I wszystko w jednym, zdaniowym stylu: takie wytyczne, które każą agentowi działać szybko i jak najlepiej. Wszystko jasne, Greg?
Greg: Jasne. Mów dalej.
Krok 3. Udowodnij — kontrola jakości bez czytania kodu
Mike: Krok trzeci: udowodnij. Bo agent nie da ci słowa honoru. GPT-6 Astra — właśnie dlatego jest takim skokiem w możliwościach — halucynuje najmniej ze wszystkich modeli, i to jest fantastyczne. Ale poza nim większość da się przycisnąć do kłamstwa albo do uwierzenia w coś nieprawdziwego; czasem agent po prostu sam się przyzna: „w sumie to nie wykonałem tej pracy”. Dlatego każę agentom dowodzić wykonanej roboty. To pewnie mój ulubiony element — a składają się na to dwa skille.
Pierwszy: „evidence-driven testing”, testowanie oparte na dowodach. Jeśli maszyna daje radę, agent nagrywa stan „przed” — powiedzmy, że naprawiasz buga: nagrywa buga w akcji — a po skończonej naprawie nagrywa działającą wersję „po”. I masz czarno na białym, że poprawka faktycznie została wprowadzona. Bo zdziwiłbyś się, jak często agent napisze kod, uzna, że działa, nie przetestuje — i po prostu ci oświadczy, że działa.
Drugi, gdy maszyna nie ma takich możliwości: „before and after”, przed i po. Pokażę pull request (wniosek o scalenie zmian), bo lepiej raz zobaczyć niż sto razy słyszeć. Ten PR zrobił mój agent, nie ja. Chciałem stronę administracyjną poczty podpiętą do mojej usługi mailowej. Popatrz, co zrobił: pokazał stan „przed” — strony po prostu nie było — i stan „po”. Czyli przy każdej funkcji, przy każdym PR-ie dostaję przed i po.
I powiem szczerze, jak to zmienia moją pracę: nie czytam już dziś całego kodu.
Greg: Przeglądasz go pobieżnie.
Mike: I te pobieżne przeglądy robią się coraz pobieżniejsze. Duża część mojej pracy to frontend: pilnuję, żeby trzymał się skille „code structure”, i pilnuję zrzutów przed/po. Mogę pokazać jeszcze jeden, bardziej efektowny przykład. Robiłem funkcję komputera — chciałem dać agentowi komputer — i nie działało. Pierwsze podejście padło. Nie miałem wtedy postawionej fabryki, pracowałem na innej maszynie; agent wrzucił kod — i nic, jak widzisz: zero reakcji. Powiedziałem agentowi: nie działa; użyj skilli, użyj fabryki. I to jest zrzut „po” — agent realnie korzysta z aplikacji.
Te skille — dowód oraz przed/po — każą agentowi przynieść twardy dowód: nagranie albo zrzuty. I bywa tak, że zrobi „przed”, potem „po”, obejrzy i stwierdzi: „patrząc na nagraniu końcowym, funkcji właściwie nie dokończyłem”. Co wtedy? Wraca do budowania. I o to chodzi w fabryce: nie muszę mu mówić „obolałeś przed/po, idź dokończyć”. Skille są napisane tak, że agent sam wie: kryterium przed/po nie jest spełnione, wracam do budowania. Dostaję obrazowy zapis wykonanej pracy, a to upraszcza przegląd — zwłaszcza dla kogoś nietechnicznego: oglądasz zrzuty albo krótkie wideo i masz jasność.
Słyszę już czyjeś pytanie: a co, gdy dowodu nie da się pokazać obrazem? Mam PR-a z wydajności. W jednej z aplikacji kliknięcia nie reagowały żwawo. Dziś, jak widzisz, wszystko działa natychmiast i strony ładują się szybko — ale tak nie było. Kazałem agentowi naprawić. Naprawił i dołączył zrzuty. Gdyby jednak chodziło o coś, czego zrzut nie udokumentuje, napisze test i przyniesie wyniki. Tutaj zmierzył prędkość ładowania strony „przed”: 815 milisekund. W webowym rzemiośle to grzech ciężki, tak nie może być — a kod, uwaga, pisał GPT-5.6 Soul, świetny model. Po poprawce: 61 milisekund. Znów mam od agenta wymierny dowód, że zrobił to, co deklarował. Zatrzymam się tu. Czegoś brakuje, Greg?
Greg: Myślę o zaufaniu. Skoro budujesz fabrykę, zaufanie będzie jej fundamentem — agenci budują funkcje i aplikacje, więc musimy móc ufać temu, co tworzą. A ty pokazujesz umiejętności, dzięki którym ty, jako menedżer agentów… bo taką właśnie pełnisz rolę, prawda? Nie siedzisz już w kodzie po uszy, tylko się rozglądasz, co się dzieje. I fajne w tym „przed/po” jest to, że świetnie pasuje do ludzi przyzwyczajonych do relacji na Instagramie czy Snapchacie. Przewijasz PR-y jak relacje: klik, klik — tak, nie. Małe porcje.
Mike: Dosłownie to. To buduje zaufanie do agenta. I zabawne — powiedziałeś to przed chwilą i mnie olśniło: przecież dokładnie tak działały zwykłe organizacje ze swoimi inżynierami. Budujesz funkcję, a potem ktoś — starszy inżynier — ma w opisie obowiązków przegląd twojej roboty: przychodzi PR z opisem „to zrobiłem, to są testy, które napisałem”. Czyli to samo, tylko teraz robimy to z maszynami. Przykład z wideo: pracuję z agentami Cursor Cloud, jest podpis „dowód ulepszenia” i widać nagranie agenta operującego aplikacją. Oglądam to jak rolkę na TikToku i widzę: dobrze, agent naprawdę to zbudował i działa. Nie muszę czytać kodu — klikam scalenie, żyję swoim życiem, wychodzę na dwór nabrać powietrza.
Krok 4. Wdrożenie — pętla przeglądu kodu
Mike: Został ostatni krok: wdrożenie. O przed/po już mówiłem, ale jest jeszcze skille „Greptile loop”, oparty na zewnętrznej usłudze Greptile — agencie do przeglądu kodu. Nie musisz używać takiego agenta, ale jeśli poważnie podchodzisz do oprogramowania, z którego będą korzystać użytkownicy, mocno polecam jakiś automatyczny przegląd. Greptile to mój faworyt; jest też CodeRabbit i sporo innych dobrych opcji.
Jak to wygląda u mnie? Greptile podsumowuje PR i zgłasza uwagi. Przykład: pierwsza uwaga do jednego z PR-ów — problem z paginacją, nie zachowany odstęp w menu. Czyli agent piszący kod te rzeczy przeoczył. I trudno: ludzie też przeoczają. Ale Greptile nie tylko komentuje — wystawia ocenę pewności. Tu widzisz piątkę, bo uwagi zostały obsłużone (moje imię i ta linijka: zgłoszenia rozpatrzone). Zanim jednak agent się z nimi rozprawił, wynik brzmiał: trójka. A to mówi agentowi jedno: są rzeczy, które przeoczyłeś, więc się im przyjrzyj.
Skille „Greptile loop” — i uwaga, to dzieje się automatycznie, nikt tego nie odpala ręcznie — działa tak: agent otwiera PR z wklejonym w opis dowodem przed/po. Jeśli zmiana ma widoczny interfejs, dostajesz zrzuty albo pary wyników; jeśli nie ma — liczby. A potem patrz: agent uruchamia „Greptile loop apps”, wariant, który sam się włącza przy zmianach rzędu dziesięciu tysięcy linii wzwyż. Nie musisz się nim zajmować. Agent czeka na ocenę Greptile i działa, dopóty nie dostanie piątki i wszystkie uwagi nie zostaną zamknięte; na końcu podaje ci adres PR-a.
Co to znaczy w praktyce? Jesteśmy przy kroku „wdrażaj” i odpala się pętla Greptile. Ocena: trójka. No i co? Pamiętasz, że rozmawialiśmy o pętlach — to jest pętla dobra. Agent zawraca do budowania, czyli do kroku drugiego. Buduje. A potem co robi? Udowadnia. I wdraża. I sam czeka na nową ocenę. Greptile daje czwórkę: coś poprawiliśmy, ale została jedna rzecz. Znów buduje, dowodzi, wdraża — i co, Greg? Piątka. Przy piątce zostaje mi jedno: scalić. Chyba mam otwartego PR-a, mogę pokazać, jak to wygląda — klikam scalenie i zmiana wraca do głównej wersji aplikacji.
A robiłem to wszystko, pracując równolegle nad piętnastoma funkcjami: różne agenty, sub-agenty i tak dalej. I to jest właśnie fabryka. Agent ma wydzieloną instancję, w której pracuje sam; ma wytyczne, jak budować; ma metodę dowodzenia pracy; i ma zewnętrzną usługę, która tę pracę sprawdza — a jeśli nie dotrzymuje standardu, kręci się w pętli, aż standard osiągnie. Kiedy widzę piątkę, na scenę wchodzę ja. To jest fabryka oprogramowania. I zauważ: ani słowa o modelu, ani o narzędziu. Sam proces, skille i odrobina wiedzy domenowej. Nie każdy pracuje tak samo — tak pracuję ja i wyniki mam świetne. Coś jeszcze doprecyzować, Greg?
Podsumowanie: fizyczna fabryka w czterech krokach
Greg: W mojej głowie właśnie składa się w całość analogia prawdziwej fabryki. Streścię, jak ja to widzę, a ty mnie prostuj. Krok pierwszy, izolacja: fabryka przyjmuje zamówienie indywidualne i przydziela mu osobne stanowisko, żeby nie mieszało w reszcie produkcji. W software to worktree, gałąź, wydzielone środowisko — koncept ten sam.
Mike: Zgadza się.
Greg: Numer dwa: budowanie to taśma montażowa. Agent ciągnie, spawa i składa — u nas: pisze kod, zmienia pliki, porządkuje strukturę. Tworzy coś realnego w programistycznym sensie. Krok trzeci, udowadnianie, to po prostu zmyślna nazwa kontroli jakości.
Mike: W zasadzie tak. Zanim cokolwiek wyjedzie z fabryki, ktoś musi to przetestować. Nie wypuszczasz produktu bez sprawdzenia: czy się włącza, czy pasuje, czy pęka pod obciążeniem. Ja obrazuję sobie fabrykę samochodów. W software: uruchamiasz testy, robisz podgląd, czytasz logi, patrzysz na zrzuty — to, co pokazywałem.
Greg: I wreszcie wdrożenie: przeszło kontrolę — wyjeżdża bramą. Ale zostaje parę rzeczy: scalić zmiany, wdrożyć PR-a, napisać notkę wydaniową, oddać uwagę zespołowi produktowemu — a jeśli nie przeszło kontroli, cała pętla rusza od nowa.
Mike: Dokładnie. Serio, jestem pokuszany, żeby przemianować wszystko na twoje nazwy, bo dopiero teraz widzę, że moje są beznadziejne. Ale tak to działa: bierzemy fabrykę i robimy z niej fabrykę oprogramowania. I dlatego — znowu, bez toczenia wojen ze startupami — fabryka oprogramowania nie jest produktem. Nie jest specjalnym narzędziem. Nie jest „tą firmą, która odpaliła jakiś soft”. Fabryka oprogramowania to dosłownie kilka plików Markdown. I przy okazji, temat na osobny film: niektóre startupy to dziś w istocie agent i parę plików Markdown. Naprawdę przyszły takie czasy. Mam nadzieję, że wszystko było zrozumiałe i że to kogoś napędza — mnie obecna chwila bardzo kręci, bo nagle możliwe jest bardzo wiele.
Greg: W stu procentach. To niesamowite, że w ogóle da się tak działać, i dobrze, że ludzie tacy jak ty dzielicie się tym know-how. Jeszcze jedna uwaga o Greptile i innych narzędziach do przeglądu kodu — nie mam tu żadnych afiliacji. Jeśli poważnie myślisz o tworzeniu oprogramowania, nie rozumiem, czemu miałbyś nie używać Greptile, CodeRabbit albo któregoś z tych narzędzi.
Mike: Czegokolwiek. Bo my w biznesie — a wiem, że ogląda nas sporo ludzi z biznesu — traktujemy poważnie usługę, którą sprzedajemy. A tu, przy budowaniu softu, nagle miałoby nas nic nie obchodzić? Skoro twoją aplikacją będą się posługiwać żywi ludzie, mam pewną empatię dla użytkownika po drugiej stronie ekranu. Poza tym wiele z tych firm ma hojne darmowe plany — da się po nich krążyć i sporo skorzystać bez wydatków. Gorąco zachęcam: jeśli budujesz coś, na czym ci naprawdę zależy, używaj jakiegoś agenta do przeglądu kodu.
Greg: Dzięki, że wpadłeś i podzieliłeś się przepisem. W opisie zostawię linki do Mike’a — YouTube, inne miejsca w sieci, no i jego soft. Dajcie mu obserwację. Do następnego, człowieku.
Mike: Doceniam, Greg. Jak zawsze dziękuję wszystkim za serdeczność i oglądanie. Do zobaczenia w następnym odcinku.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Fabryka oprogramowania to proces, nie produkt
Na czym polega: „Fabryka” nie oznacza konkretnej aplikacji ani platformy. To opisany w kilku plikach Markdown sposób pracy — proces, skille i wiedza domenowa — który działa z każdym modelem i każdym narzędziem (Codex, Claude Code, Cursor).
Jak stosować: nie szukaj „fabryki do kupienia”. Weź własny proces wytwarzania (typowo: pomysł → budowa → poprawki → wdrożenie) i dla każdego etapu napisz plik z regułami, które agent ma wykonywać automatycznie.
Na co uważać: cudze skille działają najlepiej po zrozumieniu, po co są. Kopiowanie w ciemno, bez znajomości własnego procesu, łatwo obraca się przeciwko tobie.
2.W AGENTS.md opisuj procedury, a nie wygląd kodu
Na czym polega: zawartość pliku AGENTS.md trafia do kontekstu agenta przy każdej wiadomości. Większość ludzi wypełnia go opisem struktury kodu — czyli informacjami, które agent i tak odczyta z repozytorium. Plik powinien zawierać to, czego agent sam z siebie nie zrobi: proces i standardy.
Jak stosować: zanim zaczniesz nowy projekt, wpisz do AGENTS.md kolejne kroki (izolacja → budowa → dowód → wdrożenie) oraz kryteria uznania zadania za skończone.
Na co uważać: na dryf w stronę encyklopedii. Plik ma być instrukcją operacyjną, nie dokumentacją projektu — tę agent przeczyta sam.
3.Każdą funkcję zaczynaj w osobnym worktree, nigdy na main
Na czym polega: skille „new feature” każdej nowej funkcji każe startować w świeżym drzewie roboczym gita odgałęzionym od głównej gałęzi. Gałąź to kopia aplikacji w danym momencie — praca odbywa się na kopii, a dopiero ukończone zmiany wracają do głównej wersji przez scalenie.
Jak stosować: zlecając agentowi funkcję, dodaj regułę „nigdy nie buduj na main” i każ tworzyć osobny worktree. Po scaleniu kopia jest usuwana, więc nie zostawia śmieci w projekcie.
Na co uważać: doniesienia typu „agent skasował mi pół projektu” biorą się niemal zawsze z pracy wielu agentów na tej samej gałęzi. To błąd organizacji pracy, nie modelu.
4.Wiele agentów naraz — ale jak zespół, nie jak stado
Na czym polega: dzięki izolacji można prowadzić równolegle kilkanaście wątków. W przykładzie z odcinka: cztery karty terminala, cztery funkcje tej samej aplikacji, a w praktyce nawet piętnaście — każdy agent ma swoje „stanowisko” i nie wchodzi drugiemu w drogę.
Jak stosować: dziel pracę na niezależne funkcje i przydzielaj je osobnym agentom. Scalaj kolejno, w dowolnej kolejności — konfliktów nie będzie, bo każdy pracował na kopii.
Na co uważać: równoległość ma sens tylko przy naprawdę niezależnych zadaniach. Jeśli kilka funkcji dotyka tych samych plików, samo rozdzielenie gałęzi nie rozwiąże kolizji — takie prace trzeba ułożyć po kolei.
5.Wymuszaj architekturę czytelną dla ludzi i agentów
Na czym polega: skille „code structure” każe pisać kod w architekturze warstwy serwisów. Efekt: programista wynajęty do pomocy szybko wejdzie w temat, a inny agent — bez żadnej znajomości kodu — łatwo go odczyta.
Jak stosować: zapisz w AGENTS.md wymóg konkretnej architektury i każ agentowi odwoływać się do tej reguły w trakcie pisania, a nie dopiero po wszystkim.
Na co uważać: nawet najlepsze modele dorobią się duplikacji i martwego kodu, jeśli jakość nikomu nie narzucisz. „Model jest zdolny” nie znaczy „model napisze czysto”.
6.„Działa” nie znaczy „napisane dobrze”
Na czym polega: w przykładzie z odcinka GPT-5.6 Soul napisał kod, który działał — a przegląd przez drugi model (Fable) wykazał duplikacje, porozrzucane funkcje i martwy kod. Wykonalność i jakość to dwie różne rzeczy.
Jak stosować: rozdziel te oceny w procesie: jeden etap sprawdza, czy funkcja działa (dowody), a inny — czy kod jest znośny (przegląd, reguły struktury).
Na co uważać: na pokusę wypuszczania wszystkiego, co działa. Dziś oszczędzasz godzinę, a za miesiąc nikt — ani człowiek, ani agent — nie zrozumie własnego projektu.
7.Żądaj dowodu: nagranie albo zrzuty „przed/po”
Na czym polega: agent nie złoży przyrzeczenia — pod presją potrafi twierdzić, że praca jest zrobiona. Umiejętności „evidence-driven testing” i „before and after” każą mu nagrać stan przed zmianą i po niej albo dołączyć zrzuty do PR-a.
Jak stosować: w każdym zleceniu wpisz warunek zamknięcia: „PR zawiera dowód przed/po; bez niego funkcja nie jest uznana za skończoną”. Gdy agent sam stwierdzi, że kryterium nie jest spełnione, zawróci do budowania bez twojej interwencji.
Na co uważać: dowód ma być niezależny od deklaracji agenta — nagranie ekranu, nie obietnica. Sprawdzaj, czy „po” rzeczywiście pokazuje ukończoną funkcję, a nie tylko nieudaną próbę.
8.Gdy efektu nie widać na ekranie, żądaj liczb
Na czym polega: poprawki wydajnościowe nie mają fotogenicznego „przed/po”. W przykładzie z odcinka agent napisał test, zmierzył czas ładowania strony (815 ms przed, 61 ms po) i dołączył wyniki do PR-a.
Jak stosować: dla zmian niewidocznych w interfejsie każ pisać testy i raportować mierzalne wartości przed i po — czas odpowiedzi, liczbę błędów, wyniki całości testów.
Na co uważać: pojedyncza liczba bez punktu odniesienia nic nie znaczy. Zawsze wymagaj pary „przed → po”, inaczej agent udokumentuje sam sukces.
9.Zewnętrzny przegląd kodu zamyka pętlę jakości
Na czym polega: usługa typu Greptile komentuje pull requesty i wystawia ocenę pewności (w przykładzie: od 3/5 do 5/5 po obsłużeniu uwag). Skille „Greptile loop” każe agentowi iterować — buduj, dowodź, wdrażaj — dopóty, dopóki ocena nie sięgnie piątki; przy bardzo dużych zmianach włącza się dedykowany wariant pętli.
Jak stosować: podłącz agenta przeglądowego do repozytorium i opisz w skillach pętlę: PR z dowodami → ocena → poprawki → ponowna ocena. Człowiek wchodzi dopiero przy maksymalnej ocenie.
Na co uważać: nie traktuj oceny jako wyroczni — ostateczna decyzja o scaleniu należy do człowieka, bo automat też bywa zbyt pobłażliwy albo fałszywie surowy.
10.Automatyczny przegląd kodu to standard, nie luksus
Na czym polega: jeśli z aplikacji mają korzystać realni użytkownicy, ręczne „wygląda ok” nie wystarczy. Na rynku jest sporo agentów przeglądowych (Greptile, CodeRabbit), wielu z hojnymi darmowymi planami.
Jak stosować: wybierz jedno narzędzie i włącz je do każdego PR-a od samego początku projektu — tak jak testy, a nie dopiero po pierwszym incydencie.
Na co uważać: na rezygnację z przeglądu z powodów kosztowych. W przykładzie z odcinka darmowe plany wystarczą na start — brak jakiejkolwiek kontroli jakości to brak szacunku dla użytkownika po drugiej stronie ekranu.