Ende September hat David Heinemeier Hansson auf der Rails World eine Keynote gehalten, über die die Ruby-Community noch lange sprechen wird. Ausgerechnet der Erfinder von Ruby on Rails verkündete, dass das Backend der nächsten Version seines E-Mail-Dienstes HEY nicht mehr auf Ruby basiert, sondern auf Rust. Geschrieben hat er es nicht selbst, sondern mithilfe von Coding-Agenten.

Rust sei zwar eine ästhetisch schreckliche Sprache, aber das sei egal: Er schaue sich den Code ohnehin nicht mehr an. Die schönste Programmiersprache der Welt sei nämlich nicht Ruby, sondern Englisch. Im Saal saßen rund tausend Entwicklerinnen und Entwickler, und es wurde still.

Meine erste Reaktion fiel anders aus: Er hat nicht unrecht. HEY ist keine Raketenwissenschaft, sondern eine Anwendung, deren Code technisch überschaubar ist, und genau solchen Code können Agenten heute ziemlich gut erzeugen. Warum ich der These im Kern zustimme, was sie über die Wahl von Programmiersprachen verrät und wo sie aufhört zu gelten, darum geht es in diesem ersten Teil einer zweiteiligen Serie über die Werkzeugwahl.

Ein Gütekriterium verliert seinen Adressaten

Wie weit dieser Schritt reicht, zeigt ein Blick in die Rails-Doktrin, die Hansson selbst verfasst hat. Ihr erster Grundsatz lautet „Optimize for programmer happiness“ und er beschreibt die ursprüngliche Ketzerei von Ruby: das Wohlbefinden derjenigen, die programmieren, auf ein Podest zu stellen. Ruby sollte sich gut anfühlen, Rails sollte Freude machen, und für sehr viele Entwicklerinnen und Entwickler hat genau das jahrelang funktioniert.

Dieses Kriterium ist keine Eigenheit der Ruby-Welt, es steckt in fast jeder Diskussion über Programmiersprachen. Wer zwischen zwei Sprachen wählt, fragt fast immer auch, wie es sich anfühlt, darin zu arbeiten: wie elegant die Syntax ist, wie viel unnötiges Drumherum nötig ist, wie schnell aus einer Idee lauffähiger Code wird, und so weiter. All das sind Eigenschaften des Schreibens – und sie richten sich an den Menschen, der schreibt.

Schreibt jedoch nicht mehr der Mensch, verliert das Kriterium seinen Adressaten. Einem Agenten ist es nämlich gleichgültig, ob eine Syntax elegant ist: Er empfindet weder Freude noch Verdruss. Deshalb sehe ich in Hanssons Entscheidung keinen Bruch mit seiner eigenen Doktrin, sondern ihre konsequente Fortsetzung. Wenn das Glück beim Schreiben keine Rolle mehr spielt, darf es auch die Wahl der Sprache nicht mehr bestimmen.

Was übrig bleibt, sind die Eigenschaften des Ergebnisses. Bei Rust sind das vor allem die Garantien des Typsystems, die Performance und der geringe Ressourcenverbrauch. Laut Hansson lässt sich die Zahl der Server für das HEY-Backend auf zehn reduzieren, und selbst das nur wegen der Ausfallsicherheit. Nach seiner Bauchgefühl-Rechnung würde sogar ein einzelner Raspberry Pi genügen. Ob das im Detail stimmt, sei dahingestellt. Die Richtung ist aber eindeutig – und sie hat herzlich wenig mit Ästhetik zu tun.

Für Agenten ist die Sprache fast egal

Naheliegend wäre nun der Schluss, Rust sei eben eine Sprache, die sich besonders gut von KI schreiben lässt. Ich halte diesen Schluss jedoch für falsch, und zwar aus eigener Erfahrung. Richtig ist, dass eine Sprache mit wenig Freiraum etwas hilft: Je weniger Wege es gibt, dasselbe auszudrücken, desto geringer ist die Varianz in den Trainingsdaten und desto gleichförmiger der erzeugte Code. Mit Go habe ich in dieser Hinsicht sehr gute Erfahrungen gemacht.

Überbewertet ist der Effekt trotzdem. Auch mit JavaScript und TypeScript, die deutlich mehr Freiheit lassen, entstehen KI-gestützt sehr gute Ergebnisse, sofern das Projekt mit passenden Leitplanken arbeitet, also mit einem Linter, mit einem Formatter und vor allem mit Tests. Schwierig wird es erst bei wirklich exotischen Sprachen, aber auch dort nicht wegen der Sprache an sich, sondern weil es schlicht zu wenig Trainingsmaterial gibt.

Daraus folgt eine kleine, aber wichtige Verschiebung. Rust liefert bei HEY nicht deshalb bessere Ergebnisse, weil ein Agent Rust besser schreibt als Ruby. Es liefert sie, weil Rust Stärken hat, bei denen Ruby im Hintertreffen ist, und weil diese Stärken plötzlich nichts mehr kosten. Früher zahlte jemand den Preis dafür, sich mit einer strengen und mitunter umständlichen Sprache auseinanderzusetzen. Diesen Preis zahlt nun jedoch der Agent und dem Agenten ist das egal.

Warum ich meine Meinung geändert habe

An dieser Stelle muss ich etwas Persönliches einschieben: Im Mai habe ich hier das Lesen von Code als unterschätzte Senior-Disziplin beschrieben, ausgehend von Joel Spolskys Warnung davor, Code lieber neu zu schreiben, statt ihn zu verstehen. Damals habe ich argumentiert, dass LLMs dieses Problem verschärfen würden. Heute sehe ich das in wesentlichen Teilen anders, und ich halte es für wichtig, das ehrlich anzusprechen.

Code wird nach wie vor deutlich öfter gelesen als geschrieben, etwa wenn ein Feature hinzukommt, wenn ein Fehler behoben werden muss oder jemand verstehen will, was ein Modul macht. Nur liest ihn eben zunehmend ein Agent und immer seltener ein Mensch. Dazu kommt ein schlichtes Mengenproblem. Ein Agent erzeugt Code schneller, als ein Team ihn prüfen kann, und mehr Reviewerinnen und Reviewer ändern daran nichts Wesentliches. Wer jede generierte Zeile von Hand durchsehen will, hat den Engpass nicht beseitigt, sondern nur verschoben und wird dennoch scheitern.

Hier setzt Spec-Driven Development (SDD) an. Gemeint ist ein Vorgehen, bei dem zuerst das gewünschte Verhalten beschrieben wird und ein Agent den passenden Code dazu erzeugt. Geprüft wird dann nicht mehr in erster Linie der Code, sondern ob das Verhalten stimmt. Ausführlicher beschreibe ich diesen Gedanken in „Code ist ein Implementierungsdetail“, der vierten Ausgabe von the native papers.

Der eigentliche Schlüssel ist für mich dabei allerdings nicht die Spezifikation, sondern es sind die Tests, die aus der Spezifikation folgen. Eine Spezifikation in Prosa ist so mehrdeutig wie jede Prosa, und ein Agent legt sie im Zweifel so aus, wie es ihm gerade passt. Ein Test dagegen lässt sich deterministisch ausführen und liefert bei jedem Lauf dieselbe Antwort: Entweder er ist grün oder eben nicht. Natürlich ist ein Test kein mathematischer Beweis und keine echte Garantie im eigentlichen Sinne, er prüft nur stichprobenartig, was er eben prüft. Aber er ist nichtsdestotrotz etwas, das sich objektiv überprüfen lässt, und das ist ungleich mehr als ein Agent, der einfach vor sich hin generiert.

Knapp 1500 Tests, anderthalb Stunden

Wie weit das trägt, habe ich vor einigen Wochen sehr eindrücklich erlebt. Es ging um die Implementierung eines Learning-Record-Stores für xAPI. Die Experience API, kurz xAPI, ist ein Standard für die Erfassung von Lernaktivitäten: Lernplattformen, Simulationen oder Apps melden darüber, wer was gelernt oder geübt hat. Ein Learning-Record-Store nimmt diese Meldungen über eine HTTP-Schnittstelle entgegen, speichert sie und stellt sie für Abfragen bereit.

Das Besondere an diesem Fall war nicht der Standard, sondern die offizielle Testsuite der ADL Initiative, die xAPI verantwortet. Sie prüft die verbindlichen Anforderungen der Spezifikation von außen gegen die HTTP-Schnittstelle, und für xAPI 2.0 umfasst sie 1435 Tests. Eine vollständigere Beschreibung des gewünschten Verhaltens ist kaum denkbar (außer noch mehr Tests zu haben).

Die Anweisung an den Agenten fiel entsprechend knapp aus: „Implementiere das in Go, und iteriere so lange, bis alle Tests grün sind.“

Der Agent brauchte rund 75 Minuten und drehte dabei etliche Schleifen. Runde um Runde schlugen Tests fehl, er besserte nach und nahm den nächsten Anlauf. Am Ende waren alle 1435 Tests grün, und die Implementierung funktioniert nun seit Wochen absolut tadellos.

Die Erkenntnis daraus hat mich mehr beschäftigt als das Ergebnis selbst. Der Erfolg lag weder am Modell noch an der Programmiersprache. Er lag daran, dass es eine gute, umfangreiche und vor allem vollständige Testsuite gab, an der sich jeder Zwischenstand messen ließ.

Ohne sie hätte derselbe Agent mit demselben Modell in derselben Sprache etwas abgeliefert, das plausibel aussieht, und niemand hätte gewusst, an wie vielen Stellen es falsch ist. Wenn Entwicklerinnen und Entwickler abschätzen wollen, wie viel sie einem Agenten überlassen können, lohnt deshalb zuerst ein Blick auf die Tests und erst danach auf die Sprache.

Ein Agent sagt nie, dass er etwas nicht kann

So überzeugend dieses Beispiel ist, so wichtig ist es, seine Grenzen nicht zu verschweigen. Es gibt Dinge, die sich nicht oder nur schlecht testen lassen, und zwar immer dann, wenn sie von Faktoren abhängen, die ein Test nicht oder nicht vollständig kontrollieren kann. Dazu gehört alles, was zwischen mehreren Maschinen passiert, alles, was an Hardware hängt, und auch alles, was vom Threading des Betriebssystems oder vom Verhalten des Netzwerkstacks abhängt. Ein Fehler, der nur bei einer bestimmten zeitlichen Abfolge auftritt, zeigt sich im Test vielleicht einmal in tausend Läufen, vielleicht auch nie – und trotzdem ist er da.

Schwierig wird es außerdem dort, wo es wenig Trainingsmaterial gibt, selbst wenn sich alles vollständig in Software abspielt. In solchen Bereichen findet ein Agent wenig, woran er sich orientieren kann, und zugleich gibt es wenig, was ihn korrigiert.

Das eigentliche Problem ist dabei nicht, dass der Agent scheitert, sondern wie er scheitert. Ein Agent wird nämlich nie sagen, dass er etwas nicht kann. Er meldet stattdessen zu früh, dass er fertig ist, und liefert eine Lösung, die überzeugend aussieht. Ob sie richtig ist, steht auf einem anderen Blatt, und gerade in den schwer testbaren Bereichen ist sie es meiner Erfahrung nach meistens eher nicht.

Damit wird deutlich, welche Rolle Tests in dieser Arbeitsweise tatsächlich spielen: Sie sind die Instanz, die dem Agenten widerspricht. Wo sie stark sind, wie bei der xAPI-Schnittstelle, lässt sich einem Agenten sehr viel überlassen. Wo sie schwach sind, widerspricht ihm niemand mehr, und genau dort wird es gefährlich.

Der Compiler als zweite Instanz

An dieser Stelle schließt sich der Kreis zu Rust und hier liegt für mich das stärkste Argument für Hanssons Entscheidung. Gerade bei Nebenläufigkeit, also dort, wo Tests tendenziell eher schwach sind, verlagert Rust einen Teil der Fehlersuche von der Laufzeit in den Compiler. Das Ownership-Modell sorgt nämlich dafür, dass mehrere Codestellen nicht gleichzeitig veränderlich auf denselben Speicher zugreifen können. Deshalb garantiert Rust, solange der Code ohne ausdrücklich als unsafe markierte Abschnitte auskommt, die Abwesenheit von Data-Races, also von nicht synchronisierten, gleichzeitigen Zugriffen mehrerer Threads, bei denen mindestens einer schreibt.

Hier ist Genauigkeit wichtig, weil dieser Punkt oft übertrieben wird. Rust verhindert nicht jede Art von Race-Condition, und auch Deadlocks schließt es nicht aus; die Dokumentation sagt ausdrücklich, dass das in einer Umgebung, deren Scheduler das Programm nicht kontrolliert, mathematisch unmöglich ist. Aber eine ganze Klasse besonders tückischer Fehler kommt dennoch gar nicht erst durch den Compiler, und das hilft enorm. Hinzu kommt ein Typsystem, das auch jenseits der Nebenläufigkeit vieles abfängt, was in Ruby erst zur Laufzeit auffällt.

Damit hat ein Agent, der Rust schreibt, neben den Tests eine zweite deterministische Instanz, die ihm widerspricht, und zwar genau dort, wo die erste schwach ist. Der Compiler lässt sich nicht „überreden“ und er meldet keinen Erfolg, nur weil der Code plausibel aussieht. Die Strenge, die Menschen an Rust oft als lästig empfinden, wird mit einem Agenten zum Vorteil. Und die Hässlichkeit, die Hansson der Sprache bescheinigt, kostet niemanden mehr etwas.

Wann braucht es noch einen Menschen?

Heißt das, dass Menschen keinen Code mehr lesen müssen? Nein, aber die Frage, wann sie es müssen, bekommt eine andere Antwort als früher. Entscheidend ist für mich dabei die Kritikalität der Software. Bei sicherheitskritischen Systemen, bei kritischer Infrastruktur und überall dort, wo ein Fehler Menschenleben gefährden oder generell großen Schaden jeglicher Art anrichten kann, möchte ich, dass ein Mensch auf den Code schaut, zusätzlich zu allen Tests und zu jedem Compiler.

Den zigmillionsten Webserver in Python muss dagegen niemand mehr Zeile für Zeile von Hand durchsehen, das bekommt ein Agent inzwischen ganz gut eigenständig hin. Und HEY steht auf dieser Skala eher auf der unkritischen Seite: Ein E-Mail-Dienst mag für seine Nutzerinnen und Nutzer wichtig sein – technisch ist er aber überschaubar, und deshalb trägt Hanssons These dort. Auf die Steuerung eines Kraftwerks würde ich sie nicht übertragen.

Bleibt die menschliche Seite, die die Stille im Saal erklärt. Viele Entwicklerinnen und Entwickler definieren sich über ihre Sprache, und für eine Community, deren Selbstverständnis seit gut zwanzig Jahren auf der Freude am Schreiben ruht, ist eine solche Keynote ein Einschnitt.

Ich sehe das relativ nüchtern. Natürlich gibt es Sprachen, die mir besser gefallen als andere (so mag ich zum Beispiel ganz subjektiv C# lieber als Visual Basic), und solche, die ich für gelungener halte (wie zum Beispiel, auch wieder subjektiv, Go deutlich mehr als Python). Kundinnen und Kunden ist es aber in fast allen Fällen gleichgültig, in welcher Sprache ihre Software geschrieben ist: Sie wollen letztlich einfach nur ihr (fachliches) Problem gelöst haben, wie die technische Lösung auch immer aussehen mag.

Dass Teams trotzdem so leidenschaftlich über Technologie streiten, halte ich ohnehin für eines der Grundprobleme vieler Projekte. Es finden zu viele technologische und zu wenige fachliche Diskussionen statt, ein Punkt, den ich in Software ist ein Werkzeug, kein Selbstzweck ausführlich beschrieben habe. Agenten verschärfen diesen Befund nur: Wenn das Schreiben kaum noch etwas kostet, bleibt vom Streit um die schönere Syntax nicht mehr viel übrig.

Was die Sprache nicht mehr entscheidet

Hanssons Keynote hat für Aufregung gesorgt, weil sie an ein Tabu der Branche rührt: dass die Sprache, an der so viel Identität hängt, austauschbar sein könnte. Ich halte die These für richtig, solange sie dort angewendet wird, wo sie hingehört. Wenn Agenten schreiben, entscheidet nicht mehr, welche Sprache Freude macht, sondern was sich deterministisch prüfen lässt, durch Tests und dort, wo Tests an Grenzen stoßen, durch den Compiler. Je kritischer die Software ist, desto mehr braucht es trotzdem (noch) den Menschen.

Eine Frage bleibt dabei allerdings offen, und sie geht in solchen Debatten gern unter. Ob ein Team Ruby oder Rust einsetzt, spielt mit Agenten eine geringere Rolle denn je. Ob ein Problem eine relationale Datenbank braucht, eine dokumentenbasierte oder eine Message-Queue, ist dagegen keine Geschmacksfrage, sondern eine Architekturentscheidung. Genau diese Entscheidung treffen viele Teams, bevor sie das Problem überhaupt kennen, und darum geht es im zweiten Teil dieser Serie.

(mro)