När AI:n gör bort sig av dumma anledningar

Det finns en särskild sortens frustration som uppstår när man ser ett intelligent system misslyckas av helt dumma skäl. Jag upplevde det nyligen när jag experimenterade med lokala AI-kodningsagenter – en trend som växer i takt med att open-weight-modeller blir bättre och integritetsmedveten utveckling får större betydelse.

Experimentet var enkelt: kan en kodningsagent som körs helt på lokal hårdvara bygga ett fungerande spel? Inte en trivial demo, utan något med riktig statushantering, rendering, input-hantering och ett spelbart gränssnitt. Svaret, efter betydande huvudkliande, var ja – men vägen dit avslöjade en klass av problem som AI-verktygsekosystemet inte hanterar särskilt elegant.

Installationen som borde ha funkat

Stacken bestod av tre komponenter som representerar det yppersta inom lokal AI-utveckling: en leverantörsoberoende kodningsagent CLI, Ollama som serverar ett OpenAI-kompatibelt API från localhost, och Qwen3.8 27B som kör på den lokala maskinen. För att sätta det i perspektiv: det här är ingen underdimensionerad setup – 27B-modellen på 17GB ryms bekvämt i 32GB unified memory och stödjer tool calling med respektabel resonemangsförmåga.

De första resultaten var lovande. Inom femton minuter hade agenten producerat en komplett HTML-struktur och nästan 200 rader NES-inspirerad CSS med fasade kanter och en korrekt färgpalett. Ännu mer imponerande: agenten fångade sitt eget misstag mitt i strömmen – den skrev en fil, läste tillbaka den, märkte en mismatch mellan vad den avsåg och vad som faktiskt hamnade på disk, och reparerade det utan att bli tillfrågad. Det är genuint agentiskt beteende, och det tydde på att modellen var kapabel till uppgiften.

Sedan försökte agenten skriva spelets logikfil, och allt stannade.

Dödsspiralen

Det som följde var en sekvens som alla som har kämpat med AI-verktyg kommer att känna igen. Tretton konsekutiva försök att skriva spelmotorn, var och en avbruten mitt i generationen. Strömmen dog helt enkelt, utan felmeddelande, utan förklaring, utan användbar output.

Det mest frustrerande var inte själva misslyckandet – det var att se agentens resonemangsprocess. Eftersom varje försök startade från scratch, deriverade modellen samma designbeslut på nytt från grunden och landade på olika poängtabeller och implementationsstrategier varje gång. Tre försök innebar tre olika svar på samma arkitekturfråga. Agenten ägnade en timme åt att tänka och levererade ingenting av det.

Den uppenbara skyldige verkade vara minnespress. Att stänga webbläsarflikar frigjorde flera gigabyte RAM och sakerna förbättrades marginellt, vilket verkade bekräfta diagnosen. Men det var fel läxa att ta med sig.

Vad loggarna faktiskt avslöjade

När jag gick tillbaka genom serverloggarna berättade de en annan historia. Det fanns inte ett enda out-of-memory-fel i någon av dem. Fritt systemminne låg bekvämt mellan 21 och 27 gigabyte genom hela processen, mot en 17-gigabyte modell footprint. Minnet var aldrig problemet.

Den verkliga orsaken var en konfigurationsmismatch som inte producerade något synligt fel. Agentens konfiguration annonserade ett 32 768-tokens context window. Men Ollama-servern hade startats om med ett 8 192-tokens tak, och denna diskrepans gick oupptäckt. Agenten planerade glatt en 800-raders fil att skriva i ett svep, för såvitt den visste hade den 32k utrymme. När den faktiska generationen träffade 8k-väggen mitt i tool-callet, bröts anslutningen utan felmeddelande som agenten kunde resonera kring.

Det fanns en sekundär komplikation som lurade i startup-loggarna: Ollama hade startat med context-shifting aktiverat, vilket skulle ha tillåtit fönstret att glida när det tog slut på utrymme och offra äldre tokens för att ge plats åt nya. Men modellens arkitektur stödde inte denna funktion, så den stängdes av tyst. Det som borde ha varit en mjuk gräns blev en hård vägg.

DevOps-disciplinen som AI-utveckling kräver

Denna erfarenhet kristalliserar något viktigt om lokal AI-utveckling som enthusiasmeten kring open-weight-modeller tenderar att dölja. När du kör modeller på din egen hårdvara skriver du inte bara kod – du opererar infrastruktur. Och infrastruktur kräver samma diagnostiska disciplin, konfigurationshantering och uppmärksamhet på operationella parametrar som produktionssystem kräver.

Context windows är inte abstrakta modellegenskaper att ställa in och glömma. De är operationella parametrar som interagerar med din verktygskedja på icke-uppenbara sätt. När en agents konfigurerade context inte matchar serverns faktiska tak, får du ingen varning – du får tysta fel som ser ut som modellinkompetens när de faktiskt är operativ felkonfiguration.

Den praktiska lärdommen för utvecklare som utforskar lokala AI-kodningsagenter är rak och enkel: validera din miljö lika noggrant som du validerar en produktionsinstallation. Kontrollera att din agents konfiguration matchar dina runtime-parametrar. Läs serverloggarna, inte bara agentens output. Förstå vilka funktioner din modellarkitektur faktiskt stödjer kontra vad verktygen försöker aktivera.

Modellerna blir bättre. Verktygen mognar. Men gapet mellan "fungerar i demos" och "fungerar pålitligt i daglig användning" kräver fortfarande mänskligt omdöme för att överbrygga – och det omdömet ser väldigt ut som traditionell DevOps-disciplin tillämpad på en ny klass av infrastruktur.

Tetris-bygget lyckades till slut. Det tog fyra och en halv timme över två dagar, producerade ren kod över tre filer, och fungerar korrekt. Men lärdomarna kom inte från framgången, utan från att förstå varför misslyckandena hände – och inse att ibland är de dyraste problemen helt orelaterade till intelligens.