Da jeg lot en KI bygge et spill – og oppdaget at problemet ikke var modellen

Det er en spesiell type frustrasjon som oppstår når du ser et intelligent system feile av dumme grunner. Jeg opplevde dette nylig mens jeg eksperimenterte med lokale KI-kodeagenter – et felt som vokser i takt med at open-weight-modeller blir bedre og flere utviklere prioriterer personvern.

Eksperimentet

Spørsmålet var enkelt: kan en kodeagent som kjører lokalt på min egen maskin bygge et funksjonelt spill? Ikke en trivial demo, men noe med ekte tilstandsbehandling, rendering, input-håndtering og et spillbart grensesnitt.

Stacken besto av tre komponenter som representerer toppen av lokal KI-utvikling: en provider-agnostisk kodeagent-CLI, Ollama som serverer en OpenAI-kompatibel API fra localhost, og Qwen3.8 27B kjørende lokalt. For kontekst: dette er intet underspilt oppsett. 27B-modellen på 17 GB passer komfortabelt i 32 GB united memory og støtter verktøykall med brukbare resonnementsevner.

Starten så lovende ut

De første resultatene var oppmuntrende. På femten minutter hadde agenten produsert en komplett HTML-struktur og nesten 200 linjer med NES-inspirert CSS med fasetterte kanter og en korrekt fargepalett. Enda mer imponerende: agenten fanget opp sin egen feil underveis. Den skrev en fil, leste den på nytt, oppdaget en uoverensstemmelse mellom intensjon og resultat, og reparerte det uten prompting. Det er genuint agentisk atferd, og det tydet på at modellen var kapabel.

Deretter prøvde agenten å skrive spillogikk-filen, og alt stoppet.

Tretten forsøk, null progresjon

Det som fulgte var en sekvens alle som har slitt med KI-verktøy vil kjenne igjen. Tretten påfølgende forsøk på å skrive spillmotorfilen, avbrutt midt i genereringen. Streamen døde rett og slett – ingen feilmelding, ingen forklaring, ingen brukbar output.

Det verste var ikke selve feilen. Det verste var å følge agentens resonnement. Fordi hvert forsøk startet på nytt, måtte modellen utlede de samme designbeslutningene på nytt hver gang. Tre forsøk ga tre ulike svar på samme arkitektoniske spørsmål. Agenten brukte en time på å tenke og leverte ingenting.

Den opplagte skyldige virket å være minnepress. Da jeg lukket nettleserfaner og frigjorde flere gigabyte RAM, ble ting marginalt bedre. Det bekreftet diagnosen. Men dette var feil lærdom.

Hva loggene faktisk viste

Da jeg gikk gjennom serverloggene, fortalte de en annen historie. Ikke én eneste out-of-memory-feil noe sted. Ledig systemminne holdt seg komfortabelt mellom 21 og 27 gigabyte gjennom hele prosessen, mot et 17-gigabyte modellavtrykk. Minne var aldri problemet.

Det virkelige problemet var en konfigurasjonsfeil som ikke ga noen synlig feilmelding. Agentens konfigurasjon annonserte et 32 768-token kontekstvindu. Men Ollama-serveren hadde blitt omstartet med et 8 192-token tak, og denne uoverensstemmelsen gikk ubemerket. Agenten planla glatt en 800-linjers fil i én omgang, fordi den ifølge sin egen konfigurasjon hadde 32k tilgjengelig. Da den faktiske genereringen traff 8k-grensen midt i et verktøykall, ble tilkoblingen kuttet uten noen feilmelding agenten kunne resonnere seg frem til.

Det var også en sekundær komplikasjon i oppstartsloggene: Ollama hadde lansert med context-shifting aktivert, noe som ville tillatt vinduet å gli når det gikk tomt – ofrer eldre tokens for å gi plass til nye. Men modellens arkitektur støttet ikke denne funksjonen, så den ble stille deaktivert. Det som skulle vært en myk grense ble en hard mur.

DevOps-disciplinen KI-utvikling krever

Denne opplevelsen krystalliserer noe viktig om lokal KI-utvikling som entusiastene rundt open-weight-modeller har en tendens til å overse. Når du kjører modeller på egen maskin, skriver du ikke bare kode – du drifter infrastruktur. Og infrastruktur krever samme diagnostiske disiplin, konfigurasjonsstyring og oppmerksomhet på operasjonelle parametere som produksjonssystemer.

Kontekstvinduer er ikke abstrakte modellegenskaper du setter og glemmer. De er operasjonelle parametere som samhandler med verktøykjeden din på ikke-opplagte måter. Når en agents konfigurerte kontekst ikke matcher serverens faktiske tak, får du ingen advarsel. Du får stille feil som ser ut som modelligjenskap, men som egentlig er operasjonell feilkonfigurasjon.

Praktiske lærdommer

For utviklere som utforsker lokale KI-kodeagenter er takeaways rett frem:

• Valider miljøet like grundig som en produksjonsutrulling. Sjekk at agentens konfigurasjon matcher runtime-parametere.
• Les serverloggene, ikke bare agentoutput.
• Forstå hvilke funksjoner modellarkitekturen faktisk støtter versus hva verktøyene forsøker å aktivere.

Tetris-byggingen lyktes til slutt. Det tok fire og en halv time over to dager, produserte ren kode på tvers av tre filer, og fungerer korrekt. Men lærdommene kom ikke fra suksessen – de kom fra å forstå hvorfor feilene skjedde. Og fra å erkjenne at de dyreste problemene noen ganger ikke har noe som helst med intelligens å gjøre.