Lokale KI-Modelle zum Programmieren: was sie leisten und wo du nachprüfen musst

Wer ein KI-Modell für Programmierarbeit sucht, schaut auf die Ranglisten und nimmt das größte, das noch in den Speicher passt. In unserem Test hat ausgerechnet das Modell mit dem längsten Nachdenken einen Fehler eingebaut, der schlimmer war als der, den es beheben sollte. Gewonnen hat eines, das überhaupt nicht nachdenkt.

Der Test lief im August 2026 auf einem MacBook Pro M5 Max mit 128 GB Arbeitsspeicher, gestartet über LM Studio. 8 Modelle bekamen nacheinander dasselbe fremde Programm und denselben Auftrag, keines hatte eine Verbindung nach außen.

So haben wir getestet

Die Ranglisten im Netz beruhen fast alle auf denselben öffentlichen Aufgabensammlungen, und die kennen die Modelle längst aus dem Training. Bei SWE-bench Verified, dem meistzitierten Test für Programmierarbeit, waren die 500 Aufgaben online, bevor der Test veröffentlicht wurde. Eine interne Prüfung von OpenAI zeigte, dass große Modelle für einen Teil davon die hinterlegte Musterlösung wörtlich wiedergeben können (CodeAnt AI, 2026). Wie groß der Effekt ist, zeigt der Abstand zur schwereren Variante desselben Tests. Bei den zum Prüfzeitpunkt führenden Modellen standen dort 80,9 % gegen 45,9 %.

Deshalb haben wir ein eigenes Programm geschrieben, das es vorher nirgends gab. 179 Zeilen, 16 eingebaute Fehler, jeder aus einer anderen Familie. Ein paar davon legen es sofort lahm, andere zeigen sich erst, wenn mehrere Vorgänge gleichzeitig laufen, und 2 sieht man überhaupt nicht. Das Programm startet, läuft und wirkt beim Draufschauen unauffällig.

Jedes Modell sollte die Fehler finden, sie reparieren, eine Funktion ergänzen und mit eigenen Tests belegen, dass die Reparatur stimmt. Wie viele Fehler drinsteckten, stand nicht in der Aufgabe. Von den 100 Punkten entfallen 35 auf die Fehlerliste, 25 auf das reparierte Programm, 15 auf die Tests, 10 auf die neue Funktion, 10 auf eine Analysefrage und 5 auf die eingehaltene Form. Die gelieferten Dateien liefen anschließend gegen dieselben 14 automatischen Prüfungen, für alle Modelle identisch. Das ursprüngliche, fehlerhafte Programm besteht davon 4.

Laguna meldet 7 Fehler und repariert 14

Laguna S 2.1 von Poolside meldet 7 Fehler und hat in Wahrheit 14 repariert. Seine Fassung besteht als einzige alle 14 Prüfungen, fertig war es nach 2 Minuten und 20 Sekunden. Dabei denkt das Modell vorher nicht nach, es schreibt sofort los und verbraucht dafür 0 Token. Ornith auf Platz 4 kam an derselben Stelle auf 17.656. Muse Glimmer brauchte mit 9:50 Minuten das Vierfache des Siegers und liefert dafür die beste Analyse der Architektur im ganzen Feld.

Auch die Größe entscheidet wenig. Qwen 3.6 belegt 41 GB und kommt auf 47 Punkte, Agents A1 braucht 38 GB und steht mit 34 Punkten am Ende. Dazwischen holt Gemma 4 31B mit 18 GB ganze 66 Punkte, also 1 Punkt weniger als der Sieger bei einem Drittel des Speichers.

Keines der 8 Modelle hat einen Fehler gemeldet, den es gar nicht gibt, obwohl falsche Meldungen in unserer Bewertung Punkte gekostet hätten und die Zahl der eingebauten Fehler nirgends stand. Wer eine dieser Listen durchgeht, verliert keine Zeit mit erfundenen Meldungen.

Ornith findet 9 Fehler und baut einen neuen ein

Ornith 1.0 35B stammt von DeepReinforce, steht seit Juni 2026 unter der MIT-Lizenz und darf damit auch kommerziell genutzt werden. Es fand als einziges Modell alle 3 Fehler, die nur auftreten, wenn mehrere Vorgänge gleichzeitig laufen. Darunter war eine gegenseitige Blockade, bei der 2 Kopien des Programms wechselseitig aufeinander warten und beide nicht weiterkommen.

Der Reparaturansatz dafür steht so im Lehrbuch. Man gibt eine feste Reihenfolge vor, in der die beiden Kopien gesperrt werden, dann kann die Blockade nicht mehr entstehen. Ornith hat diese Reihenfolge korrekt gebaut. Eine Zeile darunter hat es dann beim Kopieren der Daten die eigene Kopie mit der des Partners verwechselt, ein einziges Wort Unterschied.

Die Folge steht in keiner Fehlermeldung. Beim Abgleich zweier Kopien übernimmt die eine in etwa der Hälfte aller Fälle ihre eigenen Daten statt die der anderen. Welchen Durchlauf es trifft, hängt davon ab, wo die Daten gerade im Speicher liegen, der Fehler tritt also nicht zuverlässig auf. Im laufenden System ist das schlimmer als der Fehler davor, weil eine Blockade sichtbar hängt und verlorene Daten niemandem auffallen.

Zu dieser Reparatur hat Ornith selbst einen Test geschrieben, test_a8_merge_reference_sharing. Der Test läuft genau in den neuen Fehler hinein und bricht mit KeyError: 'e1' ab, im Klartext also mit dem Hinweis, dass ein Datensatz fehlt, der da sein müsste. Das Modell hat den Beweis für seinen eigenen Fehler selbst geliefert.

DeepReinforce wirbt für Ornith mit genau dieser Fähigkeit. Das Modell lerne, sich zu jeder Aufgabe das passende Prüfgerüst selbst zu bauen, heißt es in der Veröffentlichung vom Juni 2026, und die Modellkarte nennt für die 35B-Variante 75,6 Punkte auf SWE-bench Verified. Diesen Test hat Ornith tatsächlich geschrieben. Niemand hat ihn danach ausgewertet, und in unserem Aufbau konnte das Modell es auch nicht, weil keines sein Programm ausführen durfte.

Seit dem 19. August 2026 gibt es einen Nachfolger. Ornith 1.5 ist wieder ein 35B mit 3 Milliarden aktiven Parametern und steht wieder unter MIT, die Modellkarte nennt jetzt 79,0 Punkte auf SWE-bench Verified statt 75,6. Wir haben die neue Fassung nicht getestet, alle Zahlen in diesem Artikel stammen aus dem Lauf mit 1.0. Eine öffentlich dokumentierte Nachrechnung kam bei mehreren Tests deutlich niedriger heraus als die Modellkarte, unabhängig gemessen hat bislang niemand.

Der Fehler, der nicht wie ein Fehler aussieht

Einer der 16 eingebauten Fehler blieb 6 von 8 Modellen verborgen, und er unterscheidet sich von allen anderen. Eine Prüffunktion vergleicht 2 Stände des Programms und soll melden, welcher der neuere ist. Sie meldet auch dann “neuer”, wenn beide gleich alt sind. Der Code dafür ist korrekt geschrieben und liest sich unauffällig, kein Prüfwerkzeug schlägt daran an. Falsch ist die Regel dahinter, und die kennt nur, wer die Fachlogik des Programms verstanden hat.

Gefunden haben ihn Laguna S 2.1 und Muse Glimmer. Für die übrigen hat das Folgen über diesen einen Fehler hinaus. Gemma 4 26B A4B hat an derselben Stelle eine sorgfältige Reparatur gebaut, die ins Leere läuft, weil der Vergleich darunter weiterhin falsch entscheidet. Der eigene Test des Modells fällt deshalb durch, an der eigenen, reparierten Fassung.

Im Schnitt fanden die Modelle 6,6 der 16 Fehler, und keines weist von sich aus darauf hin, dass seine Liste kürzer ausfallen könnte als die Wirklichkeit. Zuverlässig finden sie, was wie ein Fehler aussieht; für alles, was erst aus der Fachlogik heraus falsch wird, bleibt die Prüfung bei jemandem, der das Programm kennt.

Tests, die nichts beweisen

Ein Test ist nur dann ein Nachweis, wenn er am fehlerhaften Programm scheitert und an der reparierten Fassung durchläuft. Genau das hatten wir verlangt. Ein Test, der auch am kaputten Programm bestanden hätte, beweist nichts. Geschafft hat es 1 von 8 Modellen, Gemma 4 31B von Google. Es kommt mit 18 GB aus, landet 1 Punkt hinter dem Sieger und hat als feinste Einzelbeobachtung des Tests nicht den naheliegenden Zwischenspeicher als Speicherleck gemeldet, sondern eine Liste, die bei jedem verspäteten Datensatz stillschweigend mitwächst.

Bei 6 weiteren Modellen überführen die selbst geschriebenen Tests die selbst geschriebene Lösung, ohne dass es auffällt. Bei Agents A1 startet das gelieferte Programm gar nicht, weil in den ersten Zeilen ein Baustein fehlt. Wie im Fall von Ornith liest keines der Modelle den eigenen Test gegen die eigene Arbeit. Wer sie in eine Umgebung stellt, in der Tests automatisch laufen, holt genau diesen Schritt zurück.

Ähnlich sieht es aus, wenn die Modelle ihre eigene Arbeit einschätzen sollen. Zum Schluss hatten wir gefragt, welche der geforderten Eigenschaften sich in diesem Programm gar nicht sicherstellen lässt. Agents A1 antwortete, es seien alle erfüllbar, und räumte einen Absatz später das Gegenteil ein. Dieselbe Antwort enthält davor eine korrekte Fehleranalyse.

Was der Test nicht abdeckt, gehört dazu. Gemessen wurde die Reparatur eines fremden Python-Programms, kein Neubau einer Anwendung und keine Weboberfläche. Jedes Modell hatte genau einen Durchlauf, und weil Antworten bei jedem Lauf etwas anders ausfallen, kann ein zweiter Durchgang eine andere Punktzahl ergeben. Die Modelle arbeiteten außerdem aus einem einzigen Auftrag heraus, ohne Dateien zu öffnen oder nachzufragen. In einer Entwicklungsumgebung mit Werkzeugzugriff sähen die Ergebnisse anders aus.

Die Ausstattung beginnt bei 64 GB

Ein Rechner braucht über den reinen Modellbedarf hinaus Luft für das Betriebssystem, den Editor und den Text, den das Modell gerade verarbeitet. Wir rechnen dafür rund 10 GB oben drauf. Damit fällt der Einstieg mit 32 GB Arbeitsspeicher heraus, denn dort laufen nur die schwächeren Modelle des Feldes, und deren Reparaturen kosten in der Nacharbeit mehr, als die Hardware einspart.

Ein MacBook Pro M5 Max mit 64 GB kostet im 14-Zoll-Gehäuse 5.899 Euro. Alles aus dem Testfeld läuft darauf außer Laguna S 2.1, und das beste dort erreichbare Ergebnis liegt mit Gemma 4 31B bei 66 Punkten. Das Gerät passt in die Tasche und braucht keinen Serverraum.

Mit 128 GB kostet dasselbe Gerät 7.659 Euro. Dort passt Laguna S 2.1 mit seinen 57 GB hinein, das einzige Modell, dessen Programm alle 14 Prüfungen besteht. Außerdem liegen 2 Modelle gleichzeitig im Speicher, sodass sich ihre Antworten direkt vergleichen lassen.

Die NVIDIA RTX PRO 6000 hat 96 GB Grafikspeicher und kostet ab rund 12.500 Euro netto, dazu kommt eine Workstation als Basis. Sie liest mit 1.792 GB/s gegenüber 614 GB/s beim M5 Max, zieht dafür 600 W und steht fest an einem Ort.

Wie viele Wörter ein geladenes Modell pro Sekunde ausgibt, hängt vor allem an dieser Speicherbandbreite, und dort liegt fast ein Faktor 3 zwischen Notebook und Karte. Gemessen haben wir die RTX PRO 6000 in diesem Test nicht, alle 8 Modelle liefen auf dem Mac. Sobald mehrere Entwickler dasselbe Modell gleichzeitig nutzen, gehört es trotzdem auf eine solche Karte. Wer beim Kunden arbeitet und dort ohne Netzzugang auskommt, bleibt beim Notebook.

Auf Apple Silicon fehlt außerdem CUDA, die Programmierschnittstelle von NVIDIA, auf die ein großer Teil der KI-Software aufsetzt. Serverseitige Werkzeuge wie vLLM laufen dort nur eingeschränkt, während LM Studio und Ollama nativ arbeiten. Für einen einzelnen Arbeitsplatz spielt das kaum eine Rolle, für einen gemeinsam genutzten Modellserver schon.

Was vor dem ersten Einsatz geklärt sein muss

Es braucht automatische Tests, die schon vor dem KI-Einsatz existieren, und einen Durchlauf des gelieferten Programms, bevor es jemand übernimmt. Wer beides ohnehin hat, weil es zur Arbeitsweise gehört, bekommt Reparaturen in Minuten statt in Stunden und behält den Quelltext dabei auf der eigenen Hardware.

Die Vollständigkeit der Fehlerliste beurteilt weiterhin ein Mensch, und über die Reparatur schaut jemand drüber, der das Programm kennt. Wir empfehlen deshalb, mit der Fehlersuche anzufangen, wo eine Zweitmeinung sofort nützt, und die Reparaturen erst dann zu übernehmen, wenn die eigenen Tests dafür fertig geschrieben sind.

Wer das Finden und das Reparieren zusammen will, braucht in diesem Feld 2 Modelle und einen Menschen, der zwischen ihnen entscheidet. Auf einem Notebook für 7.659 Euro liegen beide gleichzeitig im Speicher.