Eine Frage, die ich inzwischen fast wöchentlich höre
Vor ein paar Wochen saß ich mit dem CTO eines Softwarehauses zusammen. Sein Team hatte gerade beschlossen, ein neues internes Produkt weitgehend mit Coding Agents zu bauen, und er hatte eine einzige Frage mitgebracht: „In welcher Sprache sollen wir das machen? Wir haben gehört, KI kann Python am besten."
Die Frage ist gut. Die Antwort, die er erwartet hat, war falsch.
Denn diese Frage lässt sich auf zwei völlig verschiedene Arten beantworten, und die meisten Rankings im Netz beantworten die unwichtigere davon.
Die erste Achse: Was weiß das Modell?
Das ist die Achse, die alle messen. Wie viel Code einer Sprache steckte in den Trainingsdaten? Je mehr, desto besser die Vorhersage.
Auf dieser Achse gewinnt Python haushoch, und zwar deutlicher, als die meisten ahnen. Eine Untersuchung mit dem Titel LLMs Love Python hat acht große Sprachmodelle systematisch daraufhin geprüft, welche Sprache sie unaufgefordert wählen. Das Ergebnis: In 90 bis 97 Prozent der Benchmark-Aufgaben kam Python heraus. Selbst bei Aufgaben, für die Python fachlich ungeeignet war, blieb es in 58 Prozent der Fälle die Wahl des Modells. Rust, obwohl in mehreren Testfällen die technisch richtige Antwort, wurde kein einziges Mal verwendet.
Der interessanteste Befund derselben Untersuchung ist ein anderer. Fragt man die Modelle vorher, welche Sprache sie empfehlen würden, nennen sie durchaus differenziert Rust, Go oder C++. Und dann schreiben sie trotzdem Python. In 83 Prozent der Fälle widerspricht das Modell seiner eigenen Empfehlung, sobald es Code produziert.
Das ist ein Modell, das über sich selbst falsch Auskunft gibt. Halten Sie das kurz fest, wir kommen gleich darauf zurück.
Warum diese Achse in der Praxis wenig bringt
Trainingsdatenmenge sagt Ihnen, wie gut der erste Wurf wird. Sie sagt Ihnen nichts darüber, wie gut das Endergebnis wird.
Und der erste Wurf ist bei agentischer Entwicklung nicht das Produkt. Ein Coding Agent schreibt keinen Code wie ein Autor einen Absatz. Er schreibt einen Vorschlag, führt ihn aus, sieht ein Ergebnis, korrigiert. Nach Zahlen aus Anthropics eigenem Benchmarking laufen pro Aufgabe im Schnitt drei bis fünf solcher Runden, jede zwischen 30 und 90 Sekunden.
Das heißt: Was Sie am Ende bekommen, ist nicht das, was das Modell zuerst geraten hat. Es ist das, was nach mehreren Korrekturrunden übrig geblieben ist. Die Qualität entsteht in der Schleife, nicht im Wurf.
Damit verschiebt sich die entscheidende Frage. Sie lautet nicht mehr „Wie gut rät das Modell?". Sie lautet: Woran merkt der Agent, dass er falsch geraten hat?
Der Befund, der alles ändert
An dieser Stelle gibt es eine Untersuchung aus dem Juni 2026 mit einem sehr unbequemen Titel: The Self-Correction Illusion. LLMs Correct Others but Not Themselves.
Der Befund in einem Satz: Ein Sprachmodell findet Fehler in fremdem Code zuverlässig. Im eigenen Code findet es sie kaum.
Das klingt nach einer Kuriosität und ist in Wahrheit die zentrale Konstruktionsvorgabe für jeden ernsthaften KI-Entwicklungsprozess. Wer darauf baut, dass ein Agent seine Arbeit selbst prüft und dann verbessert, baut auf einem Mechanismus, der nachweislich nicht funktioniert. Das Modell, das eben noch begeistert war, ist derselbe Prüfer, der jetzt urteilen soll. Es sieht denselben blinden Fleck aus derselben Richtung.
Was stattdessen funktioniert, ist externe Bestätigung. Eine Forschungsübersicht dazu bringt es auf eine Formel, die ich seither in fast jedem Workshop verwende: Der Wechsel von "hält das Modell das für richtig" zu "bestätigt die Welt, dass es richtig ist".
Der Agent braucht etwas außerhalb seiner selbst, das ihm widerspricht.
Die Sprache als Widerspruchsapparat
Damit hat die Programmiersprache in einem agentischen Setup eine andere Rolle als in klassischer Entwicklung.
Für einen menschlichen Entwickler ist eine Sprache ein Ausdrucksmittel. Sie entscheidet, wie elegant sich ein Gedanke formulieren lässt, wie gut sich ein Team darin verständigt, wie viel Zeremonie nötig ist.
Für einen Agenten ist eine Sprache in erster Linie ein Orakel. Ihre wichtigste Eigenschaft ist nicht Ausdrucksstärke. Es ist die Frage, wie gut, wie schnell und wie präzise sie dem Agenten sagt: Das war falsch.
Ein Compiler ist ein Orakel. Ein Typsystem ist ein Orakel. Eine Testsuite ist ein Orakel. Ein Linter mit maschinenlesbarer Ausgabe ist ein schwaches, aber echtes Orakel. Eine Laufzeitausnahme drei Wochen später in der Produktion ist ein Orakel, das zu spät kommt, um noch etwas zu retten.
Die schärfste Formulierung dieses Gedankens stammt aus einer neuen Kategorie von Programmiersprachen, die gezielt für maschinelle Autoren entworfen werden. Auf agentlanguages.dev, einem Katalog solcher Projekte, steht ein Satz, der die ganze Debatte zusammenfasst:
„The model doesn't need to be right. It needs to be checkable."
Das Modell muss nicht recht haben. Es muss überprüfbar sein.
Was das für die Sprachwahl bedeutet
Sobald Sie die Frage so stellen, verschiebt sich die Rangfolge erheblich.
Python, unangefochtener Sieger auf Achse eins, fällt auf Achse zwei fast ans Ende des Feldes. Es gibt keinen Compiler, der einen falschen Vorschlag abfängt, bevor er läuft. Fehler zeigen sich zur Laufzeit, oft an ganz anderer Stelle, häufig gar nicht. Ein Agent, der Python schreibt, bekommt sehr viel Zustimmung und sehr wenig Widerspruch.
Go, in den Rankings der Trainingsdaten allenfalls Mittelfeld, rückt weit nach vorn. Nicht wegen der Sprache selbst, sondern wegen der Werkzeuge drumherum: eine sehr schnelle Kompilierung, strukturierte und maschinenlesbar auswertbare Ausgaben von go vet und go test, klare Exit-Codes, und ein einziger etablierter Weg, Dinge zu tun, statt zwanzig konkurrierender Konventionen.
Rust, Scala und Haskell bieten den härtesten Filter überhaupt. Was dort kompiliert, ist mit hoher Wahrscheinlichkeit auch in weiten Teilen richtig. Der Preis ist eine langsamere Rückmeldung, und ein Agent kann sich in einem strengen Typsystem auch festfahren.
Und dann gibt es einen Sonderfall, der die ganze Logik schön beleuchtet. Clojure hat die kürzeste Rückmeldeschleife im gesamten Feld, weil der REPL eine einzelne Funktion in Millisekunden auswertet, ohne Build und ohne Neustart. Gleichzeitig hat Clojure die schwächste Vorabprüfung, weil es dynamisch typisiert ist und schlicht kein Compiler existiert, der den Agenten stoppt. Schnellstes Orakel, dünnstes Orakel, in derselben Sprache.
Diesen Zielkonflikt zwischen Geschwindigkeit und Abdeckung schauen wir uns im zweiten Teil dieser Serie genauer an, samt der fünf Kriterien, an denen sich das tatsächlich messen lässt.
Die Konsequenz für Ihr Team
Wenn Sie heute eine Entscheidung treffen müssen, ist die praktisch brauchbarste Regel diese:
Wählen Sie die Sprache, in der Ihr Agent am schnellsten und am unmissverständlichsten Widerspruch bekommt. Nicht die, in der er am flüssigsten formuliert.
Das ist in den meisten Fällen eine statisch typisierte Sprache mit schneller Kompilierung und ordentlicher Werkzeugkette. Für Teams, die ohnehin im TypeScript-Umfeld arbeiten, heißt das konkret: strikter Modus an, und die Notausgänge zumachen. Ein Agent, der any schreiben darf, schaltet Ihr Orakel selbst ab, und Sie merken es erst im Review.
Aber, und das ist der Punkt, auf den diese Serie hinausläuft: Die Sprache liefert Ihnen bestenfalls die Hälfte des Orakels. Ein Typsystem prüft die Form. Es prüft nicht die Bedeutung. Ein Agent, der die Syntax beherrscht, macht ohnehin kaum noch Typfehler. Er macht Bedeutungsfehler, und dagegen ist kein Compiler der Welt eine Verteidigung.
Die andere Hälfte müssen Sie schreiben.
Dieser Beitrag ist Teil einer dreiteiligen Serie. Teil 2 behandelt die fünf Kriterien, an denen sich ein KI-taugliches Entwicklungssetup messen lässt. Teil 3 zeigt, wie Teams die fehlende Hälfte des Orakels selbst bauen.
Wie dieser Verifikationsschritt in einem realen Team-Workflow aussieht, ist der Kern von Spec-Driven Development, als Online-Kurs oder als Workshop für Ihr Team. Einen Überblick über alles Weitere finden Sie bei meinen Angeboten.