O czym jest ten film
- „Fabryka oprogramowania” to według autora nie wielki, szyty na miarę harness, tylko przepływ pracy, umiejętności i wiedza domenowa — zaprojektowane tak, by działały z każdym modelem i każdym narzędziem (Codex, Claude Code, Cursor i inne).
- Dowodem mocy fabryki jest Pluto: autor skasował cały projekt i przebudował go od zera w dwa tygodnie (pierwsza wersja wymagała około miesiąca–półtora). Przy okazji porzucił OpenClaw i postawił własnego agenta na frameworku „e” od Vercela.
- Z tej samej fabryki wyszły m.in. Grokbot z wyspecjalizowanymi agentami (pisarz propozycji, research klientów, pomocnik młodego rodzica), Bezel — serwer MCP dający dowolnemu agentowi narzędzia Pluta, system cyklicznych wpłat dla kościoła oraz organizacja Boring Computers (projekty Rut, Nehemiasz, Ezechiel, Scribe).
- W fragmencie sponsorskim: problemy zbierane w Linearze uruchamiają agenta Cursora w chmurze, który odtwarza bug, naprawia go i nagrywa wideo z dowodem poprawki — a potrafi też sprawdzić, czy zgłoszony błąd w ogóle istnieje. Efekt: ponad 500 zamkniętych PR-ów.
- Trzon fabryki stanowi plik agents.md plus umiejętności: new-feature, code-structure, evidence-driven-testing, before-and-after oraz pętla greptile-loop (i jej rozszerzona wersja dla dużych baz kodu).
- Krok 1 — izolacja: każdy nowy feature startuje w osobnym gitowym work tree odgałęzionym od origin/main, dzięki czemu wiele agentów pracuje równolegle bez kolizji, a gałąź główna pozostaje nietknięta.
- Krok 2 — struktura: umiejętność wymusza architekturę warstwy serwisowej, żeby kod nadal dało się czytać ludzkimi oczami i żeby AI nie mnożyło duplikatów.
- Krok 3 — dowód: testy oparte na dowodach każą agentowi najpierw odtworzyć problem i utrwalić stan „przed”, a umiejętność before-and-after dokleja do PR-a zrzuty ekranu.
- Krok 4 — wydanie: agent otwiera PR, czyta uwagi automatycznego recenzenta Greptile i poprawia kod, aż ocena sięgnie 5/5 bez niezamkniętych komentarzy; dopiero wtedy pokazuje człowiekowi link.
- Autor udostępnia całość na GitHubie i zachęca: skopiuj i przetestuj na przykładowym projekcie, ale potem dostosuj wszystko pod siebie — prawdziwa siła fabryki tkwi w umiejętnościach napisanych pod własny przepływ pracy.
Redakcyjne tłumaczenie
„Fabryka oprogramowania” — czyli nie to, co myślisz
Zbudowałem własną fabrykę oprogramowania. Kiedy słyszysz takie sformułowanie, pewnie widzisz wielki, specjalnie skonstruowany harness — czyli narzędzie, w którym agent pisze kod, na wzór Claude Code czy Cursora. Nic bardziej mylnego. Szczerze mówiąc, porządna fabryka oprogramowania opiera się przede wszystkim na twoim przepływie pracy, umiejętnościach i wiedzy o domenie, a dopiero w drugiej kolejności na samym narzędziu. Taka fabryka powinna być niezależna od harnessu i niezależna od modelu.
Mogę więc pracować w Codexie, w Claude Code, z Grokiem, w jednym bocie czy drugim, z agentem Hermes — z czymkolwiek. Jeśli fabryka jest porządnie poustawiona, wyniki przyjdą niezależnie od tego, jaki model i jakie opakowanie podepnę.
W dzisiejszym filmie pokażę projekty, które powstały dzięki mojej fabryce, i wyjaśnię, jak ona działa — a to oznacza, że po raz pierwszy udostępniam w całości mój plik agents.md oraz moje umiejętności, czyli „skills”: gotowe procedury, które agent wywołuje w konkretnej sytuacji. Pojedyncze pliki pokazywałem już tu i ówdzie, ale teraz oddaję wszystko, od deski do deski. Na końcu pokażę, jak przenieść to do własnej pracy z agentami. Tak, możesz skopiować moje umiejętności. Ale wiesz, co daje więcej? Kiedy zbudujesz własne. Zaczynajmy.
Projekty, które wyszły z fabryki
Kilka fajnych rzeczy, którymi chcę się podzielić. Po pierwsze: wszyscy znacie Pluta, mówię o nim od miesięcy. Ale oto ciekawostka — przebudowałem Pluta w dwa tygodnie. Usunąłem dosłownie wszystko i zbudowałem projekt od zera. Po co zaczynać od tablicy czystej? Przede wszystkim uznałem, że OpenClaw w roli agenta był fatalnym wyborem. Wyrzuciliśmy go i zbudowaliśmy własnego, osobistego agenta na frameworku „e” od Vercela — dedykowany film o tym powstanie; dajcie znać w komentarzach, jeśli chcecie go zobaczyć. Na tym fundamencie postawiłem Pluta na nowo w dwa tygodnie. I to właśnie zasługa fabryki.
(Informacja dodatkowa: OpenClaw to popularny open-source’owy projekt osobistego asystenta AI, na którym Pluto działał w pierwszej wersji.)
Podobnie w Grokbotcie można tworzyć wielu różnych agentów. Mam agenta do pisania propozycji, agenta do researchu na klientów, agenta-pomocnika do spraw dziecka — niedawno zostałem ojcem, więc rzućcie W na czacie. Mogę też zestawić czat grupowy, w którym różni agenci dogadują się między sobą i dopinają robotę, albo rozmawiać bezpośrednio z głównym agentem — „szefem sztabu”, jak sam produkt lubi go nazywać. Daliśmy mu sporo uprawnień: własny komputer, własną piaskownicę, dostęp do systemu plików, własną skrzynkę e-mail. Można mu nawet wydać własną kartę, żeby robił za ciebie zakupy. I oczywiście piszecz z nim przez iMessage. Fajne rzeczy.
Kolejny projekt, który właśnie nabiera rozpędu na Twitterze, to Bezel. Dla nieznających: Bezaleel to postać biblijna z Księgi Wyjścia, mistrz rzemieślnik, którego Bóg napełnił mądrością, by wzniósł pierwszy przybytek. Stąd nazwa — bo z Bezela możesz dać swojemu agentowi, czy to w Codexie, Claude Code czy Cursorze, wszystkie bajery, narzędzia i wszystko to, co czyni Pluta świetnym. W praktyce: masz własnego Pluta na własnym agencie. Działa to tak, że jeden serwer MCP otwiera dostęp do tysięcy konektorów i do własnego klienta poczty; możesz dać agentowi własny komputer, piaskownicę, pamięć, kartę płatniczą. Da się podpiąć konto bankowe i zlecić agentowi prowadzenie budżetu oraz analizę wydatków. Można ustawić iMessage. A najfajniejsze: podłączysz wielu agentów naraz — ja mam spięte Claude Code i Codexa — i osobno wybierasz, które narzędzia trafiają do którego.
(Informacja dodatkowa: w polskich przekładach Biblii postać ta występuje jako Besaleel; MCP to Model Context Protocol — standard łączenia modeli z zewnętrznymi narzędziami i danymi.)
Pracuję też nad systemem płatności dla kościoła: chodzi o to, żeby można było ustawić comiesięczne, dwutygodniowe albo cotygodniowe wsparcie na wybraną kwotę i automatycznie dostawać potwierdzenia dla księgowego, do rozliczenia w zeznaniu podatkowym.
Poza tym mam osobną organizację — Boring Computers. Tam rozwijam Bezela oraz Rut, czyli wersję drugą Pluta. Nehemiasz to nasz mały, firmowy serwer w chmurze; Ezechiel to fork frameworku „e” przystosowany do Cloudflare; a Scribe to własne środowisko telemetrii dla agentów, oparte o OTel, czyli OpenTelemetry. Mówię to wszystko po to, by stwierdzić krótko: panie i panowie — sypię projektami.
Fragment sponsorowany: Cursor Cloud Agents
Nie chcę się przechwalać, ale spójrzcie na tę liczbę: ponad 500 zamkniętych PR-ów, i to w bardzo krótkim czasie — w dużej mierze dzięki Cursor Cloud Agents. Mój przepływ wygląda tak: mamy miejsce, w którym zbieramy zgłoszenia; u nas to Linear. Może być dowolne narzędzie, byle oferowało połączenie MCP. To połączenie uruchamia agenta w chmurze Cursora, a ten wykonuje trzy kroki: odtwarza bug, wprowadza poprawkę i nagrywa film pokazujący poprawkę w działaniu.
Pokażę efekt. Oto podsumowanie jednego PR-a i lista naprawionych rzeczy — ale dla mnie, jako recenzenta, najważniejsze jest co innego: dostaję wideo z poprawką w akcji. Nie muszę wierzyć agentowi na słowo, mam dowód nagrany na oczach widza. W kolejnym PR-ie znowu jest podsumowanie i podpięte nagranie. Ja przeskakuję prosto do filmu, zanim przeczytam cokolwiek innego, bo to ogromna oszczędność czasu. Aktualizowaliśmy na przykład proces onboardingu — widać tam agenta przy pracy.
A teraz coś, co rozniesie wam głowę. Mogę kazać agentowi weryfikować zgłaszane bugi, bo zdarza się, że ktoś zgłasza błąd, który nie istnieje. Oto przypadek, w którym agent potwierdził realność problemu: „wyświetlanie zawieszonego przebiegu”, a dalej w nagraniu — „potwierdzanie zablokowanego czatu”. Błąd potwierdzony. I zgadnijcie, co zrobił potem? Nie tylko go potwierdził — on go jeszcze naprawił. Czyli tym samym agentem mogę i łatać bugi, i sprawdzać, czy błędy zgłaszane przez ludzi faktycznie występują. To wszystko działa, bo stoi za tym potężne narzędzie i potężne środowisko chmurowe: mam pulpit, którym mogę sterować osobiście, aplikację działającą lokalnie oraz dostęp do najnowszych modeli — przełączam się między nimi kilkoma kliknięciami. Jeśli nie używacie Cursor Cloud Agents do zamykania PR-ów tak jak my, to zostajecie w tyle. Link znajdziecie w opisie. Wracamy do filmu.
Anatomia fabryki: agents.md i umiejętności
Fabryka składa się z kilku plików — mam je otwarte w VS Code. Jest plik agents.md. Są umiejętności: „new feature” (nowa funkcjonalność), pętla „greptile loop” oraz jej rozszerzenie „greptile loop apps” — to drugie wchodzi do gry przy dużych bazach kodu, rzędu trzech, czterech, pięciu tysięcy linii. Dalej: „evidence-driven testing” (testy oparte na dowodach), „code structure” (struktura kodu) oraz „before and after” (przed i po). Spójrzmy do środka.
Krok 1: Izoluj — nowy feature w osobnym work tree
Oto przepływ pracy. Krok pierwszy: izolacja. Wywołujemy umiejętność „new feature”. Każda nowa funkcjonalność zaczyna się w świeżym gitowym work tree, odgałęzionym od origin/main, tak aby agenty mogły pracować równolegle i bez konfliktów. Nigdy nie budujemy na main. Ta linijka to jedna z najważniejszych rzeczy w całym agents.md — i zaraz wyjaśnię dlaczego.
(Informacja dodatkowa: git work tree to dodatkowy katalog roboczy podpięty do tego samego repozytorium — dzięki niemu kilka gałęzi może być wybranych jednocześnie, każda w osobnym folderze.)
Wyobraźcie sobie projekt, powiedzmy Bezel. Agenty odblokowały nam pracę nad różnymi funkcjami równolegle. Mamy główną ścieżkę rozwoju — gałąź main. Kto używa gita, zna ten obraz; kto nie używa, po prostu niech nadąża. Chcę zabrać się za pierwszy feature. Umiejętność „new feature” robi kopię istniejącego projektu i wyznacza nową ścieżkę — to właśnie odgałęzienie. Agent buduje funkcję w tej nowej gałęzi i w nowym work tree, nie na mainie. A uroka w tym, że obok może pracować wielu agentów, nad różnymi zadaniami, na różnych etapach — i gałąź główna pozostaje nietknięta.
Bez takiego ustawienia dzieje się co innego: jeden agent pracuje na gałęzi, ty każesz drugiemu zbudować kolejny feature — i ten drugi wchodzi na tę samą gałąź co pierwszy. Zaczynają się zgrzyty: jeden tworzy plik, drugi go kasuje, oba edytują ten sam fragment. Kłopotów wtedy jest mnóstwo. Izolacja pozwala agentowi wydzielić własny katalog roboczy i w nim spokojnie budować. Gdy funkcja jest gotowa, agent scala ją z powrotem do main. Przez cały ten czas mogłem mieć dziesięć innych agentów nad innymi zadaniami — nie wpadną na siebie i niczego sobie nie nadpiszą.
W opisie samej umiejętności czytamy: „Rozpocznij nowe zadanie w odizolowanym gitowym work tree odgałęzionym od origin/main, aby wiele agentów mogło równolegle pracować w tym samym repozytorium bez konfliktów. Stosuj na początku każdego nowego zadania, feature’a czy poprawki — przed napisaniem choćby linii kodu.” Dlatego krok pierwszy to izolacja.
Krok 2: Nadaj kodowi strukturę
Struktura kodu obowiązuje w trakcie budowania funkcji. Umiejętność każe agentowi pisać w architekturze warstwy serwisowej: akcje i ich granice orkiestrują „dlaczego” i „kiedy”, a warstwa serwisów przechowuje wielokrotnego użytku „jak” — z jawnie zadeklarowanymi wejściami i uporządkowanymi wynikami. To po prostu układ, w którym lubię czytać kod: gdyby kiedyś przyszło mi przeglądać go ręcznie, jak to bywało w 2022 roku, będzie napisany tak, że łatwo go strawię. Drodzy programiści — możecie się nie zgadzać z architekturą serwisową i wolić coś innego. Nie w tym rzecz. Chodzi o to, żeby umiejętność była sformułowana tak, żeby powstający kod miał sens właśnie dla was. Dla mnie sensem jest warstwa serwisowa. Poza tym agenty piszą w niej naprawdę dobrze.
W opisie czytamy dalej: „Stosuj, gdy wiele przepływów powiela tę samą logikę operacyjną; gdy zastanawiasz się, co trafi do akcji, a co do współdzielonych serwisów; gdy refaktorujesz powtarzające się bloki operacyjne między procesami domeny; gdy dodajesz funkcje korzystające z mechanik już istniejących.” Zauważyłem bowiem, że AI uwielbia pisać zduplikowany kod i powielać funkcje. Ta umiejętność pilnuje, żeby kod był łatwy w utrzymaniu.
Krok 3: Udowodnij — testy oparte na dowodach
Podsumujmy: najpierw izolujemy zadanie, potem budujemy funkcję zgodnie ze strukturą — agent pisze i pisze. Krok trzeci: dowód. Wywołujemy „evidence-driven testing”: weryfikacja przez odtworzenie problemu plus dowody z czasu wykonania. W praktyce agent najpierw sprawdza, czy zgłoszony bug naprawdę jest bugiem, i utrwala stan „przed” — zanim cokolwiek naprawi, bo wtedy taka weryfikacja kosztuje najmniej — a na końcu stan „po”. Umiejętność odtwarza więc problem, wprowadza poprawkę i nagrywa działające rozwiązanie.
Jedno zastrzeżenie: zadziała to tylko wtedy, gdy wasza maszyna spełnia określone wymagania. Jeśli nie — macie wyjście awaryjne: agent w chmurze albo kolejny krok, „wydanie”. Chcę jeszcze pokazać umiejętność „before and after”. Podkradłem ją wprost z repozytorium Vercela i wpiąłem do swojej fabryki. Opis głosi: „Wykonuje zrzuty ekranu strony lub elementów przed i po, do wizualnego porównania. Stosuj, gdy użytkownik prosi o »przed i po«, porównanie zrzutów itp.” Umiejętność robi zdjęcie stanu przed i stanu po, a potem wkleja oba do PR-a. Przykład: chciałem odświeżyć panel sterowania agentami na dashboardzie — więcej przełączników, zmieniony interfejs. Stan „przed” nie przypadł mi do gustu; stan „po” — gotowe. Przy przeglądaniu PR-ów mam oba obrazki pod ręką i recenzja staje się banalnie prosta. Więc jeśli „evidence-driven testing” u was nie ruszy, każcie agentowi, żeby je odpalił; a gdyby się nie udało — macie „przed i po”.
Krok 4: Wydaj — pętla recenzencka aż do 5/5
Krok czwarty: wydanie. Po „przed i po” wchodzi pętla greptile. Otwórz PR z osadzonym w opisie dowodem „przed/po”: zrzutem lub nagraniem, gdy zmiana ma widoczny interfejs; porównaniem liczb albo par wyników, gdy go nie ma. I dalej: „Uruchamiaj pętlę greptile (lub wersję apps, gdy PR przekracza limit plikowy), dopóki Greptile nie zgłosi pięciu na pięć i zera niezamkniętych komentarzy. Na koniec podaj URL PR-a.”
(Informacja dodatkowa: Greptile to bot do automatycznego przeglądu kodu, który wystawia pull requestom ocenę pewności — piątka oznacza pełne zaufanie.)
To moja ulubiona część — pokażę, jak to wygląda. W przykładowym PR-ie widać ocenę pewności 5/5. Ale zauważcie: to był pierwszy push, pierwsza wersja, i pierwsza recenzja Greptile nie była piątką. Może trójka, może dwójka, może czwórka. Moja fabryka uruchamia pętlę: czeka na ocenę, widzi, że nie ma 5/5, czyta recenzję i wypycha poprawkę. To jest ten drugi push. Greptile recenzuje znowu — wciąż nie 5/5, kolejne uwagi. Agent je czyta, rozwiązuje, wypycha trzeci raz. I proszę: uwag już nie ma, a ocena wskoczyła na piątkę.
Oto PR otwarty właśnie teraz — zmieniamy onboarding. Zrzuty „przed/po” działają na żywo, a ocena pewności właśnie doszła do piątki. Skąd wiem, że „właśnie”? Bo wyżej w wątku widać, że ostatnim krokiem było „PR z przed/po, pętla greptile do 5/5” — czyli agent pracował, czytał uwagi i doszlifowywał, dopóki nie dostał piątki.
Dzięki fabryce nie dostaję PR-ów na dwójkę czy trójkę, z dziurą bezpieczeństwa w środku. Dostaję PR w pełni zrecenzowany przez Greptile. Scenariusz wygląda tak: funkcja gotowa, PR utworzony — ale ja go nie scalam, dopóki nie ma 5/5. Fabryka czyta feedback i pokazuje mi link dopiero, gdy piątka jest pewna. Wtedy ja oglądam „przed i po”, czytam opis i scalam. A gdy to wszystko dzieje się z wieloma agentami, nad wieloma funkcjami, w wielu narzędziach naraz — widać, jak szybko można pociągnąć projekt o jasno zakreślonych granicach.
Wiem dokładnie, jak wszystko ma wyglądać. A nawet gdybym coś zepsuł i chciał przebudować projekt od nowa — pierwotne doprowadzenie Pluta do stabilnej wersji zajęło mi miesiąc, może półtora, i to bez fabryki. Wersja druga ruszyła po tygodniu i pół, a dwa tygodnie zeszły na szlif. Teraz zostało już tylko marketing i planowanie — produkt jest dosłownie gotowy. I to dlatego, że fabryka nie zależy ani od narzędzia, ani od modelu: odpalę ją w Codexie, w Cursorze, w Claude Code, w czym chcecie. Z Antigravity raczej nie zadziała, bo Gemini jest po prostu fatalny — więc z Antigravity nie próbujcie.
Gdy bierzecie mój plik agents.md, który instruuje agenta, jak korzystać z każdej mojej umiejętności, nieuchronnie dostajecie fabrykę produkującą feature’y na piątkę — gotowe do waszych testów i scalenia. To właśnie jest fabryka oprogramowania.
Jak zacząć: skopiuj, a potem zbuduj własne
Od czego zacząć? Wejdźcie na moje GitHubowe repozytorium „skills” — link w opisie filmu. Skopiujcie zawartość, dajcie ją agentowi i zbudujcie przykładowy projekt. Zobaczcie, jak to wam podchodzi. A potem poprawcie wszystko pod siebie i pod swój przepływ. To nie powstało z dnia na dzień — trwały to tygodnie i miesiące przyglądania się, jak pracuję i co robię powtarzalnie. Na przykład zauważyłem, że po każdym otwarciu PR-a zawsze ręcznie odpalałem pętlę greptile. Dziś to część fabryki: nie muszę nic uruchamiać, bo agent zrobi to sam. Skąd wie? Bo jest zapisane w agents.md.
Kilka reguł, które trzymam w tym pliku: nigdy nie commituj wprost na main; jeden work tree i jedna gałąź na zadanie i na agenta; nigdy nie ruszaj cudzego work tree, cudzej gałęzi ani niescommitowanej pracy innego agenta — dopiero wtedy agenty naprawdę pracują równolegle. Przed startem zbadaj zakres: przejrzyj otwarte PR-y i listę zmienianych plików. Nigdy nie rób force push na main. Ogarniaj konflikty w plikach lock. W work tree nie izoluj zasobów współdzielonych. Plus instrukcja, jak poprawnie domknąć zadanie. Tyle informacji dajecie agentowi — a on, wyposażony w te umiejętności, zacznie wam „gotować” feature’y w najwyższej możliwej jakości.
Zakończenie
Tyle o mojej fabryce oprogramowania. Dałoby się mówić dalej, ale tu chcę urwać. Napiszcie w komentarzach, co myślicie i czy chcecie więcej materiałów na ten temat. Mam do was wyzwanie: pobierzcie to wszystko i naprawdę zbudujcie z tym coś — a potem podzielcie się wrażeniami. Dajcie like’a, komentarz, subskrypcję i włączcie dzwoneczek. Właśnie przekroczyliśmy sto tysięcy subskrypcji — dziękuję, to spełnienie marzeń. Niech was Bóg błogosławi. Przygotowuję jeszcze coś specjalnego, dajcie mi tylko chwilę: niedawno urodziło mi się dziecko, więc byłem mocno zajęty. Do zobaczenia w następnym filmie. Trzymajcie się.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Fabryka to przepływ pracy, a nie narzędzie
Na czym polega: Wartość „fabryki oprogramowania” tkwi w plikach instrukcji (agents.md, umiejętności) i wiedzy o własnej domenie, nie w konkretnym harnessie czy modelu. Dobrze zaprojektowany zestaw jest przenośny między Codexem, Claude Code i Cursor’em.
Jak stosować: Buduj przepływ tak, by dało się go odpalić w dowolnym narzędziu: reguły trzymaj w plikach, które kopiujesz między projektami, a nie w ustawieniach jednej aplikacji.
Na co uważać: Wymiana modelu czy narzędzia nie naprawi wadliwie zaprojektowanego przepływu — jeśli agent nie wie, jak ma pracować, nowy harness niczego nie zmieni.
2.Nigdy nie buduj na main — izoluj każdy feature
Na czym polega: Każde nowe zadanie startuje w osobnym gitowym work tree odgałęzionym od origin/main; dopiero ukończoną i sprawdzoną pracę scala się z powrotem.
Jak stosować: Zapisz w umiejętności „new feature” regułę: świeży work tree przed napisaniem pierwszej linii kodu, scalenie dopiero po przedstawieniu dowodów i recenzji.
Na co uważać: Izolacja wymaga dyscypliny — jeden niepilnowany agent commitujący wprost na main potrafi zepsuć pracę wszystkich pozostałych, pracujących równolegle.
3.Jeden agent, jedna gałąź, jeden work tree
Na czym polega: Równoległość wielu agentów jest bezpieczna tylko wtedy, gdy żaden nie wchodzi na teren innego: nie modyfikuje jego gałęzi, katalogu roboczego ani niescommitowanych zmian.
Jak stosować: W agents.md zapisz to wprost jako regułę „jeden work tree i jedna gałąź na zadanie na agenta” wraz z zakazem dotykania cudzej pracy.
Na co uważać: Nawet przy izolacji trzeba pilnować zasobów współdzielonych i plików lock (np. zależności) — właśnie tam równoległe agenty nadal mogą wchodzić sobie w drogę.
4.Wymuszaj architekturę kodu przez umiejętności
Na czym polega: Umiejętność „code structure” każe agentowi pisać w konkretnym układzie (u autora: warstwa serwisowa), dzięki czemu kod pozostaje czytelny dla człowieka, a AI nie mnoży duplikatów.
Jak stosować: Wybierz architekturę, którą sam dobrze czytasz, i opisz ją w umiejętności — wraz z sytuacjami użycia: powielona logika operacyjna, refaktoring powtarzających się bloków, nowe funkcje oparte na istniejących mechanikach.
Na co uważać: Nie przejmuj bezrefleksyjnie cudzych preferencji architektonicznych — umiejętność ma sens tylko wtedy, gdy odpowiada waszym konwencjom i temu, jak będziecie kod później przeglądać.
5.Dowód zamiast obietnic: najpierw odtwórz, potem napraw
Na czym polega: Testy oparte na dowodach każą agentowi najpierw odtworzyć zgłoszony problem i utrwalić stan „przed”, zanim cokolwiek zmieni — widać wtedy, że błąd był realny i że poprawka działa.
Jak stosować: W umiejętności zapisz kolejność: reprodukcja problemu, zrzut lub nagranie stanu przed, poprawka, nagranie rozwiązania w działaniu — z dowodami wklejonymi do PR-a.
Na co uważać: Automatyczne odtwarzanie i nagrywanie wymaga odpowiedniego środowiska (lokalnie lub w chmurze) — miej plan awaryjny na wypadek, gdyby twoja maszyna nie dała rady.
6.„Przed i po” w PR-zie skraca recenzję do sekund
Na czym polega: Zrzuty ekranu — albo porównanie liczb, gdy zmiana nie ma interfejsu — osadzone w opisie PR-a pozwalają ocenić efekt bez uruchamiania kodu.
Jak stosować: W kroku wydania każ agentowi zawsze doklejać dowód wizualny lub metryczny, zanim ktokolwiek zacznie czytać opis zmiany.
Na co uważać: Screeny pokazują wygląd, a nie poprawność logiki — to uzupełnienie testów i recenzji maszynowej, nie ich zamiennik.
7.Pętla recenzencka: agent poprawia sam, aż dostanie 5/5
Na czym polega: Agent czyta uwagi automatycznego recenzenta (np. Greptile), wprowadza poprawki i wypycha kolejne zmiany, dopóki ocena nie sięgnie maksimum, a wszystkie komentarze nie zostaną zamknięte. Dopiero wtedy melduje człowiekowi URL PR-a.
Jak stosować: Zapisz warunek domknięcia wprost w umiejętności: „nie zgłaszaj PR-a, dopóki recenzent nie wystawi 5/5 bez uwag” — i pozwól agentowi iterować.
Na co uważać: Ocena bota to nie gwarancja bezbłędności — przed scaleniem i tak przeczytaj opis i obejrzyj dowody; pętla potrafi też „załatwić” uwagi kosmetyczne, pomijając istotne.
8.Automatyzuj to, co robisz powtarzalnie
Na czym polega: Fabryka autora wyrasta z obserwacji własnych nawyków: ręczne odpalanie pętli recenzenckiej po każdym PR-zie przerodziło się z czasem w regułę zapisaną w agents.md.
Jak stosować: Przez kilka tygodni notuj czynności wykonywane przy każdym zadaniu (izolacja, testy, recenzja, raport), a potem przenieś je do plików umiejętności.
Na co uważać: Nie automatyzuj wszystkiego naraz — zacznij od jednej, najczęściej powtarzanej czynności, sprawdź ją na małych zadaniach i dopiero potem rozszerzaj.
9.Kopiuj cudze umiejętności, ale buduj własne
Na czym polega: Autor udostępnia komplet plików i wprost mówi: skopiuj i przetestuj na przykładowym projekcie, ale prawdziwa siła tkwi w procedurach napisanych pod własny przepływ i domenę.
Jak stosować: Traktuj czyjś zestaw jako szkielet: uruchom go na małym projekcie, zobacz, gdzie nie pasuje do waszej rzeczywistości, i podmieniaj kolejne elementy na własne.
Na co uważać: Bez zrozumienia, dlaczego dana reguła istnieje, skopiowany zestaw może szkodzić — choćby wymuszając architekturę, której wasz zespół w ogóle nie stosuje.
10.Jasny zakres plus fabryka to tygodnie zamiast miesięcy
Na czym polega: Przebudowa Pluta od zera zajęła autorowi około tygodnia i pół plus dwa tygodnie szlifu — wobec miesiąca, półtora w pierwszej wersji bez fabryki. Kluczem były dobrze określony zakres i powtarzalny przepływ.
Jak stosować: Zanim wypuścisz wielu agentów, zdefiniuj, co dokładnie ma powstać i jakie dowody ukończenia będą obowiązywać — wtedy równoległość przekłada się wprost na tempo.
Na co uważać: Fabryka przyspiesza realizację znanego zakresu, a nie jego ustalanie; przy mglistych wymaganiach wielu równoległych agentów mnoży chaos zamiast efektów.