Gdy ktoś mówi ci, że w pojedynkę wdrożył 335 aktywnych stron w 26 repozytoriach w ciągu 29 dni, instynktownie chcesz zapytać, jak udało mu się pracować tak szybko. Lepsze pytanie brzmi: co się zepsuło w tym procesie.

Liczby są prawdziwe: 1549 commitów, 26 repozytoriów, 29 dni, jeden programista korzystający z Claude Code. Jednak sama prędkość uczy niewiele. Liczy się charakter porażek, ponieważ nie były to błędy, które wyłapiesz w stosie wywołań (stack trace). Były to pęknięcia strukturalne. Dostrzegasz je dopiero wtedy, gdy odsuniesz się od edytora i spojrzysz na cały system pracujący na produkcji.

Co zadziałało

Prędkość nie była złudzeniem. Niektóre zadania rzeczywiście skracają się drastycznie, gdy powierzysz je sztucznej inteligencji, która nie potrzebuje snu.

Podręcznikowe algorytmy zmieniały się w gotowe funkcje w ciągu dni, a nie tygodni. Rozwiązywacz gry w 2048 i gry oparte na algorytmie minimax powstały szybko, ponieważ wzorce implementacji są dobrze udokumentowane. Model nie gubi się w pracach naukowych; pisze drzewo wyszukiwania, ewaluację heurystyczną, punktację ruchów i idzie dalej. To są rozwiązane problemy, a AI jako programista parowy (pair programmer) radzi sobie z nimi z brutalną wydajnością.

Żmudne audyty stały się znośne. Przeszukiwanie grafów linków, weryfikacja łańcuchów przekierowań, sprawdzanie tagów kanonicznych na setkach stron — ta praca wykańcza ludzką koncentrację, ale model językowy będzie powtarzał te czynności bez skargi. Sprawdza ten sam wzorzec trzysta razy i raportuje wyniki.

Prawdziwym zaskoczeniem była spójność. Gdy prosisz AI o wygenerowanie dziesiątek stron lądowania (landing pages), dryfowanie stylu jest nieuniknione, chyba że je zakotwiczysz. Użyłem małych plików pamięciowych, aby narzucić jeden system marki: zasady tonu wypowiedzi (voice rules), nazwy tokenów kolorów, ograniczenia komponentów i archetypy stron. Model odczytywał te ograniczenia na początku każdego istotnego zadania i tworzył pracę, która sprawiała wrażenie, jakby wyszła spod jednej ręki, a nie z dwudziestu dziewięciu różnych nastrojów.

Co tak naprawdę się zepsuło

Porażki miały charakter architektoniczny. Żaden proces budowania (build) nie zakończył się błędem z powodu brakującego średnika. Zamiast tego system powoli zwodził mnie, wmawiając, że wszystko jest w porządku.

Najpierw uderzyła kanibalizacja SEO. AI zbudowało nowe centrum narzędzi pod nowym adresem URL, podczas gdy starsze centrum narzędzi wciąż znajdowało się pod swoją oryginalną ścieżką. Każda pojedyncza strona była zoptymalizowana. Tytuły były zwięzłe. Meta opisy były unikalne. Treść była użyteczna. Ale wszystkie celowały w to samo zamiar wyszukiwania (search intent). Wyszukiwarki widziały dwóch autorytetów na te same frazy i nie rankingowały żadnego z nich. Idealne strony wzajemnie się znosiły, ponieważ nikt nie patrzył na witrynę jak na portfolio, lecz jak na zbiór plików.

Następnie pojawiły się niezgodności URL. Różne repozytoria przyjęły nieco inne struktury folderów dla tej samej logicznej treści. Jedno repozytorium umieszczało narzędzia w /tools/utility-name, inne spłaszczało je do /utility-name. CDN widział oba, generował łańcuchy przekierowań, aby je rozwiązać, i zaczął wyrzucać błędy na brzegu sieci (at the edge). Strony w końcu się ładowały, ale każde przekierowanie marnowało budżet indeksowania (crawl budget) i cierpliwość użytkownika. Kod był poprawny. Topologia była chaosem.

Potem pojawiła się pułapka synchronizacji. Zaktualizowałem stronę lustrzaną — instancję stagingową lub zapasową — ale zapomniałem przenieść tych zmian z powrotem do repozytorium źródłowego. Gdy później poprosiłem AI o synchronizację środowisk, potraktowało stronę lustrzaną jako źródło prawdy (ground truth). Prosta komenda synchronizacji mogłaby nadpisać produkcyjną bazę danych lub zestaw plików nieaktualnymi danymi z lustra. AI wykonało to, co opisałem, a nie to, co zamierzałem. Intencje nie podlegają operacji diff; pliki tak.

Narzędzia audytowe same kłamały. Ponieważ zautomatyzowałem audytowanie, założyłem, że wyniki są czyste. Tak nie było. Skrypty audytowe napisane przez AI zawierały subtelne błędy: błędy typu off-by-one, błędne założenia dotyczące kodów statusu przekierowań, fantomowe błędy wywoływane przez timing lub nagłówki, a nie rzeczywiste błędne konfiguracje. Raportowały problemy, które nie istniały, co zmuszało mnie do ścigania duchów. Nauczyłem się przestać ufać analizie statycznej, dopóki nie sprawdziłem ręcznie działającej strony i nie potwierdziłem objawu w przeglądarce lub za pomocą bezpośredniego polecenia curl.

Ukryty koszt

Oto liczba, o której nikt nie mówi: 93 procent moich wydatków na tokeny poszło na ponowne czytanie kontekstu z pamięci podręcznej (cached context).

W długiej sesji Claude Code każdy nowy request zmusza model do ponownego przeglądania historii rozmowy, buforów plików i pamięci roboczej. Pierwsze zadanie w sesji może być tanie. Przy dziesiątym zadaniu model trawi wszystko, co wydarzyło się wcześniej, tylko po to, by zrozumieć kolejne zdanie. Krzywa kosztów gwałtownie rośnie. Długie sesje zmieniają się w kosztowne ćwiczenia z ponownego czytania, a okno kontekstowe wypełnia się śmieciami z wcześniejszych zadań, które nie mają nic wspólnego z obecnym.

To nie jest kaprys. To bezpośredni podatek od złej higieny sesji.

Jak to naprawić

Rozwiązania okazały się proste, gdy tylko nazwałem problemy.

Traktuj jedną sesję jako jedno zadanie. Gdy zmienia się praca, zacznij od nowa. Pokusa utrzymywania „rozgrzanego” kontekstu jest silna — masz wrażenie, że oszczędzasz czas na konfiguracji — ale w rzeczywistości wynajmujesz pamięć na procent składany.

Przechowuj wiedzę w małych, dedykowanych plikach pamięci. Nie pozwól, aby model nosił wytyczne marki, biblioteki komponentów czy zasady SEO wewnątrz kontekstu rozmowy. Zapisuj je na dysku w zwięzłych plikach i odwołuj się do nich w sposób jawny. Przenosi to informacje z drogiego, ulotnego kontekstu do taniej pamięci trwałej.

Między różnymi zadaniami zrób porządek. Zamknij sesję. Otwórz nową. Trzydzieści sekund konfiguracji oszczędza dolary i halucynacje w przyszłości.

Lekcje dotyczące skalowania

Jeśli zamierzasz pracować na taką skalę, potrzebujesz barier ochronnych, które traktują system, a nie pojedynczy plik, jako jednostkę weryfikacji.

Wykonaj benchmark przed publikacją. Nie zakładaj, że strona działa tylko dlatego, że się renderuje. Sprawdź czas ładowania, układ mobilny i kluczowe metryki pod opublikowanym adresem URL. Piękny komponent w środowisku lokalnym może zawieść w rzeczywistych warunkach sieciowych.

Sprawdź diff przed skopiowaniem. Nigdy nie wykonuj masowej synchronizacji ani operacji kopiowania na ślepo. Przyjrzyj się różnicom (delta). Zrozum, w którym kierunku płyną dane. AI nie ostrzeże Cię, że zaraz nadpiszesz żywe dane klientów.

Sprawdź działające strony, zanim zaufasz audytom. Analiza statyczna to tylko hipoteza. Żywe zapytanie to dowód. Gdy narzędzie audytowe zgłasza niedziałający link lub pętlę przekierowań, zweryfikuj to bezpośrednim zapytaniem. Narzędzia również mają błędy, zwłaszcza te napisane przez AI działające na podstawie wnioskowanych wzorców.

Spisuj konwencje przed skalowaniem. Struktura URL, hierarchia folderów, wzorce kanoniczne i taksonomia treści muszą zostać udokumentowane w miejscu, które AI może odczytać, zanim wygeneruje choćby jedną nową stronę. Pliki pamięci nie są opcjonalne przy