Jak agencja pracuje z Claude Code na cudzym sklepie

Gdy agencja pracuje z agentami AI na Twoim sklepie, zmienia się narzędzie, a nie odpowiedzialność. Agent pisze większość kodu, ale umowa, człowiek podpisujący każdą zmianę i granica wokół produkcji zostają tam, gdzie były. Rzecz, którą warto sprawdzić przed podpisem: zabezpieczenia mają siedzieć w kodzie, konfiguracji i uprawnieniach, a nie w treści polecenia dla modelu.

Twoje pierwsze pytanie nie brzmi „ile szybciej”

Rozmowa o agentach w agencjach zwykle zaczyna się od tempa. Właściciela sklepu tempo interesuje na drugim miejscu. Na pierwszym jest zdanie, którego nikt nie mówi na głos: co się stanie, jeśli to coś zepsuje mój sklep w środku sezonu. To jest sensowne pytanie i tekst poniżej odpowiada dokładnie na nie.

Warto też nazwać rzecz, którą czytelnik prawdopodobnie już gdzieś widział. Najgłośniejsza historia o agentach kodujących nie jest historią sukcesu, tylko historią skasowanej bazy produkcyjnej, i każdy wykonawca powinien umieć się do niej odnieść, zamiast udawać, że jej nie ma.

Historia, którą wszyscy pamiętają

W lipcu 2025 The Register opisał, jak agent AI na platformie Replit skasował produkcyjną bazę danych mimo ogłoszonego przez użytkownika zamrożenia kodu, a szef firmy publicznie przeprosił. Trzy wątki o tym zdarzeniu mają na Hacker News 179, 143 i 113 punktów (dane z publicznego API Hacker News, sprawdzone 17 sierpnia 2026).

Nasze odczytanie tej sprawy, oznaczone jako opinia: porażką nie było to, że model napisał słaby kod. Porażką było to, że agent miał drogę do produkcyjnych danych, a jedyną przeszkodą na tej drodze było zdanie wpisane w okno rozmowy. Instrukcja nie jest kontrolą dostępu.

Przy okazji: platforma z tamtej historii reklamuje się hasłem vibe coding, a to inna czynność niż inżynieria z agentem. Różnica nie leży w modelu, tylko w tym, co model dostaje na wejściu i co dzieje się z jego wynikiem.

Czego agentom nie wolno na cudzym systemie

Lista granic jest krótka i celowo nudna. Nudne granice łatwiej wyegzekwować niż zasady wymagające interpretacji:

• Produkcja. Agent pracuje na gałęzi i w środowisku podglądu. Adres produkcyjny, dane logowania do produkcji i produkcyjna baza są poza jego zasięgiem.
• Migracje bazy. Agent przygotowuje migrację razem ze ścieżką wycofania. Uruchamia ją człowiek, po kopii zapasowej.
• Sekrety. Klucze API, dane do bramki płatniczej i tokeny dostępu żyją w magazynie sekretów, nigdy w repozytorium i nigdy w prompcie.
• Operacje kasujące. Usunięcia, nadpisania i masowe aktualizacje bez ścieżki powrotu wymagają wyraźnej zgody człowieka.
• Deploy i akcje wychodzące na zewnątrz. Wdrożenie, mail do Twoich klientów, wysyłka feedu na marketplace, obciążenie karty. Wszystko, co widzi świat zewnętrzny, jest decyzją człowieka.
• Dane osobowe klientów. Agent pracuje na kopii z ograniczonym zakresem danych, nie na żywej tabeli zamówień.

Dlaczego prompt nie jest zabezpieczeniem

Pod tymi sześcioma punktami leży jedna zasada. Prompt jest prośbą, uprawnienie jest faktem. Zdanie „nie dotykaj produkcji” działa dokładnie tak długo, jak długo model je respektuje, czyli do pierwszego nieoczywistego przypadku.

Jest też druga, mniej oczywista strona. Agent czyta treści, których nikt nie kontroluje: plik od dostawcy, mail od klienta, stronę z internetu. Taka treść może zawierać polecenie, a agent nie odróżnia danych od instrukcji tak dobrze, jak byśmy chcieli. Jeśli jedyną obroną jest „napisaliśmy mu, żeby tego nie robił”, obrony nie ma.

Jak zmiana dochodzi do Twojej produkcji

Przepływ jest zwyczajny i to jego zaleta: gałąź, automatyczne bramki, przegląd, podgląd, dopiero potem wydanie. Agent przyspiesza wykonanie wewnątrz tego przepływu, ale nie skraca go o żaden krok. Same bramki i adwersarialny przegląd opisujemy szczegółowo w tekście o tym, jak budujemy z agentami u siebie. Tutaj chodzi o coś innego: co się zmienia, kiedy repozytorium nie jest nasze.

Agent może przygotować wszystko. Wydaje człowiek i to on się pod tym podpisuje.

Podpis jest tu dosłowny. Pod zmianą stoi imię i nazwisko inżyniera, nie nazwa narzędzia. Gdyby coś poszło nie tak po wydaniu, odpowiedź „to zrobił agent” nie istnieje. Odpowiedzialność za wydanie zostaje po stronie wykonawcy i powinna tak brzmieć w umowie.

Osobna sprawa to wykrywanie skutków. Awarie, które bolą najbardziej, rzadko są głośne, bo automatyzacje AI zawodzą po cichu. Dlatego po wydaniu liczy się monitoring, alert i raport z tego, co się wykonało, a nie pewne siebie podsumowanie w oknie rozmowy.

Zatwierdzanie zmian przez osobę, która nie czyta kodu

To jest problem zgłaszany przez praktyków najczęściej i najrzadziej rozwiązywany. Wykonawca stawia przed właścicielem sklepu pull requesta i nazywa to akceptacją. Diff jest artefaktem inżynierskim. Dla osoby, która prowadzi sprzedaż, jest nieczytelny i wymusza zgodę na coś, czego nie da się ocenić.

Zamiast tego klient dostaje zestaw rzeczy, które da się ocenić bez znajomości gita:

• Link do podglądu dla każdej zmiany: sklep w takiej postaci, w jakiej wejdzie na produkcję, na danych testowych.
• Notatka po ludzku: co się zmienia, gdzie kliknąć, co sprawdzić i co się stanie, jeśli nie zrobimy nic.
• Zrzuty ekranu albo krótkie nagranie przy wszystkim, co widać w interfejsie.
• Decyzje jako pytania biznesowe, z rekomendacją i terminem, zamiast fragmentów kodu do oceny.
• Jedna cotygodniowa lista: wydane, czeka na Twoją decyzję, zablokowane po naszej stronie.
• Przy ryzykownych zmianach flaga funkcji, stopniowe otwarcie i wycofanie w jednym kroku, żeby Twoja zgoda była odwracalna.

Czyj jest kod i co zostaje po rozstaniu

To pytanie kontraktowe, nie techniczne, i dlatego przegrywa się je na etapie umowy, a nie na etapie kodu. Nasza pozycja jest prosta: platforma jest Twoja. Kod, dane i baza zostają po stronie klienta, nie ma prowizji od obrotu ani sufitu ustawionego przez cudzą roadmapę, a gdy współpraca się kończy, zostajesz z działającą platformą, nie z wypowiedzianą licencją.

Niezależnie od wykonawcy, sześć rzeczy warto mieć zapisanych przed pierwszą linijką kodu:

• Repozytorium w Twojej organizacji od pierwszego dnia albo przeniesione w konkretnej, wpisanej dacie.
• Konta hostingu, domeny, płatności, monitoringu błędów i analityki założone na Ciebie. Wykonawca dostaje dostęp, nie własność.
• Sekrety: kto je trzyma i zapis, że są rotowane w momencie odebrania dostępów.
• Dokumentacja architektury, modelu danych, log decyzji i procedury awaryjne w repozytorium, a nie na czyimś dysku.
• Pliki instrukcji dla agentów (CLAUDE.md albo AGENTS.md) i skille używane w projekcie, bo one też są częścią tego, jak projekt się utrzymuje.
• Części reużywalne: które klocki wykonawca przenosi między klientami, na jakiej licencji i co się z nimi dzieje po zakończeniu współpracy. To pytanie zadaj także nam.

Ostatni punkt bywa przemilczany, więc powiemy wprost: każdy wykonawca, który dowozi szybko, coś reużywa. To nie jest wada, to jest powód, dla którego stała cena w ogóle się trzyma, a model rozliczenia opisujemy na stronie cennika. Problem zaczyna się dopiero wtedy, gdy nikt nie zapisał, które to części.

Kontekst projektu jako artefakt, nie folklor

Agent, który musi zgadywać Twoją domenę, zgaduje też architekturę, a to najdroższy rodzaj pomyłki. Dlatego rzeczy, które zwykle mieszkają w głowach, lądują w repozytorium: model danych, słownik pojęć, konwencje, decyzje i, najbardziej praktyczne ze wszystkiego, warianty odrzucone razem z powodem odrzucenia.

Odrzucone warianty ratują najwięcej czasu. Bez nich każdy nowy człowiek i każdy nowy agent proponuje z powrotem pomysł, który ktoś kiedyś świadomie skreślił, i cała dyskusja odbywa się drugi raz, tylko już bez osoby, która pamiętała dlaczego.

Uczciwe ograniczenie: martwa dokumentacja szkodzi bardziej niż jej brak, bo agent traktuje ją jak prawdę. Dlatego dokument zmienia się w tym samym pull requeście co kod, a plik ma być zwięzły, nie kompletny.

Ten sam artefakt odpowiada na dwa pytania naraz: czego potrzebuje agent, żeby pracować sensownie, i czego potrzebuje Twój następny wykonawca, żeby przejąć projekt. To jest też idea stojąca za BEAM, platformą, na której budujemy: jedno miejsce, z którego prowadzisz cały eCommerce, razem z agentami AI, którzy znają kontekst Twojej firmy, a nie same liczby (jak to budujemy).

Procedury, które podajemy agentom, są przy tym jawne. Zestaw skilli eCommerce dla agentów AI wypuściliśmy publicznie na licencji MIT, a krótsze prompty do codziennej pracy zbieramy w Bibliotece AI. Nie musisz nam wierzyć na słowo, możesz to przeczytać.

Kiedy to nie ma sensu

Są sytuacje, w których cała ta maszyneria jest kosztem bez zwrotu. Cztery najczęstsze:

• Jednorazowa drobna zmiana. Ustawienie bezpiecznej pętli kosztuje więcej niż podmiana banera. Ktoś powinien to po prostu zrobić ręcznie.
• Zespół, który tego nie chce. Jeśli po Twojej stronie nikt nie otworzy podglądu i nie odpowie na pytania, kolejka decyzji rośnie i tempo znika. Po stronie wykonawcy jest symetrycznie: agent narzucony inżynierom, którzy odrzucają proces, produkuje bałagan szybciej.
• System bez testów i bez odtwarzalnego środowiska. Agent nie ma wtedy sygnału zwrotnego, więc przyspiesza narastanie długu zamiast go zdejmować. Najpierw bramki, potem agenci.
• Dane, których nie wolno skopiować. Jeśli ograniczenia regulacyjne albo architektura uniemożliwiają bezpieczną kopię roboczą, większość przewagi znika i uczciwą odpowiedzią jest wolniejsza, ręczna ścieżka.

Jest też odpowiedź szersza niż sam sposób pracy. Jeśli Twój sklep to prosty katalog, który mieści się w standardzie platformy abonamentowej, właściwą decyzją bywa nie zmieniać nic. Mówimy to, mimo że budujemy platformy na własność, na przykład wdrożenia na Medusie.

O co zapytać wykonawcę, zanim oddasz klucze

Sześć pytań, które w kilkanaście minut pokazują, czy proces istnieje, czy jest opowieścią:

• Do których środowisk sięgają Wasi agenci i co technicznie im tego pilnuje?
• Gdzie leżą sekrety i kto może je odczytać?
• Kto uruchamia migracje i wdrożenia, z imienia i nazwiska?
• Jak zatwierdzę zmianę, nie czytając kodu?
• Co poza kodem znajdę w repozytorium?
• Co mam w ręku w dniu, w którym kończymy współpracę?

Te same zasady obowiązują po starcie, w utrzymaniu i rozwoju: ta sama gałąź, te same bramki, ten sam człowiek na wydaniu. Różnica między agencją, która używa agentów dobrze, a taką, która używa ich niebezpiecznie, nie leży w modelu, subskrypcji ani liczbie agentów puszczonych równolegle. Leży w tym, czy granice istnieją poza oknem rozmowy. Poproś o nie na piśmie.