Claude Code lub Codex na działającej stronie: środowisko testowe, kopie zapasowe i kontrola

Claude Code, Codex i podobni agenci nie ograniczają się już do podpowiadania kodu. Sami uruchamiają WP-CLI, wypychają motywy Shopify, edytują komponenty Astro i otwierają pull requesty. Właśnie przez to tempo właściciele stron dają im klucze, i z tego samego powodu jedno złe polecenie dociera do klientów w kilka sekund. Ten poradnik opisuje kolejność zabezpieczeń, którą stosuję, zanim agent dotknie strony klienta: kopia do pracy, sprawdzone odtwarzanie, uprawnienia egzekwowane przez narzędzie, dane dostępowe, które nie pozwalają na więcej, niż wymaga zadanie, i testy, które przeprowadzasz sam.

Dotyczy to WordPressa, Shopify i frontendów opartych na Gicie, takich jak Astro czy Next.js. Każde opisane niżej zachowanie produktu pochodzi z dokumentacji producenta pobranej 23 października 2026 r.

#Czy można pozwolić agentowi AI edytować stronę na produkcji

Nie na pierwszym kroku. Powód jest techniczny, a nie kwestia zaufania do modelu. Dokumentacja uprawnień Claude Code mówi wprost: “Reguły uprawnień egzekwuje Claude Code, a nie model” (tłumaczenie własne). Linijka w CLAUDE.md albo AGENTS.md w stylu “nigdy nie dotykaj produkcji” wpływa na to, co agent próbuje zrobić, ale żadnego polecenia nie zatrzyma. Na działającym serwerze powłoka agenta ma dokładnie te prawa, które ma użytkownik SSH, użytkownik bazy danych albo token API.

Jedna z odpowiedzi w wątku na r/Wordpress o przerabianiu projektu HTML z AI na motyw ujęła tę zasadę w jednym zdaniu:

AI świetnie zamienia twój HTML na elementy motywu, ale nie pozwoliłbym mu łączyć się z twoją działającą stroną i edytować jej bezpośrednio.

(u/eshbanbahadur2020, r/Wordpress, 23 października 2026, tłumaczenie własne)

Przycisk cofania też obejmuje mniej, niż się wydaje. Strona o punktach kontrolnych podaje, że plik zmieniony wyłącznie poleceniami Bash “nie jest śledzony i zostaje w obecnym stanie”, a same punkty kontrolne “nie zastępują kontroli wersji” (tłumaczenie własne). Uruchomienie wp search-replace, aktualizacja wtyczki czy wypchnięcie motywu dzieją się całkowicie poza tą historią. Dlatego praca zaczyna się z dala od produkcji.

#Jak przygotować kopię testową strony dla agenta AI

Wybierz kopię pasującą do twojej platformy.

WordPress. Strona testowa na tym samym hostingu albo kopia lokalna, z bazą danych wyeksportowaną i zaimportowaną przez WP-CLI. Cały proces opisuje mój przewodnik po środowisku testowym WordPressa. Przy pracy z agentem liczą się dwa polecenia: wp db export zapisuje bazę do pliku, a wp search-replace ma opcję --dry-run, która według podręcznika WP-CLI “wykona całą operację wyszukiwania i zamiany i pokaże raport, ale nie zapisze zmian w bazie danych” (tłumaczenie własne). Każ agentowi uruchamiać każdą zamianę najpierw na sucho i pokazywać ci raport.

Do jednorazowych eksperymentów Playground CLI uruchamia WordPressa lokalnie poleceniem npx @wp-playground/cli@latest server. W tym trybie pliki i baza SQLite trafiają do katalogów tymczasowych, więc po zatrzymaniu nic nie zostaje. Tryb start zachowuje zmiany między uruchomieniami. Rolę agenta w takiej konfiguracji omawia mój artykuł o WordPress Playground i MCP dla agentów AI.

Aktualizacja, 4 listopada 2026. Zespół Playground opisał, że WordPress Playground potrafi teraz sklonować działającą stronę do przeglądarki, bez lokalnego serwera. Wybierasz New Playground > Clone a live site, wpisujesz adres i sprawdzasz stronę. Na stronie źródłowej musi być aktywna wtyczka Reprint, a ty potrzebujesz konta administratora. Sam adres nie daje dostępu do plików ani bazy: klucz migracji z Playground wklejasz w Tools > Reprint Server > Migration Token i wybierasz Authorize client. Zmiany w kopii nie trafiają na żywą stronę, a gotowa kopia zapisuje się w przeglądarce. Reprint przesyła pliki i bazę małymi porcjami i poprawia zapisane adresy strony. Import w przeglądarce przyjmuje obecnie do 2 GiB. Playground uruchamia WordPressa w innym środowisku niż twój hosting, więc część wtyczek i usług zewnętrznych może zachowywać się inaczej; wpis radzi łączyć te sprawdzenia z testami na hostingu. Do pracy z agentem to kopia na jedną sesję, bez własnego serwera. Wpis ostrzega też, że kopia może zawierać prywatne treści, dane użytkowników i dane dostępowe wtyczek, więc traktuj ją jak każdą kopię bazy z danymi klientów i przed udostępnieniem eksportu usuń te informacje.

Shopify. shopify theme dev wgrywa twój lokalny motyw jako motyw deweloperski i serwuje podgląd pod adresem http://127.0.0.1:9292. Dokumentacja CLI Shopify określa motywy deweloperskie jako “tymczasowe, ukryte motywy”, które nie wliczają się do limitu motywów i “są usuwane ze sklepu po siedmiu dniach bezczynności” (tłumaczenie własne). Znikają też po shopify auth logout. Jeśli potrzebujesz podglądu, który przetrwa do akceptacji przez klienta, Shopify zaleca wypchnięcie zmian do nieopublikowanego motywu. W obu przypadkach agent nie potrzebuje prawa publikacji na żywym motywie.

Astro, Next.js i inne strony oparte na Gicie. Agent pracuje na gałęzi, a hosting buduje podgląd. W Cloudflare Pages adresy podglądów domyślnie “są publiczne” (tłumaczenie własne), a każdy podgląd wysyła X-Robots-Tag: noindex; Cloudflare Access pozwala udostępnić je tylko twojemu kontu. Strona o środowiskach w Vercel zawiera ostrzeżenie warte dwukrotnego przeczytania: przygotowane wdrożenie produkcyjne korzysta z produkcyjnych zmiennych środowiskowych, “więc testy mogą sięgać do produkcyjnych usług i danych” (tłumaczenie własne). Jeśli podgląd agenta łączy się z twoją działającą bazą albo kluczami płatności, to nie jest środowisko testowe.

#Jak zrobić kopię zapasową strony, żeby cofnąć zmianę agenta

Kopia zapasowa się liczy dopiero wtedy, gdy ją odtworzyłeś. Przed sesją z agentem:

• Kod: zatwierdź albo otaguj obecny stan w Gicie. Na stronie WordPress bez Gita skopiuj wp-content do folderu z datą w nazwie.
• Baza danych: wp db export before-agent.sql. Odtworzenie to wp db import before-agent.sql, zgodnie z opisem polecenia import w WP-CLI.
• Strona deweloperska i testowa (aktualizacja 24 października 2026): wtyczka SnapShots w wersji 3.0.0 zapisuje bazę danych i domyślnie folder uploads, a potem przywraca je jednym kliknięciem z paska administracyjnego albo poleceniem wp snapshot restore. Wtyczki, motywy i rdzeń nie wchodzą do migawki, a pliki zostają na tym samym serwerze. Autorzy na stronie wtyczki piszą wprost, że to narzędzie do cofania zmian podczas testów, a nie kopia poza serwerem. Wymaga WP-CLI i funkcji PHP exec, którą wiele hostingów wyłącza. Używaj jej między kolejnymi próbami agenta na kopii lokalnej albo testowej, a dla produkcji trzymaj eksport bazy z punktu wyżej i kopię na innym serwerze.
• Shopify: zduplikuj żywy motyw w panelu. Produkty, zamówienia i ustawienia zmienione przez Admin API nie są częścią motywu, więc wszystko, co agent tam zapisze, wymaga osobnego eksportu.
• Próba odtworzenia: raz odtwórz kopię na środowisku testowym i zmierz czas. Zmierzone dziesięć minut jest więcej warte niż założenie, że “hosting robi kopie”.

Ten sam nawyk chroni aktualizacje wtyczek i rdzenia; w artykule czy warto aktualizować WordPressa pokazuję, jak aktualizować bez psucia strony.

#Czy agent AI może pracować na kopii bazy z danymi klientów

Kopia testowa sklepu WooCommerce albo Shopify to kopia imion i nazwisk klientów, ich adresów i zamówień. Jeśli agent wysyła zawartość plików do modelu w chmurze, te dane opuszczają twój serwer. W UE takie przetwarzanie podlega RODO jak każde inne. Art. 5 ust. 1 lit. c) wymaga, by dane osobowe były “ograniczone do tego, co niezbędne do celów, w których są przetwarzane”, a art. 28 ust. 1 pozwala administratorowi korzystać “wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje” (brzmienie polskiej wersji RODO). Poprawka szablonu nagłówka nie wymaga prawdziwych klientów w bazie.

W praktyce: przed sesją z agentem zanonimizuj albo usuń w kopii tabele klientów i zamówień, albo daj agentowi kopię zawierającą tylko tabele, których dotyczy zadanie. Opcje wp db export --tables=... i --exclude_tables=... z opisu polecenia export sprowadzają ten drugi wariant do jednego polecenia. Zanim jakiekolwiek prawdziwe dane osobowe trafią do dostawcy AI, porównaj jego warunki powierzenia przetwarzania z art. 28.

To samo rozporządzenie wspiera próbę odtworzenia z poprzedniej sekcji. Art. 32 ust. 1 wymienia wśród środków do rozważenia “zdolność do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich” oraz “regularne testowanie, mierzenie i ocenianie skuteczności” środków bezpieczeństwa (brzmienie polskiej wersji RODO). Kopia zapasowa, której nikt nie odtworzył, nie spełnia żadnego z tych warunków.

#Jak ograniczyć uprawnienia Claude Code i Codexa

Oba narzędzia mają warstwę uprawnień. Korzystaj z niej, ale nie polegaj tylko na niej.

Claude Code ma tryby: default (opisany jako Manual) pyta przed pierwszym użyciem każdego narzędzia, acceptEdits automatycznie akceptuje edycje plików w katalogu roboczym, plan przegląda projekt bez edytowania plików źródłowych, auto przekazuje ocenę działań klasyfikatorowi, a bypassPermissions pomija pytania. Dokumentacja zaleca używanie bypassPermissions “wyłącznie w odizolowanych środowiskach, takich jak kontenery czy maszyny wirtualne, gdzie Claude Code nie może wyrządzić szkód” (tłumaczenie własne). Reguły w settings.json są sprawdzane w stałej kolejności, “deny, potem ask, potem allow”, a reguła allow nie wytnie wyjątku z reguły deny. Punkt wyjścia dla repozytorium WordPressa:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./wp-config.php)", "Bash(git push *)", "Bash(wp db drop *)", "Bash(ssh *)"],
    "ask": ["Bash(wp search-replace *)", "Bash(wp plugin update *)"],
    "allow": ["Bash(git diff *)", "Bash(wp plugin list *)"]
  }
}

Jedno ograniczenie warto znać: reguły deny dla Read i Edit obejmują narzędzia plikowe Claude’a i polecenia takie jak cat czy sed, ale nie “skrypt Pythona lub Node, który sam otwiera pliki” (tłumaczenie własne). Jeśli sekrety mają być naprawdę odgrodzone, dokumentacja odsyła do piaskownicy.

Reguły dla Bash mają drugą lukę, którą warto sprawdzić, zanim zaczniesz na nich polegać. Reguła dopasowuje tekst polecenia napisanego przez Claude’a, a nie program, który faktycznie się uruchamia. Tabela w samej dokumentacji pokazuje, że Bash(git push *) zatrzyma git push origin main, ale nie git -C . push origin main, a Bash(rm *) nie zatrzyma bash -c 'rm -rf build/'. Lista deny to więc próg zwalniający dla poleceń, które agent zwykle pisze. Prawdziwy mur postaw tam, gdzie zmiana zapisu polecenia go nie obejdzie.

Tym murem jest piaskownica. Domyślnie jest wyłączona; włączasz ją poleceniem /sandbox w sesji albo wpisem "sandbox": {"enabled": true} w settings.json. Egzekwuje ją system operacyjny (Seatbelt na macOS, bubblewrap na Linuksie i WSL2) i obejmuje polecenia powłoki uruchamiane przez Claude’a “oraz procesy, które one uruchamiają” (tłumaczenie własne), więc skrypt Pythona, który prześlizgnął się obok reguły Read, też jest w środku. Zapis jest ograniczony do katalogu roboczego, dodanych katalogów i katalogu tymczasowego. Ruch sieciowy przechodzi przez serwer pośredniczący, którego lista dozwolonych domen na starcie jest pusta. Ta sama strona podaje dwa ograniczenia: w natywnym Windowsie polecenia działają bez piaskownicy, a hooki, lokalne serwery MCP i polecenia pomocnicze działają poza nią z twoimi pełnymi uprawnieniami.

Do sprawdzeń, które wymagają logiki, służy hook PreToolUse: uruchamia się przed każdym wywołaniem narzędzia i może je zablokować. Strona o uprawnieniach zaznacza, że hook nie poluzuje reguły deny: wywołanie odrzucone przez regułę deny pozostaje odrzucone, nawet jeśli hook zwróci allow. Dzięki temu hooki są bezpiecznym miejscem na reguły specyficzne dla projektu, na przykład odrzucanie każdego polecenia, które zawiera nazwę hosta produkcyjnego.

Codex oddziela piaskownicę od zatwierdzeń. Według strony OpenAI o zatwierdzeniach i bezpieczeństwie agent domyślnie “działa z wyłączonym dostępem do sieci” (tłumaczenie własne), folder objęty kontrolą wersji dostaje zapis w obszarze roboczym z zatwierdzaniem na żądanie, a folder poza kontrolą wersji tryb read-only. danger-full-access oznacza brak piaskownicy i brak zatwierdzeń; strona oznacza go jako podwyższone ryzyko i odradza. Zostaw ustawienia domyślne i zatwierdzaj dostęp do sieci osobno dla każdego zadania.

Dane dostępowe to warstwa, która trzyma, gdy wszystko inne zawiedzie. Daj agentowi osobnego użytkownika bazy danych na kopii testowej, a jeśli ma tylko analizować dane, nadaj mu samo SELECT, tak jak w opisie GRANT w MySQL. W Shopify użyj tokenu aplikacji własnej z zakresami, których wymaga zadanie; Shopify zaznacza w przewodniku po zakresach dostępu, że “zakres zapisu obejmuje odczyt” (tłumaczenie własne), więc write_products to już szeroka opcja. Po zakończeniu pracy unieważnij token. Mój audyt dostępów zdalnych i kluczy API wymienia miejsca, w których takie tokeny się chowają.

Aktualizacja 24 października 2026, przykład dostępu tylko do odczytu: otwartoźródłowy serwer MCP dla Google Search Console (pakiet open-gsc-mcp) ma zapis włączony od instalacji. README wymienia cztery narzędzia, które zmieniają konto (submit_sitemap, delete_sitemap, add_site i delete_site), domyślną wartość GSC_ENABLE_WRITES ustawia na 1, a logowanie prosi Google o pełny dostęp do Search Console. Narzędzia są oznaczone jako zapisujące, ale sam serwer nie pyta cię o zgodę; to, czy zobaczysz pytanie, zależy od ustawień uprawnień w twoim kliencie. Jeśli agent ma tylko analizować kliknięcia i zapytania, zaloguj się przez auth login --read-only albo ustaw GSC_ENABLE_WRITES=0, a tych czterech narzędzi po prostu nie będzie. Tak samo sprawdzaj domyślne logowanie każdego serwera MCP, zanim go podłączysz.

Aktualizacja 6 listopada 2026, adres e-mail w nagłówku User-Agent: 5 listopada użytkownik zgłosił w repozytorium Claude Code (zgłoszenie #107757), że agent wysyłał obcym stronom adres e-mail z jego konta w nagłówku User-Agent. Lydia Hallie z zespołu Claude Code wyjaśniła na Hacker News, skąd się to wzięło: adres konta trafił do kontekstu modelu, żeby agent przestał wymyślać autora w tagach @author, a gdy model sam pisał polecenie curl, czasem wpisywał ten adres jako kontakt w User-Agent. Anthropic zapowiedział usunięcie adresu z kontekstu w kolejnym wydaniu. Do tego czasu wersje od 2.1.317 mają wbudowany dodatek, który pyta o zgodę przed wywołaniem narzędzia sieciowego albo polecenia w stylu curl z tym adresem. Zespół przyznaje, że dodatek nie obejmuje skryptów, które agent sam napisze i uruchomi, a w tym samym zgłoszeniu dwie osoby opisały testy na wersjach 2.1.317 i 2.1.318 (macOS i Windows), w których dodatek niczego nie zatrzymał. Ten błąd pokazuje ogólną zasadę: wszystko, co agent ma w kontekście, może trafić do żądania wysłanego na zewnątrz, także dane klientów z kopii bazy. Zaktualizuj Claude Code co najmniej do 2.1.317 i dodaj własny hook PreToolUse, który odrzuca polecenia zawierające twój adres i słowo User-Agent (taki hook opisał w zgłoszeniu jeden z użytkowników). W logach serwera poszukaj nagłówków User-Agent z adresem e-mail, a zobaczysz, co agenci wysyłają do twoich stron.

#Jakie dane dostępowe dać agentowi AI w WordPressie, WooCommerce, Shopify i Cloudflare

Każda z tych platform pozwala wystawić dane dostępowe, które dają mniej niż twoje własne logowanie. Korzystaj z tego i twórz je wyłącznie dla agenta, żeby móc je unieważnić bez odcinania samego siebie.

W WordPressie ograniczeniem jest rola. Dokumentacja ról opisuje administratora jako osobę z dostępem do wszystkich funkcji administracyjnych strony, a redaktora jako osobę, która może publikować wpisy i nimi zarządzać, także wpisami innych użytkowników. Agentowi, który edytuje treści przez REST API, wystarczy co najwyżej rola redaktora. Agent z hasłem administratora ma każdą funkcję administracyjną, łącznie z instalacją wtyczek, a wtyczka to kod PHP wykonywany na twoim serwerze.

W Shopify CLI ma zabezpieczenie, którego agentowi nigdy nie wolno zdjąć. Opis polecenia theme push mówi, że --allow-live jest “wymagana w środowiskach nieinteraktywnych, gdy celem jest żywy motyw” (tłumaczenie własne), a --publish publikuje wgrany motyw. Agent działa nieinteraktywnie, więc reguła deny dla obu flag trzyma go na nieopublikowanych motywach. shopify theme push --unpublished tworzy nowy nieopublikowany motyw i wypycha zmiany właśnie do niego: to jest cel, który warto dać agentowi.

#Jak przejrzeć zmiany wprowadzone przez agenta AI

Przeczytaj listę zmian, zanim cokolwiek trafi na produkcję. git diff --stat pokazuje, które pliki się zmieniły; agent poproszony o poprawienie linku w stopce, który dotknął czterdziestu plików, zrobił też coś innego. Potem przeczytaj pełny git diff każdego pliku. Zwróć uwagę na:

• wyłączone zabezpieczenia: zakomentowaną weryfikację nonce, sprawdzenie uprawnień zastąpione przez is_admin(), test usunięty, “bo nie przechodził”;
• nowe zależności, wtyczki albo pakiety Composera, o które nikt nie prosił;
• sekrety lub klucze API wklejone w kod;
• zmiany w migracjach bazy danych, .htaccess, przekierowaniach albo robots.txt.

W WordPressie porównaj wp plugin list i wp option get active_plugins przed zmianą i po niej: część zmian siedzi w bazie danych, a nie w plikach. Jeśli agent napisał kod wtyczki, moja lista kontrolna do audytu kodu wtyczek WordPress generowanego przez AI przechodzi przez osiem typowych błędów.

#Jak sprawdzić, czy zmiana agenta naprawdę działa

Gdy agent pisze “gotowe, przetestowane, wszystko działa”, to jest raport, a nie dowód. Test, który agent napisał sam dla siebie, może przejść z niewłaściwego powodu. Przeprowadź własne sprawdzenie:

Wpis oznaczony jako [PROMO] na r/Wordpress, napisany przez twórcę wtyczki do testów A/B, który promował do niej umiejętności dla agentów, miał tytuł: “Claude tak ułatwił zmiany na mojej stronie WordPress, że przestałem sprawdzać, czy w ogóle działają”. Jedna z odpowiedzi:

‘Przestałem sprawdzać, czy moje zmiany w ogóle działają’ to właśnie sposób, w jaki wpakowałem się w dużą część bałaganu, w którym teraz stoę. Ufaj, jasne, jeśli chcesz, ale sprawdzaj.

(u/SoItBegins_n, r/Wordpress, 22 października 2026, tłumaczenie własne)

1. curl -sI na każdym zmienionym adresie i na stronie głównej: kod odpowiedzi, przekierowania, nagłówki cache.
2. Log błędów PHP albo konsola przeglądarki na tych samych stronach.
3. Prawdziwe wysłanie formularza, a w sklepie testowe zamówienie przez cały koszyk.
4. Strona na telefonie, a nie tylko w przeglądarce bez interfejsu, której używa agent.
5. Przy zmianach istotnych dla SEO: wyrenderowany tytuł, canonical i meta robots, bo agenci edytują szablony, które je generują.

Zrób to na środowisku testowym, a potem jeszcze raz na produkcji zaraz po wdrożeniu. Jeśli coś zawiedzie na produkcji, najpierw przywróć kopię, a dopiero potem szukaj przyczyny.

#Jak wygląda bezpieczna sesja z agentem AI na kopii testowej WordPressa

Zadanie: przenieść formularz zapisu na newsletter z paska bocznego do stopki na stronie WordPress z własnym motywem trzymanym w Gicie. Poniższa kolejność korzysta wyłącznie z narzędzi opisanych wyżej.

1. Na środowisku testowym git tag before-agent w repozytorium motywu i wp db export before-agent.sql dla bazy danych.
2. Uruchom Claude Code w trybie plan i poproś o plan. Przeczytaj go. Jeśli przy zmianie w stopce plan wspomina o wtyczkach, bazie danych albo plikach spoza motywu, zatrzymaj się i zapytaj dlaczego.
3. Przełącz na acceptEdits z opisanymi wcześniej regułami deny i ask oraz z włączoną piaskownicą. Agent edytuje pliki motywu; każde polecenie wp nadal wymaga twojej zgody.
4. Po zakończeniu git diff --stat. Dwa pliki szablonów i arkusz stylów to wiarygodny wynik dla tego zadania. Wszystko w functions.php, co rejestruje nowe skrypty, czytasz w całości.
5. Sprawdź sam: wyślij formularz na środowisku testowym, potwierdź, że subskrybent pojawił się w narzędziu do wysyłki maili, obejrzyj stopkę na telefonie i przeszukaj log błędów PHP pod kątem nowych wpisów.
6. Scal i wdróż motyw samodzielnie. Na produkcji przeprowadź te same pięć sprawdzeń.
7. Jeśli na produkcji coś zawiedzie: git revert dla scalenia albo ponowne wdrożenie tagu before-agent. Baza danych nie była ruszana, więc nie trzeba jej odtwarzać. Gdyby była, krokiem byłoby wp db import before-agent.sql, i to polecenie musiałoby wcześniej zadziałać na środowisku testowym.

Agent napisał kod w kroku 3. Każdy krok, który dotykał produkcji, należał do ciebie.

#Agent twierdzi, że zmiana działa, a strona mówi co innego

#Co zrobić ze spaghetti kodem po agencie AI

Objawy są znajome: ta sama funkcja w trzech plikach, poprawki nakładane na poprawki, osobna wtyczka do każdej drobnej funkcji, style wpisane w kod, bo agent nie znalazł arkusza stylów. Nie proś tego samego agenta, żeby “posprzątał wszystko” na działającej stronie, bo tylko powiększysz listę zmian do przejrzenia. Zamroź obecny stan w Gicie, spisz, co strona ma robić, i dla każdego obszaru zdecyduj, czy go przebudować od środka, czy napisać od nowa.

Początkujący, który nie programował od 20 lat, opisał na r/Wordpress dwa tygodnie pracy z Codexem jako “koszmarną pętlę: psucie, łatanie, znowu psucie i znowu łatanie” (wątek, 21 października 2026, tłumaczenie własne). Jedna z odpowiedzi podsunęła wyjście:

Używaj Codexa do małych zmian, które da się przejrzeć, na kopii testowej, a nie do otwartych przeróbek działającej strony.

(u/NakanoNoNeko, r/Wordpress, 22 października 2026, tłumaczenie własne)

Mój artykuł o vibecodingu a WordPressie wyjaśnia, dlaczego strony zbudowane przez AI trudno potem utrzymać. Jeśli wolisz to komuś przekazać, moja usługa naprawy stron zrobionych przez AI przejmuje stronę od tego miejsca, a plan opieki technicznej utrzymuje potem środowisko testowe, kopie zapasowe i kontrolę aktualizacji. Jeśli chcesz włączyć agentów do swojej pracy na stałe, wdrożenia AI obejmują konfigurację uprawnień, tokenów i etapów przeglądu.

#Jakie uprawnienia dać agentowi AI na każdym etapie

Agent pisze kod. Wejście na produkcję zostaje krokiem, który wykonujesz sam.