Kiedy AI zawodzi z głupich powodów, czyli jak straciłem pół dnia na źle skonfigurowany context window

Jest coś wyjątkowo irytującego w obserwowaniu inteligentnego systemu, który pada z banalnych przyczyn. Sam tego doświadczyłem podczas eksperymentów z lokalnymi agentami programistycznymi — temat, który zyskuje na znaczeniu w miarę jak modele open-weight stają się coraz zdolniejsze, a deweloperzy coraz bardziej świadomi kwestii prywatności.

Cel: zbudować grę na własnym sprzęcie

Mój plan był prosty: sprawdzić, czy agent AI działający wyłącznie na lokalnej maszynie zdoła stworzyć działającą grę. Nie żadną trywialną demonstrację, tylko coś z prawdziwym zarządzaniem stanem, logiką renderowania, obsługą wejścia i grywalnym interfejsem.

Stos technologiczny? Trzy komponenty reprezentujące szczyt obecnych możliwości lokalnego AI: provider-agnostic agent CLI, Ollama wystawiający API kompatybilne z OpenAI, oraz Qwen3.8 27B działający na mojej maszynie. Dla kontekstu — to nie jest żadna słaba konfiguracja. Model 27B przy 17GB spokojnie mieści się w 32GB pamięci zunifikowanej i obsługuje tool calling z przyzwoitymi zdolnościami reasoningu.

Pierwsze wyniki wyglądały obiecująco. W kwadrans agent wyprodukował kompletną strukturę HTML i prawie 200 linii CSS w stylu NES z efektami 3D i właściwą paletą kolorów. Co bardziej imponujące — agent złapał własny błąd w locie: zapisał plik, sprawdził go, zauważył rozbieżność między zamierzeniem a tym, co faktycznie wylądowało na dysku, i naprawił problem bez żadnego prompta. To autentyczne agentyczne zachowanie, które sugerowało, że model podoła zadaniu.

Potem agent spróbował napisać logikę gry i wszystko się zatrzymało.

Trzynaście prób, zero postępu

To, co nastąpiło, rozpozna każdy, kto zmagał się z narzędziami AI. Trzynaście kolejnych prób zapisu pliku z silnikiem gry, każda przerwana w połowie generowania. Strumień po prostu umierał — bez błędu, bez wyjaśnienia, bez użytecznego wyniku.

Najbardziej irytujące nie było samo niepowodzenie, ale obserwowanie procesu rozumowania agenta. Ponieważ każda próba zaczynała się od zera, model za każdym razem na nowo wyprowadzał te same decyzje projektowe, dochodząc do innych tabel punktacji i podejść implementacyjnych. Trzy próby oznaczały trzy różne odpowiedzi na to samo pytanie architektoniczne. Agent spędzał godzinę na myśleniu i nie dostarczał niczego.

Oczywistym winowajcą wydawała się presja na pamięć. Zamknięcie zakładek przeglądarki zwolniło kilka gigabajtów RAM i sprawy minimalnie się poprawiły, co zdawało się potwierdzać diagnozę. Ale to była nieprawidłowa lekcja.

Co mówiły logi

Powrót do logów serwera przedstawiał zupełnie inną historię. W żadnym z nich nie było ani jednego błędu braku pamięci. Wolna pamięć systemowa przez cały czas wynosiła komfortowe 21-27 gigabajtów, przy śladzie modelu wynoszącym 17 gigabajtów. Pamięć nigdy nie była problemem.

Prawdziwy problem stanowiła niezgodność konfiguracji, która nie generowała żadnego widocznego błędu. Konfiguracja agenta reklamowała context window o rozmiarze 32 768 tokenów. Ale serwer Ollama został restartowany z limitem 8192 tokenów i ta rozbieżność pozostała niewykryta. Agent szczęśliwie planował plik o 800 liniach do zapisania za jednym razem, bo z jego perspektywy miał do dyspozycji 32k zapasu. Kiedy faktyczna generacja uderzała w ścianę 8k w połowie tool call, połączenie było przerywane bez żadnego komunikatu, na którym agent mógłby się względnie oprzeć.

Druga komplikacja czaiła się w logach startowych: Ollama uruchomił się z włączonym context shifting, który pozwoliłby oknu przesuwać się przy wyczerpaniu miejsca, poświęcając starsze tokeny kosztem nowych. Ale architektura modelu nie obsługiwała tej funkcji, więc została cicho wyłączona. To, co powinno być miękkim limitem, stało się twardą ścianą.

DevOps, którego AI development wymaga

To doświadczenie skrystalizowało coś ważnego o lokalnym rozwoju AI, co entuzjazm wokół modeli open-weight ma tendencję zacierać. Kiedy uruchamiasz modele na własnym sprzęcie, nie piszesz tylko kodu — zarządzasz infrastrukturą. A infrastruktura wymaga tej samej dyscypliny diagnostycznej, zarządzania konfiguracją i uwagi do parametrów operacyjnych, co systemy produkcyjne.

Context window to nie abstrakcyjne właściwości modelu do ustawienia i zapomnienia. To parametry operacyjne, które wchodzą w interakcje z twoim łańcuchem narzędzi w nieoczywisty sposób. Kiedy skonfigurowany context agenta nie zgadza się z faktycznym limitem serwera, nie dostajesz ostrzeżenia — dostajesz ciche błędy, które wyglądają jak niekompetencja modelu, podczas gdy w rzeczywistości są operacyjną błędną konfiguracją.

Praktyczna rada dla deweloperów eksplorujących lokalne agenty AI jest prosta: waliduj swoje środowisko tak samo starannie, jak walidowałbyś wdrożenie produkcyjne. Sprawdź, czy konfiguracja agenta odpowiada twoim parametrom runtime. Czytaj logi serwera, nie tylko output agenta. Zrozum, jakie funkcje twoja architektura modelu faktycznie obsługuje w porównaniu z tym, co narzędzia próbują włączyć.

Modele stają się lepsze. Narzędzia dojrzewają. Ale przepaść między "działa w demo" a "działa niezawodnie w codziennym użytkowaniu" wciąż wymaga ludzkiego osądu do jej zbridgowania — a ten osąd wygląda bardzo jak tradycyjna dyscyplina DevOps zastosowana do nowej klasy infrastruktury.

Build Tetris w końcu się powiódł. Zajęło to cztery i pół godziny rozłożone na dwa dni, wyprodukował czysty kod w trzech plikach i działa poprawnie. Ale lekcje nie wyniknęły z sukcesu — tylko ze zrozumienia, dlaczego wystąpiły błędy, i uświadomienia sobie, że czasem najdroższe problemy nie mają nic wspólnego z inteligencją.