Når din lokale AI har højdesyge uden at klage

Der er en helt særlig form for frustration forbundet med at se et intelligent system fejle af dumme grunde. Jeg oplevede det for nylig, da jeg eksperimenterede med lokale AI-kodningsagenter – et felt der vinder frem i takt med, at open-weight modeller bliver bedre, og privatlivets fred i softwareudvikling får større betydning.

Spørgsmålet var simpelt: Kan en kodningsagent, der udelukkende kører på lokal hardware, bygge et funktionelt spil? Ikke en trivial demo, men noget med ægte statushåndtering, rendermotor, inputhåndtering og et spilleligt interface.

Svaret var ja – men vejen derhen afslørede en række problemer, som AI-værktøjsøkosystemet ikke håndterer særlig elegant.

Setuppet der burde virke

Stacken bestod af tre komponenter, der repræsenterer det ypperste inden for lokal AI-udvikling: en provider-agnostisk kodningsagent CLI, Ollama der serverer en OpenAI-kompatibel API fra localhost, og Qwen3.8 27B kørende på maskinen. For kontekst: dette er ikke en underpowered opsætning. 27B-modellen fylder 17 GB og sidder fint i 32 GB unified memory med respektabel reasoning-kapacitet.

De første resultater var lovende. På femten minutter havde agenten produceret en komplet HTML-struktur og næsten 200 linjer NES-inspired CSS med afskårne cabinet-kantninger og en ordentlig farvepalette.

Endnu mere imponerende fangede agenten sin egen fejl undervejs: Den skrev en fil, læste den igen, opdagede uoverensstemmelse mellem hensigt og resultat, og reparerede det uden at blive bedt om det. Det er ægte agentisk adfærd – og det antydede, at modellen var til opgaven.

Så forsøgte agenten at skrive spilogikfilen, og alt stoppede.

Dødsspiralen

Det, der fulgte, var en sekvens som enhver, der har kæmpet med AI-værktøjer, vil genkende. Tretten forsøg i træk på at skrive game engine-filen, hver gang afbrudt midt i generationen. Streamen døde bare – ingen fejl, ingen forklaring, intet brugbart output.

Det mest irriterende var ikke selve fejlen. Det var at se agentens reasoning-proces. Fordi hvert forsøg startede forfra, måtte modellen gentage de samme designbeslutninger fra bunden. Tre forsøg betød tre forskellige svar på det samme arkitektoniske spørgsmål. Agenten brugte en times tankearbejde på at producere præcis ingenting.

Den oplagte skyldige var hukommelsespres. Jeg lukkede browserfaner, frigjorde adskillige gigabytes RAM, og tingene forbedrede sig marginalt. Det bekræftede diagnosen. Men det var den forkerte konklusion.

Hvad logfilerne faktisk viste

En gennemgang af serverloggene fortalte en anden historie. Ikke én eneste out-of-memory fejl. Ledig systemhukommelse lå komfortabelt mellem 21 og 27 gigabyte gennem hele forløbet mod et 17 gigabyte model-footprint. Hukommelsen var aldrig problemet.

Det egentlige problem var en konfigurationsMismatch uden synlig fejl. Agentens config reklamerede med en 32.768 token context window. Men Ollama-serveren var blevet genstartet med et 8.192 token loft, og denne uoverensstemmelse gik ubemærket hen. Agenten planlagte gerne at skrive en 800-linjers fil i ét hug, fordi den ifølge sin config havde 32k headroom. Da den faktiske generation ramte 8k-væggen midt i et tool-call, blev forbindelsen afbrudt uden fejlbesked, som agenten kunne forholde sig til.

Der var en sekundær komplikation i startup-loggene: Ollama var startet med context-shifting aktiveret, hvilket ville have ladet vinduet glide, når det løb tør for plads. Men modellens arkitektur understøttede ikke funktionen, så den blev lydløst deaktiveret. Det, der burde have været en blød grænse, blev en hård væg.

DevOps-disciplinen som AI-udvikling kræver

Denne oplevelse krystalliserer noget vigtigt om lokal AI-udvikling, som den berettigede interesse for open-weight modeller har tendens til at skjule. Når du kører modeller på din egen hardware, skriver du ikke kun kode – du driver infrastruktur. Og infrastruktur kræver den samme diagnostiske disciplin, konfigurationsstyring og opmærksomhed på operationelle parametre som produktionssystemer.

Context windows er ikke abstrakte modelegenskaber, man sætter og glemmer. De er operationelle parametre, der interagerer med din værktøjskæde på ikke-indlysende måder. Når en agents konfigurerede context ikke matcher serverens faktiske loft, får du ikke en advarsel. Du får lydløse fejl, der ligner modelinkompetence, men faktisk er operationel miskonfiguration.

Den praktiske lærdom for udviklere, der udforsker lokale AI-kodningsagenter, er klar: valider dit miljø lige så grundigt som en produktionsinstallation. Tjek at din agents konfiguration matcher dine runtime-parametre. Læs serverloggene – ikke kun agentoutputtet. Forstå hvilke funktioner din modelarkitektur faktisk understøtter versus hvad værktøjerne forsøger at aktivere.

Modellerne bliver bedre. Værktøjerne modnes. Men kløften mellem "virker i demoer" og "virker pålideligt i daglig brug" kræver stadig menneskelig dømmekraft – og den dømmekraft ligner i høj grad traditionel DevOps-disciplin anvendt på en ny klasse af infrastruktur.

Tetris-byggeriet lykkedes til sidst. Det tog fire en halv time over to dage, producerede ren kode på tværs af tre filer, og fungerer korrekt. Men læringen kom ikke af succesen. Den kom af at forstå, hvorfor fejlene skete – og af at indse, at nogle gange har de dyreste problemer intet at gøre med intelligens.