Waarom mijn lokale AI-coderingsagent struikelde over iets heel doms

Er komt een bijzondere vorm van frustratie kijken bij het aanzien van een intelligent systeem dat faalt om stomme redenen. Dat ondervond ik onlangs tijdens een experiment met lokale AI-coderingsagents – een trend die terrein wint nu open-gewicht modellen steeds capabeler worden en privacy-bewust ontwikkelen aan belang wint.

Het experiment was simpel: kan een coderingsagent die volledig op lokale hardware draait een werkend spelletje bouwen? Geen triviale demo, maar iets met échte state management, render logica, input handling en een speelbare interface. Het antwoord, na heel wat gekrab in het haar, was ja – maar erheen komen legde een klasse problemen bloot waar het AI tooling-ecosysteem niet elegant mee omgaat.

De Opzet Die Zou Moeten Werken

De stack bestond uit drie componenten die het scherpste mes vormen van lokale AI-ontwikkeling: een provider-agnostische coding agent CLI, Ollama die een OpenAI-compatibele API serveert vanaf localhost, en Qwen3.8 27B op de lokale machine. Voor de context: dit is geenUnderpowered opzet – het 27B model met 17GB past comfortabel in 32GB unified memory en ondersteunt tool calling met redelijke reasoning capabilities.

De eerste resultaten waren veelbelovend. Binnen vijftien minuten had de agent een complete HTML-structuur geproduceerd en bijna 200 regels NES-geïnspireerde CSS met afgeschuinde kaststijl en een correct kleurenpalet. Nog indrukwekkender: de agent pakte zijn eigen fout op midden in de stream. Hij schreef een bestand, las het terug, merkte een mismatch op tussen wat hij bedoelde en wat er op disk belandde, en repareerde het zonder aansporing. Dat is echte agentic behavior, en het suggereerde dat het model de taak aankon.

Toen de agent vervolgens het game logic bestand probeerde te schrijven, stopte alles.

De Doodspiraal

Wat volgde was een sequentie die iedereen herkent die met AI tooling heeft geworsteld. Dertien opeenvolgende pogingen om het game engine bestand te schrijven, elk afgekapt midden-generatie. De stream stierf simpelweg – geen error, geen uitleg, geen bruikbare output.

Het meest verstikkende was niet de mislukking zelf – het was het kijken naar het reasoning proces van de agent. Omdat elke poging vanaf nul begon, leidde het model telkens dezelfde ontwerpbeslissingen opnieuw af, met telkens andere scoring tables en implementatie-benaderingen. Drie retries betekende drie verschillende antwoorden op dezelfde architecturale vraag. De agent besteedde een uur aan denken en leverde niets.

De voor de hand liggende boosdoener leek geheugendruk te zijn. Browser tabs sluiten freeede verschillende gigabytes RAM en de situatie verbeterde marginaal, wat de diagnose leek te bevestigen. Maar dit was de verkeerde les om uit te trekken.

Wat De Logs Werkelijk Onthulden

Terugscrollen door de server logs vertelde een heel ander verhaal. Er was niet één out-of-memory error in welk van hen dan ook. Vrij systeemgeheugen zat comfortabel tussen 21 en 27 gigabyte gedurende het hele proces, tegenover een 17-gigabyte model footprint. Geheugen was nooit het probleem.

Het échte issue was een configuratie-mismatch die geen zichtbare error produceerde. De agent's config adverteerde een 32.768-token context window. Maar de Ollama server was herstart met een 8.192-token plafond, en dit verschil bleef onopgemerkt. De agent plantte vrolijk een 800-regelig bestand om in één keer te schrijven, omdat het naar zijn idee 32k aan headroom had. Toen de daadwerkelijke generatie de 8k muur raakte midden-tool-call, werd de verbinding verbroken zonder error message die de agent kon reasonen over.

Er was een secundaire complicatie verscholen in de startup logs: Ollama was gelanceerd met context-shifting ingeschakeld, wat het window zou hebben laten schuiven wanneer het ruimte tekortkwam – oudere tokens opofferend om plaats te maken voor nieuwe. Maar de model's architectuur ondersteunde deze feature niet, dus het was stilzwijgend uitgeschakeld. Wat een soft limit had moeten zijn, werd een harde muur.

De DevOps Discipline Die AI-Ontwikkeling Vereist

Deze ervaring kristalliseert iets belangrijks over lokale AI-ontwikkeling dat het enthousiasme rond open-gewicht modellen geneigd is te verhullen. Wanneer je modellen draait op je eigen hardware, schrijf je niet alleen code – je beheert infrastructuur. En infrastructuur vereist dezelfde diagnostische discipline, configuration management en aandacht voor operationele parameters die productiesystemen vereisen.

Context windows zijn geen abstracte model properties om in te stellen en te vergeten. Het zijn operationele parameters die interacteren met je tool chain op niet voor de hand liggende manieren. Wanneer een agent's geconfigureerde context niet overeenkomt met het server's werkelijke plafond, krijg je geen waarschuwing – je krijgt stille failures die eruitzien als model incompetentie terwijl het eigenlijk operationele misconfiguratie is.

De praktische takeaway voor developers die lokale AI coding agents verkennen is recht voor z'n raap: valideer je omgeving zo grondig als je een productie-deploy zou valideren. Check dat de configuratie van je agent overeenkomt met je runtime parameters. Lees de server logs, niet alleen de agent output. Begrijp welke features je model architectuur daadwerkelijk ondersteunt versus wat de tooling probeert in te schakelen.

De modellen worden beter. De tooling rijpt. Maar de kloof tussen "werkt in demos" en "werkt betrouwbaar in dagelijks gebruik" vereist nog steeds menselijk oordeel om te overbruggen – en dat oordeel ziet er veel uit als traditionele DevOps discipline toegepast op een nieuwe klasse infrastructuur.

De Tetris build is uiteindelijk gelukt. Het kostte viereneenhalf uur verspreid over twee dagen, produceerde schone code over drie bestanden, en functioneert correct. Maar de lessen kwamen niet van het succes, maar van het begrijpen waarom de failures plaatsvonden – en het herkennen dat soms de duurste problemen niets met intelligentie te maken hebben.