Wenn künstliche Intelligenz an ganz banalen Dingen scheitert

Es gibt eine ganz besondere Art von Frustration, die man empfindet, wenn man zusehen muss, wie ein vermeintlich kluges System aus dumment Gründen versagt. Mir ist das neulich passiert, als ich mit lokalen AI-Coding-Agents experimentiert habe – ein Trend, der an Fahrt gewinnt, weil Open-Weight-Modelle immer besser werden und datenschutzbewusste Entwicklung an Bedeutung gewinnt.

Die Fragestellung war simpel: Kann ein Coding-Agent, der komplett auf eigener Hardware läuft, ein funktionierendes Spiel bauen? Kein triviales Demo-Projekt, sondern etwas mit echter State-Management, Rendering-Logik, Input-Handling und einer spielbaren Oberfläche. Die Antwort nach reichlichem Kopfzerbrechen: Ja, durchaus. Aber der Weg dorthin hat eine Problemklasse offengelegt, mit der das AI-Tooling-Ökosystem noch nicht gut umgeht.

Das Setup, das funktionieren sollte

Drei Komponenten bildeten das Fundament: ein anbieterunabhängiger Coding-Agent als CLI, Ollama als OpenAI-kompatibler API-Server auf localhost, und Qwen3.8 27B auf der lokalen Maschine. Das war kein unterdimensioniertes System – das 27B-Modell mit 17 GB passt entspannt in 32 GB Unified Memory und unterstützt Tool-Calling mit ordentlichen Reasoning-Fähigkeiten.

Die ersten Ergebnisse sahen vielversprechend aus. In fünfzehn Minuten hatte der Agent eine komplette HTML-Struktur und knapp 200 Zeilen NES-inspiriertes CSS produziert – mit abgeschrägten Cabinet-Styling und passender Farbpalette. Noch beeindruckender: Der Agent hat seinen eigenen Fehler mitten im Prozess bemerkt: Er hat eine Datei geschrieben, sie erneut gelesen, eine Abweichung zwischen seiner Absicht und dem Ergebnis auf der Festplatte erkannt und das Problem eigenständig behoben. Das ist echtes agentisches Verhalten und deutete darauf hin, dass das Modell der Aufgabe gewachsen war.

Dann versuchte der Agent, die Game-Logic-Datei zu schreiben – und alles kam zum Erliegen.

Die Abwärtsspirale

Was folgte, war eine Sequenz, die jeder wiedererkennen wird, der schon mit AI-Tooling gekämpft hat. Dreizehn aufeinanderfolgende Versuche, die Game-Engine-Datei zu schreiben, jeder einzelne wurde mitten in der Generierung abgebrochen. Der Stream starb einfach, ohne Fehlermeldung, ohne Erklärung, ohne brauchbare Ausgabe.

Das Schlimmste war nicht das Versagen an sich – es war der Blick auf den Reasoning-Prozess des Agents. Weil jeder Versuch bei Null startete, leitete das Modell dieselben Designentscheidungen immer wieder neu ab und landete jedes Mal bei unterschiedlichen Scoring-Tabellen und Implementierungsansätzen. Drei Wiederholungen bedeuteten drei verschiedene Antworten auf dieselbe Architekturfrage. Der Agent hat eine Stunde lang gedacht und nichts davon geliefert.

Der naheliegende Verdacht: Memory Pressure. Also habe ich Browser-Tabs geschlossen und несколько Gigabyte RAM freigegeben. Die Situation verbesserte sich marginal – was die Diagnose bestätigt zu haben schien. Aber das war die falsche Lektion.

Was die Logs tatsächlich verraten

Ein genauer Blick in die Server-Logs erzählte eine andere Geschichte. Nicht ein einziger Out-of-Memory-Fehler war zu finden. Der verfügbare Systemspeicher lag komfortabel zwischen 21 und 27 Gigabyte – bei einem 17-Gigabyte-Modell-Footprint. Speicher war nie das Problem.

Die eigentliche Ursache war ein Konfigurations-Mismatch, der keine sichtbare Fehlermeldung erzeugte. Die Agent-Konfiguration gab einen 32.768-Token-Context-Window vor. Aber der Ollama-Server war mit einem 8.192-Token-Limit neu gestartet worden, und diese Diskrepanz blieb unentdeckt. Der Agent plante fröhlich eine 800-Zeilen-Datei in einem Rutsch zu schreiben, weil er laut Konfiguration 32k Spielraum hatte. Als die tatsächliche Generierung die 8k-Grenze mitten im Tool-Call erreichte, wurde die Verbindung gekappt – ohne Fehlermeldung, mit der der Agent etwas hätte anfangen können.

Da war noch ein sekundäres Problem in den Startup-Logs versteckt: Ollama war mit aktivierter Context-Shifting-Funktion gestartet worden, die das Fenster hätte gleiten lassen können, wenn der Platz ausging – ältere Token opfern, um Platz für neue zu schaffen. Aber die Modellarchitektur unterstützte dieses Feature nicht, also wurde es stillschweigend deaktiviert. Aus einer weichen Grenze wurde eine harte Wand.

Die DevOps-Disziplin, die AI-Entwicklung verlangt

Diese Erfahrung hat etwas Wichtiges kristallisiert, das die Begeisterung um Open-Weight-Modelle gerne überschattet. Wenn du Modelle auf eigener Hardware betreibst, schreibst du nicht nur Code – du betreibst Infrastruktur. Und Infrastruktur erfordert dieselbe diagnostische Disziplin, Konfigurationsmanagement und Aufmerksamkeit für operative Parameter wie Produktionssysteme.

Context-Windows sind keine abstrakten Modelleigenschaften, die man einmal setzt und dann vergisst. Es sind operative Parameter, die mit deiner Tool-Chain auf nicht-offensichtliche Weise interagieren. Wenn ein Agents konfigurierter Context nicht zum tatsächlichen Limit des Servers passt, bekommst du keine Warnung – du bekommst stille Fehler, die nach Inkompetenz des Modells aussehen, aber tatsächlich operative Fehlkonfiguration sind.

Der praktische Rat für Entwickler, die lokale AI-Coding-Agents ausprobieren, ist klar: Validiere deine Umgebung so gründlich wie eine Produktionsumgebung. Prüfe, ob die Agent-Konfiguration zu deinen Runtime-Parametern passt. Lies die Server-Logs, nicht nur die Agent-Ausgabe. Verstehe, welche Features deine Modellarchitektur tatsächlich unterstützt – nicht nur, was das Tooling zu aktivieren versucht.

Die Modelle werden besser. Das Tooling reift. Aber die Lücke zwischen „funktioniert in Demos" und „funktioniert zuverlässig im täglichen Einsatz" erfordert immer noch menschliches Urteilsvermögen – und dieses Urteilsvermögen sieht verdammt nach traditioneller DevOps-Disziplin aus, angewandt auf eine neue Klasse von Infrastruktur.

Das Tetris-Build hat am Ende dann doch funktioniert. Vierundeinhalb Stunden über zwei Tage verteilt, sauberer Code in drei Dateien, und es läuft korrekt. Aber die Lehren kamen nicht aus dem Erfolg – sondern aus dem Verständnis, warum die Fehler passiert sind. Und daraus zu erkennen, dass die teuersten Probleme manchmal nichts mit Intelligenz zu tun haben.