+49 173 5926916

info@mwolff.org

Butjadinger Straße 34a, 28197 Bremen

Manfred.Wolff

Die restlichen 10 bis 20 Prozent

Meine Faustregel aus der Praxis: 80 bis 90 Prozent der typischen Entwicklungsaufgaben erledigt ein Sprachmodell heute zuverlässig, wenn die Leitplanken stimmen. Die restlichen 10 bis 20 Prozent scheitern nicht zufällig. Sie scheitern dort, wo die Trainingsdaten dünn sind.

Das ist keine Vermutung, das lässt sich belegen. Fangen wir mit der ersten Hälfte an.

Was die 80 bis 90 Prozent stützt

SWE-bench Verified ist ein standardisierter Test: Man gibt dem Modell echte, dokumentierte Fehler aus bekannten Open-Source-Projekten und prüft, ob es sie selbstständig behebt. Die Spitzenmodelle schaffen dort im Juli 2026 zwischen 80 und 95 Prozent der Aufgaben. Das deckt sich mit dem, was ich in Projekten und Workshops sehe: Alltagsaufgaben in weit verbreiteten Technologien wie Spring Boot und Angular, also Formulare, Schnittstellen, Tests. Brot und Butter funktioniert.

Auch der Feldbefund passt. Eine Studie des Complexity Science Hub, erschienen in Science, hat über 30 Millionen öffentliche Code-Änderungen ausgewertet: Ende 2025 waren in den USA 29 Prozent des neuen Codes KI-generiert. Interessantes Detail am Rande: Der Produktivitätsgewinn kam fast vollständig von erfahrenen Entwicklern. Wer die Leitplanken kennt, profitiert. Wer sie nicht kennt, produziert nur schneller.

Wo es kippt

Jetzt die zweite Hälfte, und dafür braucht es nur einen zweiten Test. SWE-bench Pro stellt dieselbe Art von Aufgaben, aber aus Code, den die Modelle beim Training mit hoher Wahrscheinlichkeit nie gesehen haben, etwa aus geschützten Firmen-Codebasen. Dieselben Modelle, die eben noch 80 bis 95 Prozent erreichten, lösen hier nur noch rund 59 Prozent. Der Unterschied ist nicht die Aufgabe. Der Unterschied ist die Datenbasis.

Drei Fälle, in denen mir das immer wieder begegnet:

Erstens: Programmiersprachen mit wenig öffentlichem Code. Die Forschung nennt sie Low-Resource-Sprachen, darunter R, Racket, Julia und Lua. Ein Survey über 111 Studien dokumentiert den Leistungsabfall systematisch. Bemerkenswert: Julia und Lua gehen noch halbwegs, vermutlich weil sie verbreiteten Sprachen ähneln. Das Modell überträgt Muster aus der Nachbarschaft. Es hat keine Erfahrung mit der Sprache, es hat Ähnlichkeitsmuster.

Zweitens: Spezialsprachen. Fachleute sagen domänenspezifische Sprachen dazu: kleine Sprachen, die nur in einem Fachgebiet oder sogar nur in einer Firma verwendet werden. Regelwerke, Berechnungsvorschriften, hauseigene Formate. Alles, was nie öffentlich im Netz lag, ist für das Modell Neuland. Genau hier sitzt oft die Fachlichkeit eines Unternehmens.

Drittens: Altsysteme hinter Firmenmauern. COBOL ist das bittere Paradebeispiel. Der Code läuft seit Jahrzehnten, er ist geschäftskritisch, und er ist fast vollständig privat. Genau dort, wo die Hilfe am dringendsten gebraucht würde, fehlen die Trainingsfälle.

Der interessanteste Fall: die Grenze mitten im System

Ich war von 2010 bis 2019 Trainer für Hybris, das heute SAP Commerce Cloud heißt, eine große E-Commerce-Plattform für Konzerne. Deshalb kenne ich diesen Fall aus der Nähe, und er ist der lehrreichste, weil hier alle drei Muster in einer einzigen Plattform zusammenkommen.

Der Unterbau von SAP Commerce besteht aus Standardtechnologie (Java, Spring), von der es Millionen öffentliche Beispiele gibt. Diesen Teil erledigt ein Modell ordentlich. Alles Plattformspezifische ist dagegen datendünn: das eigene Datenmodell, die hauseigenen Spezialsprachen für Datenimport (ImpEx) und Abfragen (FlexibleSearch), die Konfiguration der Verwaltungsoberfläche. Der Plattform-Code selbst ist lizenzpflichtig, die echten Projekt-Codebasen liegen bei Agenturen und Konzernen. Die Grenze zwischen „funktioniert“ und „rät plausibel“ verläuft also mitten durch dasselbe System, oft mitten durch dieselbe Aufgabe. Und von außen sieht beides gleich überzeugend aus.

Wie die Entwickler-Community darauf reagiert, bestätigt die Diagnose. Es gibt inzwischen ein frei verfügbares Wissenspaket für SAP Commerce, eine sogenannte Skill, die Coding-Assistenten wie Claude Code genau das nachliefert, was den Modellen fehlt: Datenmodell, Architekturmuster, die Spezialsprachen. Und ein Anschluss-Werkzeug, einen sogenannten MCP-Server, mit dem die KI direkt im laufenden System nachschlagen kann, statt zu raten. Das eine liefert das fehlende Wissen, das andere ersetzt Raten durch Nachschauen. Niemand baut solche Werkzeuge für Spring Boot. Man baut sie dort, wo die Trainingsdaten es nicht hergeben.

Was daraus folgt

Zwei Dinge, und keines davon heißt „KI weglegen“.

Erstens: Halluzination ist keine Ausnahme, sie ist eine Betriebsbedingung. Bei dünner Datenlage rät das Modell plausibel statt korrekt, und es sagt einem nicht, wann es rät. Deshalb müssen Leitplanken scheitern können, nicht argumentieren. Ein Test ist rot oder grün. Eine Prüfschranke lässt durch oder nicht. In den 80 bis 90 Prozent halten diese Leitplanken das Tempo. In den restlichen 10 bis 20 Prozent fangen sie den Absturz, bevor er im gemeinsamen Code landet.

Zweitens: Wenn ein Modell an einer Aufgabe scheitert, ist das eine Aussage über das Modell und seine Datenbasis, nicht über die Aufgabe. Das Gedächtnis liegt in Dateien, nicht im Modell. Bei Nischen-Systemen heißt das konkret: der KI eigene Beispiele, eigene Konventionen und eigene Referenzen mitgeben, notfalls ein Werkzeug, das am lebenden System nachschaut. Die Hybris-Community macht gerade vor, wie das aussieht.

Die Faustregel bleibt also stehen, aber sie hat zwei Seiten. 80 bis 90 Prozent sind mit klaren Leitplanken kein Problem. Die restlichen 10 bis 20 Prozent sind vorhersagbar. Wer weiß, wo sie liegen, plant sie ein, statt sich überraschen zu lassen.

Quellen

Neue Beiträge als Mail

Wir senden keinen Spam! Erfahre mehr in unserer Datenschutzerklärung.

← Zurück zur Beitragsliste

Vorhandene Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert