Jak jednoosobowo prowadzę biznes modułów PrestaShop z flotą agentów AI

Kilka miesięcy temu odkryłem, że moi agenci AI zostawili 154 repozytoria Git ze zmianami w drzewie roboczym - i rozwiązaniem nie był lepszy prompt, tylko struktura organizacyjna.

Nie 154 pliki. 154 repozytoria. Dziesiątki repozytoriów z modułami, w każdym niezatwierdzone zmiany nałożone jedna na drugą - część to niedokończone eksperymenty, część to naprawdę dobra praca, która po prostu nigdy nie została wypuszczona. Różni agenci, uruchamiani w różnym czasie, robili po kawałku i szli dalej. Nikt tego nie commitował. Nikt nie sprzątał. Ta praca właściwie nie przepadła. Było gorzej: była splątana. Była splątana, a ja nie potrafiłem już powiedzieć, czyje ręce czego dotykały.

Naturalny odruch, kiedy agent AI zrobi coś głupiego, to poprawić prompt. Dopisać linijkę. "Zawsze commituj pracę, kiedy skończysz." "Nigdy nie zostawiaj repozytoriów dirty." Próbowałem. To się nie trzyma - a kiedy zrozumiesz dlaczego, zmienia się cały sposób pracy z tymi narzędziami.

To jest opis tego, jak naprawdę prowadzę sklep: jedna osoba, katalog znacznie ponad stu rozszerzeń PrestaShop publikowanych w sześciu językach, plus kilka prawdziwych sklepów internetowych, które sam prowadzę na tych samych modułach. Duża część powtarzalnego budowania i supportu przechodzi przez flotę agentów AI - zawsze pod moją kontrolą; architektura, decyzje release'owe i ostateczna akceptacja zostają u mnie. Dalej jest ta część, której nikt nie wkłada na stronę sprzedażową - konkretne błędy, które ci agenci zrobili, i mechanizmy, które zbudowałem, żeby nie mogli zrobić ich drugi raz.

Agent jest genialnym pracownikiem z całkowitą amnezją

Model myślenia, który naprawdę działa, jest taki: agent AI to autentycznie świetny wykonawca - szybki, oczytany, niestrudzony - który ma zero pamięci, że kiedykolwiek wcześniej dla ciebie pracował. W każdej sesji przez drzwi wchodzi genialny nieznajomy. Nigdy nie widział twojego kodu. Nie zna twoich konwencji. Nie wie, że rzecz, którą zaraz zrobi, zepsuła produkcję w zeszłym miesiącu, bo jego przy tym nie było. Z punktu widzenia jego pamięci nikogo przy tym nie było.

Nie naprawisz tej osoby sprytniejszym zestawem instrukcji na wejściu. Prompt jest rozmową. Wyparowuje, kiedy sesja się kończy. Potrzebujesz tego, co buduje każda prawdziwa organizacja, żeby nie zależeć od pamięci jednej osoby: trwałej, spisanej i egzekwowanej wiedzy instytucjonalnej. Dokumentacji wdrożeniowej. Runbooków. Checklisty pre-commit przypiętej do ściany. Barier, które fizycznie utrudniają zły ruch.

Nie piszę lepszych promptów. Piszę lepszą pamięć. Amnezja jest droga tylko wtedy, gdy każesz agentowi uczyć się wszystkiego od nowa za każdym razem, gdy wchodzi.

Rzemiosłem nie jest więc prompt engineering. Rzemiosłem jest zbudowanie organizacji wokół amnezyka. A najważniejsze odkrycie, jakie miałem, brzmi tak: każda bariera w moim setupie jest blizną. Prowadzi do jednego konkretnego, datowanego momentu, w którym agent zrobił coś źle, ja poczułem ból, a potem zamieniłem ten ból w regułę, którą środowisko egzekwuje już zawsze. Moja konfiguracja nie jest listą życzeń. To historia choroby.

Oto blizny.

Blizna #1: Agent, który wyczyścił folder vendor i położył sklep

Część moich modułów zależy od współdzielonych bibliotek wewnętrznych - kodu, którego używam w całym katalogu. Z powodów wdrożeniowych te biblioteki mieszkają w folderze vendor/ każdego modułu, ale są tam kopiowane skryptem synchronizującym, a nie zarządzane przez normalny menedżer pakietów. To nietypowy układ i agent z amnezją nie ma skąd o nim wiedzieć.

Pewnego wieczoru zeszłej jesieni agent musiał więc dodać zależność i zrobił rzecz podręcznikowo poprawną: uruchomił composer install. Menedżer pakietów spojrzał na manifest, zobaczył stertę plików w vendor/, których sam tam nie położył, i uprzejmie je usunął. Klasy zniknęły. Live sklep zaczął rzucać 500, gdy tylko klient wszedł na stronę autoloadującą jeden z brakujących traitów.

Agent nie mylił się według własnej logiki. Mylił się, bo nie miał mojej pamięci. Tego nie da się niezawodnie rozwiązać promptem - "uważaj z composerem" to dokładnie ten rodzaj miękkiej instrukcji, o której agent zapomina pod presją. Poprawką nie jest więc zdanie. Poprawką jest ściana:

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Teraz ten błąd jest niedostępny. Świeży agent bez pamięci awarii nadal nie może jej odtworzyć, bo środowisko mówi "nie", zanim powstanie szkoda. Na tym polega różnica między promptem a blizną: prompt ma nadzieję; blizna egzekwuje. Mam już małą bibliotekę takich hooków i każdy z nich to popołudnie, którego nie odzyskam.

Blizna #2: 154 dirty repozytoria

Wróćmy do otwarcia. Splątanie powstało dlatego, że rozwiązałem inny problem - uruchamianie wielu agentów równolegle - bez zbudowania warstwy koordynacji, której równoległość naprawdę potrzebuje.

Uruchomienie jednego agenta to rozmowa. Uruchomienie floty to logistyka, a logistyka jest zestawem problemów, których żaden prompt nie rozwiąże:

• Throttlują i wiszą. Odpal pięć ciężkich zadań naraz, a zaczną się piętrzyć, stawać i wpadać w timeouty. Rozwiązaniem była infrastruktura: runner, który kolejkuje i równoważy zadania między równoległymi workerami oraz zakłada watchdog na każdy run, żeby duże użycie równoległe nie zapychało się ani nie zamierało. Agenci nie zarządzają własną przepustowością. Organizacja robi to za nich.
• Wchodzą sobie w drogę. Dwóch agentów edytujących ten sam moduł w tym samym momencie niszczy sobie nawzajem pracę. Rozwiązaniem jest lock pliku per moduł - agent bierze moduł, pracuje, zwalnia go. Z jednym dodatkiem, którego nauczyłem się boleśnie: lock, którego proces właściciel umarł, nie jest aktywną pracą, tylko śmieciem. Dlatego lock sprawdza, czy jego właściciel nadal istnieje, i automatycznie czyści stare blokady. System koordynacji, który deadlockuje się na duchach, jest gorszy niż brak systemu.
• Commitują cudze pranie. To była prawdziwa przyczyna 154. Agent kończący własne zadanie uruchamiał odpowiednik "commit everything" - i zgarniał do tego samego commita niedokończoną pracę trzech innych agentów. Dlatego ścieżka commita dostała bramkę: agent może stage'ować tylko swoje własne pliki, nigdy hurtowe "add everything". Dosłownie nie może zacommitować pracy, której nie zrobił.

Żaden z tych trzech punktów nie jest sprytny. To nudna mechanika działającego miejsca pracy: odbij kartę, nie dotykaj biurka, przy którym ktoś jest w środku projektu, nie podpisuj odbioru paczki, która nie jest twoja. Musiałem zbudować każdy z nich, bo konkretny agent konkretnego dnia zrobił odwrotnie.

Koordynacja ma umożliwiać domykanie pracy, a nie ją zamrażać. Locki są po to, żeby dwóch agentów nie edytowało jednego pliku naraz - nie po to, żeby zmieniać "skończoną pracę" w "zamrożoną pracę". Commit jest checkpointem, nie klatką.

To ostatnie zdanie jest ważniejsze, niż wygląda. Pierwsza wersja mojego lockowania była zbyt surowa i agenci zaczęli siedzieć bezczynnie, czekając na locki, które nie należały już do nikogo. System bezpieczeństwa, który zatrzymuje domknięcie pracy, nie jest bezpieczeństwem - jest po prostu inną awarią. Teraz zasada brzmi: koordynacja ma robić kończenie łatwiejszym niż niekończenie, albo projektuję ją od nowa.

Blizna #3: Nigdy nie pozwól agentowi uczyć się na sklepie klienta

To jedyna reguła, na której bolesne zasłużenie nie czekałem. Na początku agent "tylko coś sprawdził" na live sklepie - i dziesięć sekund zanim potwierdziłem, że nic faktycznie się nie zmieniło, wystarczyło, żeby zasada stała się nienegocjowalna: agenci budują i testują najpierw na jednorazowej kopii, a czegokolwiek widocznego dla klienta dotykają dopiero po udowodnieniu zmiany.

Świeży agent nie ma instynktu, w jakim środowisku stoi. Dla niego shell to shell. Więc środowisko robi rozróżnienie za niego: ryzykowne operacje domyślnie trafiają do jednorazowych klonów, produkcja jest traktowana jako osobne, chronione miejsce, a destrukcyjne z przyzwyczajenia komendy uruchamiane na dev boxie (wyczyszczenie katalogu cache, reset stanu) są blokowane albo przekierowywane na wszystkim, co widzi prawdziwy klient. Agent nie musi pamiętać różnicy między "moim sandboxem" a "czyimś sklepem". Organizacja pamięta za niego.

To jest ta jedna bariera, o której chciałbym, żeby klient wiedział, bo to ona chroni jego. Powód, dla którego aktualizacja modułu rzadko przychodzi z niespodzianką, jest taki, że zmiany widoczne dla klientów przechodzą pełną próbę generalną - na jednorazowym sklepie, gdzie pomyłka nic nie kosztuje - zanim trafią do release'u.

Blizna #4: Niech psuje się głośno, nie grzecznie

Pozostawiony sam sobie pomocny agent przykryje problem. Czegoś, czego oczekiwał, nie ma, więc po cichu podstawia default, owija wywołanie fallbackiem "na wszelki wypadek" i idzie dalej. Zadanie wygląda na udane. W sklepie klienta cichy workaround jest gorszy niż widoczny błąd - bo widoczny błąd zostaje naprawiony dzisiaj, a cichy trafia do wydania i czeka.

Stała instrukcja jest więc odwrotnością odruchu: kiedy coś jest źle, wywal się głośno. Nie wymyślaj fallbacku, żeby ukryć brakujący element. Nie dodawaj defensywnej waty, która zmienia błąd w subtelnie złą odpowiedź. Pokaż go, zatrzymaj się i pozwól człowiekowi zdecydować. W połączeniu z zasadą dev-first oznacza to, że brzydkie awarie dzieją się w sali prób, gdzie brzydota jest dokładnie tym, co chcesz zobaczyć, a celem jest, żeby klienci widzieli ujęcie, które wyszło, nie te, które nie wyszły.

Część, która czyni to wszystko tanim: pamięć robiona celowo

Blizny powstrzymują agentów przed psuciem rzeczy. Ale nawyk, który czyni całą operację ekonomiczną, to ten, który zmienia amnezję z podatku w błąd zaokrąglenia.

Naiwny sposób używania agenta do powtarzalnego zadania to tłumaczyć mu je za każdym razem od nowa. Ponownie dołączać przykładowe pliki. Ponownie opisywać kroki. Ponownie ustalać, które ścieżki są ważne i które pułapki gryzą. Płacisz pełną cenę, w tokenach i w czasie zegarowym, za wiedzę, którą odkryłeś już w zeszłym tygodniu. To amnezyk uczący się każdego ranka od nowa dróg ewakuacyjnych w budynku.

Dlatego wprowadziłem regułę dla samych agentów: na końcu zadania napisz notatkę. Nie wpis do pamiętnika - operacyjną notatkę. Gdzie leżą istotne pliki. Dokładną sekwencję, która zadziałała. Jedną nieoczywistą rzecz, o którą potknie się następny run. Te notatki żyją w uporządkowanym drzewie, a - i to jest część, której ludzie nie zauważają - istnieje jednolinijkowy indeks każdej notatki, ładowany na samym początku każdej sesji. Amnezyk wchodzi, czyta spis treści i od razu wie, co firma już wie oraz gdzie tego szukać.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

To cała teza w jednym nawyku. Sprytny prompt poprawia ten run. Spisana notatka obniża koszt każdego przyszłego runu, niezależnie od tego, który agent go podniesie. Pamięć instytucjonalna się kumuluje; prompty nie. Pierwszy raz, kiedy robię tu cokolwiek, jest drogi. Dziesiąty kosztuje prawie nic, i jest tani właśnie dlatego, że pierwszych dziewięć zapisało, czego się nauczyło.

Jak naprawdę wygląda zadanie przechodzące przez ten system

Złożone razem rutynowe zadanie działa jak mały, dobrze wyćwiczony zespół, a nie jak sesja z chatbotem:

1. Agent czyta indeks, wyciąga notatkę dla tego typu zadania i zaczyna większość drogi do celu już za sobą, zamiast od zera.
2. Bierze lock na moduł, którego zaraz dotknie, żeby nic innego nie mogło z nim kolidować.
3. Pracuje na jednorazowej kopii. Jeśli coś jest nie tak, wywala się głośno tam - nie na live sklepie.
4. Kiedy próbuje skończyć, bariery trzymają: nie może uruchomić komendy, która kiedyś wyczyściła folder vendor, i może commitować tylko własne pliki, nie półgotową pracę leżącą w repo obok.
5. Zapisuje, czego się nauczył, żeby notatka była trochę ostrzejsza dla następnego agenta - może zupełnie innego.

Zwróć uwagę, jak mało w tym "promptowania". Prompt to jedna linia: zrób zadanie. Wszystko, co czyni je bezpiecznym, szybkim i powtarzalnym, mieszka w środowisku, nie w wiadomości. To cały trik.

Bilans dobrego i złego, czyli dlaczego każde "dobre" znaczy po prostu "ma pamięć"

Ludzie pytają mnie o wskazówki, jak efektywnie używać AI, spodziewając się sztuczek z promptami. Prawdziwa lista jest nudniejsza i dużo bardziej użyteczna, a każdy punkt jest tą samą ideą w innym ubraniu - daj amnezykowi pamięć i przygotowany warsztat:

• Źle: wkleić kod do darmowego chatbota i ręcznie przekopiować odpowiedź z powrotem. Dobrze: uruchamiać agentów tam, gdzie mieszka praca - na maszynie, z prawdziwym dostępem do plików i narzędzi - żeby nie trzeba było opisywać niczego, co można po prostu przeczytać.
• Źle: bałagan na dysku, gdzie każde zadanie zaczyna się od tego, że agent szuka, gdzie co leży. Dobrze: uporządkowane drzewo materiałów, więc "znajdź rzecz" jest lookupem, a nie wyprawą.
• Źle: agent grepuje cały dysk i czyta dwadzieścia plików, żeby znaleźć jedną funkcję. Dobrze: przygotować warsztat - szybkie wyszukiwanie i connectory, które pozwalają mu pytać bazę danych, przeglądarkę i uruchomione kontenery bezpośrednio, zamiast zgadywać.
• Źle: za każdym razem odtwarzać od zera to samo wieloetapowe zadanie. Dobrze: wielorazowa notatka i indeks, który ją podsuwa.
• Źle: jeden agent do wszystkiego. Dobrze: routować pracę - model lepszy w ostrożnym rozumowaniu backendowym dostaje backend; ten z lepszym wyczuciem interfejsu i słów dostaje te rzeczy. Tak samo jak obsadza się zespół według mocnych stron.

Nieznajomy z amnezją w dobrze prowadzonym budynku - opisane półki, jasny podręcznik, ostre narzędzia pod ręką i osłony na niebezpiecznych maszynach - jest zdumiewająco produktywny. Ten sam nieznajomy wrzucony do zagraconego pokoju z mglistym ustnym briefingiem jest ryzykiem. Ten sam pracownik. Różnica to w całości organizacja.

Gdzie AI pomaga, a gdzie ludzka kontrola nadal wygrywa

Po tym wszystkim mam dość ostre poczucie granicy.

AI wygrywa w tym, co mechaniczne, równoległe i dobrze zamknięte. Przeciągnięcie zmiany przez dziesiątki modułów. Napisanie pierwszej wersji czegokolwiek. Wyciąganie i przekształcanie danych strukturalnych. Ponowne uruchomienie przygotowanego workflow z notatki. Badanie upierdliwego błędu z większą cierpliwością, niż ja mam o 6pm. Kiedy zadanie ma poznawalną poprawną odpowiedź i ścieżkę dojścia do niej, dobrze wyposażony agent jest szybszy ode mnie i nie nudzi się przy trzecim powtórzeniu.

Ludzka kontrola wygrywa w ocenie, smaku i konsekwencjach. Wszystko, za co klient płaci. Wszystko o wadze prawnej albo finansowej - właśnie dlatego korekty faktur wyżej dostają ludzki podpis, a nie automatyczną wysyłkę. Decyzje architektoniczne, w których "dobra" odpowiedź zależy od tego, gdzie chcę mieć firmę za rok, a nie od tego, co kod mówi dzisiaj. I ostatni metr wyczucia w pisaniu oraz designie, gdzie "technicznie poprawne" i "naprawdę dobre" to różne rzeczy, a tylko jedna z nich zatrzymuje klienta.

Ta linia też nie jest stała. Każda blizna w tym tekście to miejsce, w którym kiedyś zaufałem agentowi w czymś, na co nie był gotowy, oberwałem i przesunąłem granicę. To jest właściwa umiejętność - nie jednorazowo zdecydować, gdzie kończy się AI, tylko patrzeć, gdzie zawodzi, i przesuwać granicę szybciej, niż awarie zdążą się piętrzyć.

Dlaczego powinno cię to obchodzić, jeśli kupujesz ode mnie

Oto szczera wersja, bo framing takiego tekstu może łatwo zjechać w miejsce, którego nie chcę. Agenci nie robią za mnie modułów i nigdy bym ci tego nie powiedział. Budują rusztowania, uruchamiają narzędzia, których nie chce mi się odpalać ręcznie, robią pierwsze szkice i wyłapują nawzajem swoje błędy - wszystko w zestawie barier, na które zapracowałem awaria po awarii. Ocena, architektura i podpis zostają moje.

To, co ta dyscyplina daje tobie, jako osobie po drugiej stronie modułu albo ticketa supportowego, jest nudne w najlepszym sensie. Ta sama reguła, która powstrzymuje 154 repozytoria przed splątaniem, powstrzymuje release przed wypuszczeniem półgotowej pracy. Ta sama ściana, która zatrzymuje agenta przed wyczyszczeniem folderu vendor, jest powodem, dla którego zła aktualizacja dużo rzadziej wychodzi z mojego warsztatu. Ten sam nawyk dev-first, który chroni moje własne sklepy testowe, chroni twoje. Staranny proces upstream to coś, co downstream czuje się jak spokojna niezawodność.

Jeśli masz wynieść jedną rzecz, to tę: przestań stroić prompt i zbuduj pamięć. Agent zapomni wszystko w chwili, gdy sesja się zamknie - więc włóż wszystko warte zapamiętania tam, gdzie nie może tego zapomnieć, a błędy, których nie chcesz już nigdy zobaczyć, uczyń niemożliwymi, nie tylko odradzanymi. Zrób to, a flota genialnych amnezyków przestaje być ryzykiem i zaczyna wyglądać bardzo podobnie do zespołu.