AutoBe: Wie schwache lokale LLMs die Architektur eines KI-Backend-Generators verbesserten

Was geschah
AutoBe ist ein Open-Source-KI-Agent, der vollständige Backend-Anwendungen mit TypeScript, NestJS und Prisma generiert. Anfangs erreichte er 100% Kompilierungserfolg, aber der Code war unwartbar – es gab keine Wiederverwendung von Code, sodass jede kleine Änderung eine Neugenerierung von allem erforderte. Das Team baute das System um modulare Codegenerierung herum neu auf, was die Erfolgsrate sofort auf 40% abstürzen ließ.
Der Debugging-Durchbruch
Als die neue Architektur Abhängigkeiten zwischen Modulen einführte, nutzte das Team absichtlich schwache lokale LLMs, um Fehler zu finden, von denen sie nicht wussten, dass sie existierten. Das qwen3-30b-a3b-thinking-Modell hatte eine Erfolgsrate von etwa 10% und deckte AST-Schema-Mehrdeutigkeiten und fehlerhafte Strukturen auf. Das qwen3-next-80b-a3b-instruct-Modell hatte eine Erfolgsrate von etwa 20% und offenbarte Typinkonsistenzen und Randfälle in verschachtelten Beziehungen.
Diese niedrige Erfolgsrate war wertvoll: Jede Korrektur straffte das gesamte System. Wenn ein Schema präzise genug ist, dass ein 30B-Modell es nicht falsch interpretieren kann, werden stärkere Modelle es ebenfalls nicht falsch verstehen. Dieser Ansatz hebt auch den Kostenvorteil lokaler LLMs hervor – das Aufdecken von Randfällen erfordert Hunderte von Generierungs-Kompilierungs-Diagnose-Zyklen, was zu Cloud-API-Preisen unerschwinglich teuer wäre.
Architekturwechsel
Das Team wechselte von Prompt-Engineering zu Schema-Design mit Validierungsfeedback. Sie reduzierten System-Prompts auf fast nichts und verlagerten alle Einschränkungen in Funktionsaufruf-Schemas, sodass das Validierungsfeedback die Lehre übernahm. AutoBe verwendet drei AST-Typen, die für LLMs besonders herausfordernd zu generieren sind: AutoBeDatabase (Prisma-Modelle, Beziehungen, Indizes), AutoBeOpenApi (OpenAPI-Schemas, Endpunkte, DTOs) und AutoBeTest (30+ Ausdruckstypen).
Diese Strukturen sind schwierig, weil sie unbegrenzte Union-Typen, unbegrenzte Tiefe und rekursive Referenzen beinhalten. Beispielsweise enthält der Compiler-AST Typen wie IArrayLiteralExpression und IObjectLiteralExpression, die rekursive Referenzen zu IExpression[] enthalten.
Ergebnisse
Allein durch Validierungsfeedback verbesserte sich das Team von 6,75% rohem Funktionsaufruf-Erfolg auf 100%. Sie sind jetzt mit GLM v5 wieder bei 100% Erfolg, und andere lokale Modelle steigen in der Leistung.
📖 Read the full source: r/LocalLLaMA
👀 Siehe auch

Erkundung von LiveDocs: Ein KI-natives Datenanalyse-Notebook
LiveDocs bietet eine reaktive Notebook-Umgebung, die es Datenteams ermöglicht, mehrstufige Analysen durchzuführen und die Analyse von Anfang bis Ende mit Hilfe eines KI-Agenten aufrechtzuerhalten.

OpenClaw-Entwickler baut Kumiho kognitives Speicher-Plugin für persistente Agenten-Kollaboration
Ein Entwickler hat Kumiho erstellt, ein KI-Kognitives Gedächtnissystem, das auf einem Wissensgraphen basiert, um OpenClaws fehlendes Gedächtnis über Sitzungen hinweg zu beheben. Das Plugin openclaw-kumiho greift in Gespräche ein, um Kontext abzurufen, strukturierte Zusammenfassungen zu erfassen und versionierte kreative Ergebnisse zu erhalten.

Entwickler baut Terminal-Statusleiste zur Überwachung der Claude-Code-Sitzungslimits nach unerwartetem Abbruch
Ein Entwickler hat eine Python-Terminal-Statuszeile erstellt, die die Sitzungsnutzung von Claude Code live anzeigt, nachdem er mitten in einer Refaktorisierung ohne Vorwarnung abgeschnitten wurde. Das Tool verwendet bestehende Sitzungen und erfordert keinen API-Schlüssel.

Pi-Coding-Agent mit Qwen 35B Q2: Dateisystem als externen Speicher nutzen und Kontextschutz erzwingen
Ein Reddit-Nutzer hat einen Stack um den Pi-Coding-Agenten mit Qwen 35B Q2_K_XL-Quantisierung gebaut, der Schutzmechanismen durchsetzt – bearbeitet keine Ausgaben über 100 Zeilen, begrenzt Denkblöcke auf 2000 Zeichen und überwacht den Kontext bei 65 %/80 % – und das Dateisystem als Gedächtnis des Modells behandelt, nicht den Kontextfenster.