Kurze Wiederholung
Im ersten Teil dieser Serie ging es darum, dass die übliche Frage nach der besten Programmiersprache für KI-Coding an der Sache vorbeigeht. Ein Coding Agent liefert nicht das ab, was er zuerst geraten hat, sondern das, was nach drei bis fünf Korrekturrunden übrig bleibt. Und weil Sprachmodelle Fehler im eigenen Code nachweislich schlecht finden, muss der Widerspruch von außen kommen.
Die Sprache und ihre Werkzeuge sind dieser Widerspruch. Sie sind das Orakel.
Bleibt die Frage, wie man ein gutes Orakel von einem schlechten unterscheidet. „Hat einen Compiler" ist dafür zu grob. In der Praxis zerfällt die Sache in fünf Kriterien, und die werden fast immer durcheinandergeworfen. Genau deshalb reden die Go-Fraktion und die Rust-Fraktion in diesem Streit konsequent aneinander vorbei.
Kriterium 1: Latenz
Wie lange dauert es, bis der Widerspruch beim Agenten ankommt?
Das ist das Kriterium, das am direktesten auf die Wanduhr durchschlägt. Bei drei bis fünf Runden pro Aufgabe multipliziert sich jede Sekunde Wartezeit. Ein Setup, in dem ein Durchlauf 20 Sekunden braucht, und eines mit vier Minuten trennen Welten, obwohl beide „einen Compiler haben".
Hier gewinnt der REPL vor allem anderen, dann Go, dann TypeScript im Watch-Modus, dann mit Abstand Rust und alles, was einen vollständigen Build braucht.
Kriterium 2: Abdeckung
Welcher Anteil der möglichen Fehler wird gefangen, bevor der Code läuft?
Das ist die Achse, auf der die streng typisierten Sprachen gewinnen. Ein ausdrucksstarkes Typsystem schließt ganze Fehlerklassen aus, bevor eine einzige Zeile ausgeführt wird. Bei Python liegt diese Abdeckung nahe null.
Kriterium 1 und Kriterium 2 arbeiten gegeneinander, und das ist der eigentliche Kern der ganzen Debatte. Rust maximiert die Abdeckung und bezahlt mit Latenz: wenige Runden, jede teuer. Go nimmt mittlere Abdeckung bei sehr niedriger Latenz: mehr Runden, jede billig. Beide landen bei ähnlicher Gesamtzeit, mit unterschiedlichem Risikoprofil. Go lässt mehr Fehlerklassen bis in die Laufzeit durch, Rust hält den Agenten länger in Compiler-Schleifen fest, in denen er sich bei Lifetimes durchaus verheddern kann.
Kriterium 3: Lokalisierung
Zeigt die Fehlermeldung auf die Ursache oder auf ein Symptom drei Schichten weiter?
Das ist das am meisten unterschätzte Kriterium. Eine präzise Meldung führt zu einer gezielten Korrektur. Eine unpräzise Meldung führt dazu, dass der Agent an der falschen Stelle etwas ändert, das Symptom verschwindet und der eigentliche Fehler bleibt.
Rusts Compiler-Meldungen sind hier hervorragend, sie sagen oft direkt, was zu tun ist. C++-Template-Fehler sind das andere Extrem. JVM-Stacktraces, die durch mehrere Ebenen von Makros und verzögerter Auswertung laufen, sind ebenfalls schwach, und das trifft unter anderem Clojure.
Kriterium 4: Maschinenlesbarkeit
Kann der Agent die Rückmeldung verlässlich auswerten, oder muss er Text raten?
Das ist Gos stiller Vorteil und ein Punkt, den fast niemand nennt. Stabile Exit-Codes, strukturierte Ausgaben, ein einheitliches Format. Der Agent muss keine Prosa parsen, um zu wissen, was schiefging.
Bei fragmentierten Werkzeugketten, in denen jedes Tool ein anderes Ausgabeformat hat, geht dieser Vorteil verloren. Nicht weil die Information fehlt, sondern weil der Agent sie unzuverlässig extrahiert.
Kriterium 5: Was bedeutet eigentlich Grün?
Das wichtigste Kriterium, und das am seltensten gestellte.
Wenn Ihr Setup meldet „alles in Ordnung", welche Aussage steckt tatsächlich dahinter?
Bei Haskell bedeutet ein erfolgreicher Compilerlauf sehr viel. Bei Python bedeutet „Tests sind grün" oft nur, dass die Pfade abgedeckt sind, an die jemand gedacht hat. Und bei einem Agenten, der seine Tests selbst geschrieben hat, bedeutet es manchmal überhaupt nichts, weil er die Tests passend zum Code formuliert hat und nicht zur Anforderung.
Ein grünes Signal, dem man nicht trauen kann, ist gefährlicher als gar kein Signal. Es beendet die Prüfung.
Der Punkt, den die Sprachdebatte übersieht
Jetzt kommt die Beobachtung, die in der gesamten Diskussion um Go, Rust und TypeScript praktisch nicht vorkommt, obwohl sie die Sprachwahl relativiert.
Typsysteme fangen Formfehler. Sie fangen keine Bedeutungsfehler.
Ein Agent, der die Syntax einer Sprache beherrscht, und das tun heutige Modelle in allen gängigen Sprachen, macht kaum noch Typfehler. Er macht andere Fehler: Er dreht eine Bedingung um. Er vergisst den Randfall bei einer leeren Liste. Er zählt eins zu viel. Er ruft die richtigen Funktionen in der falschen Reihenfolge auf. Er implementiert sauber, korrekt typisiert und vollständig kompilierbar etwas, das die Anforderung verfehlt.
Ein Typsystem sagt Ihnen, dass dort eine Ganzzahl steht. Es sagt Ihnen nicht, dass es die falsche Ganzzahl ist.
Damit ist die unangenehme Wahrheit: Die Sprache deckt genau die Fehlerklasse ab, die ohnehin kaum noch auftritt, und lässt genau die durch, die tatsächlich weh tut. Ein Compiler ist ein gutes Orakel für Anfängerfehler und ein schwaches für die Fehler eines kompetenten, aber ahnungslosen Mitarbeiters. Und genau das ist ein Coding Agent.
Was Bedeutungsfehler tatsächlich fängt
Es gibt Werkzeuge, die auf dieser Ebene arbeiten, und sie sind älter als der ganze KI-Zyklus.
Eigenschaftsbasiertes Testen prüft nicht einzelne Beispiele, sondern Aussagen, die immer gelten müssen. Nicht „Sortieren von [3,1,2] ergibt [1,2,3]", sondern „das Ergebnis ist immer aufsteigend und enthält immer dieselben Elemente wie die Eingabe". Das System erzeugt dann hunderte Eingaben selbst und sucht gezielt nach dem Gegenbeispiel. Genau die Randfälle, die ein Agent übersieht, findet dieser Ansatz systematisch.
Verträge an den Systemgrenzen prüfen zur Laufzeit, ob Daten die Form haben, die die Anforderung verlangt, und zwar unabhängig davon, was der Code behauptet.
Verifizierbare Abnahmekriterien, die vor dem Code formuliert wurden. Das ist das mit Abstand stärkste Orakel für Bedeutungsfehler, weil es die einzige Instanz ist, die etwas über die Absicht weiß. Ein Compiler kennt die Absicht nicht. Ein Test, den der Agent nach dem Code geschrieben hat, kennt sie auch nicht.
Hier liegt übrigens der Grund, warum Clojure trotz fehlendem Compiler in dieser Betrachtung nicht abstürzt. Der Werkzeugkasten aus Spec, Malli und generativem Testen erzeugt aus einer einmal geschriebenen Vertragsdefinition gleichzeitig Prüfung, Instrumentierung und automatische Testdaten. Das ist auf der Bedeutungsebene stärker als jedes Typsystem. Man muss es nur bauen, weil die Sprache es nicht mitliefert.
Die Bilanz
Stellt man alle fünf Kriterien nebeneinander, ergibt sich ein anderes Bild als in den üblichen Ranglisten.
| Latenz | Abdeckung | Lokalisierung | Maschinenlesbar | Grün heißt was? | |
|---|---|---|---|---|---|
| Go | sehr gut | mittel | gut | sehr gut | mittel |
| Rust | schwach | sehr gut | sehr gut | gut | sehr gut |
| TypeScript (strict) | gut | gut | mittel | mittel | mittel |
| Clojure | herausragend | schwach | schwach | gut | schwach ab Werk |
| Python | mittel | sehr schwach | mittel | schwach | schwach |
Go ist der beste Kompromiss, wenn niemand Zeit hat, etwas aufzubauen. Rust ist die Wahl, wenn Korrektheit teurer ist als Wartezeit. TypeScript im strikten Modus ist solide, sofern die Notausgänge zu sind.
Und in allen fünf Spalten steckt dieselbe Grenze: Keine dieser Sprachen weiß, was Sie eigentlich wollten.
Die eigentliche Arbeit
Die Sprachwahl bringt Sie ungefähr bis zur Hälfte. Sie bekommen ein Orakel geliefert, das Formfehler zuverlässig abfängt und bei Bedeutungsfehlern schweigt.
Die andere Hälfte ist kein Werkzeugkauf. Sie ist eine Arbeitsweise: die Absicht so aufzuschreiben, dass sie prüfbar wird, bevor der Agent loslegt. Verifikationsschritte zu formulieren, die tatsächlich falsifizierbar sind statt „sieht gut aus". Und diese Prüfung an einer Stelle zu verankern, an der der Agent sie nicht umgehen kann.
Wie das konkret aussieht, ist Thema von Teil 3.
Teil 3 dieser Serie zeigt die vier Bausteine, mit denen Teams die fehlende Hälfte des Orakels selbst bauen.
Der vollständige Team-Workflow dazu, von der prüfbaren Spezifikation bis zum Review, ist der Inhalt von Spec-Driven Development. Wenn Sie die Sprachfrage zuerst grundsätzlich klären wollen, hilft Ihnen vielleicht mein Beitrag zu Vibecoding im Unternehmen.