Eine Meldung aus der Entwickler-Community sorgt derzeit für Diskussionen: Der Erfinder des Web-Frameworks Ruby on Rails lässt das Backend seines Produkts HEY von KI-Agenten in Rust schreiben. Bemerkenswert ist daran weniger die Sprachwahl selbst als die Begründung, die in der Fachdebatte mitschwingt – wenn Agenten den Großteil des Codes erzeugen, verliert die Frage nach der Programmiersprache an Gewicht. Entscheidend wird, was sich am Ergebnis überprüfen lässt.

Für Unternehmen, die ihre Entwicklungsprozesse schrittweise mit KI-Werkzeugen umstellen, ist das mehr als eine Randnotiz. Es berührt eine Entscheidung, die in Projekten traditionell früh und mit viel Gewicht getroffen wird: die Wahl des Technologie-Stacks.

Warum die Sprachwahl bisher so schwer wog

Die Entscheidung für eine Programmiersprache war immer auch eine Personalentscheidung. Wer PHP wählte, band sich an einen Arbeitsmarkt, an Bibliotheken, an Konventionen und an das, was ein Team in vertretbarer Zeit sicher beherrscht. Sprachen mit steiler Lernkurve – Rust gilt als klassisches Beispiel – galten damit in vielen Projekten als Risiko, selbst wenn sie technisch gut gepasst hätten.

Ein zweiter Faktor war die Schreibgeschwindigkeit. Frameworks wie Rails wurden populär, weil sie schnelles Vorankommen ermöglichten. Ausdrucksstarke, kompakte Sprachen hatten einen handfesten ökonomischen Vorteil, solange Menschen jede Zeile selbst tippten.

Genau diese beiden Argumente verlieren an Kraft, wenn ein Agent den Code erzeugt. Die Lernkurve einer Sprache ist für ein Modell kein Hindernis in dem Sinne, wie sie es für ein Team ist. Und die Zeit, die das Schreiben kostet, fällt anders ins Gewicht, wenn das Schreiben nicht mehr der Engpass ist.

Der Engpass wandert zur Kontrolle

Was bleibt, ist die Frage: Woher weiß ich, dass der erzeugte Code richtig ist? Diese Frage war immer schon da, sie stand nur hinter anderen. Wenn ein erfahrener Mensch Zeile für Zeile schreibt, entsteht Vertrauen nebenbei – durch das Nachdenken beim Schreiben, durch Code-Reviews, durch die Erfahrung des Teams. Fällt dieser Prozess weg oder wird er stark beschleunigt, muss das Vertrauen aus anderen Quellen kommen.

Damit rücken Eigenschaften in den Vordergrund, die vorher eher als Begleitthemen galten:

  • Strenge Typsysteme und Compiler, die eine ganze Klasse von Fehlern abfangen, bevor Code überhaupt läuft.
  • Automatisierte Tests, die nicht nur vorhanden sind, sondern das fachlich Wesentliche abdecken.
  • Deterministische Builds und Werkzeuge, die bei gleichem Input dasselbe Ergebnis liefern und dadurch nachvollziehbar bleiben.
  • Klare Architekturgrenzen, damit eine Änderung nur dort wirkt, wo sie wirken soll.

In dieser Lesart ist die Wahl einer Sprache mit striktem Compiler kein Luxus mehr, sondern ein Kontrollinstrument. Was die Maschine prüfen kann, muss kein Mensch mehr lesen.

Was Entscheiderinnen und Entscheider daraus mitnehmen können

Aus einem einzelnen prominenten Fall lässt sich keine allgemeine Regel ableiten. Ein etabliertes Produkt mit einem erfahrenen Team ist eine andere Ausgangslage als ein mittelständisches Projekt mit gewachsener Systemlandschaft. Trotzdem sind die dahinterliegenden Fragen übertragbar.

Wer KI-gestützte Entwicklung ernsthaft einführen will, sollte zuerst prüfen, wie gut die eigene Codebasis überhaupt überprüfbar ist. Ein Projekt ohne verlässliche Testabdeckung profitiert von Agenten deutlich weniger – dort erhöht schnell erzeugter Code vor allem das Risiko, weil niemand zeitnah feststellen kann, ob etwas kaputtgegangen ist. Die sinnvolle Reihenfolge lautet also: erst Prüfbarkeit herstellen, dann Erzeugungsgeschwindigkeit erhöhen.

Ebenso verschiebt sich das Anforderungsprofil im Team. Gefragt ist weniger die Fähigkeit, eine bestimmte Syntax flüssig zu schreiben, als die Fähigkeit, Anforderungen präzise zu formulieren, Architekturentscheidungen zu treffen und Ergebnisse kritisch zu beurteilen. Review-Kompetenz wird wichtiger als Tippgeschwindigkeit.

Wo Vorsicht angebracht bleibt

Die These, Sprachen verlören an Gewicht, hat Grenzen. Ein Technologie-Stack ist auch eine Festlegung auf ein Ökosystem: auf Bibliotheken, Hosting, Sicherheitsupdates, auf die Frage, wer das System in fünf Jahren betreut. Diese Aspekte verschwinden nicht, nur weil ein Agent den ersten Entwurf liefert. Wartbarkeit ist kein reines Schreibproblem.

Hinzu kommt: Auch der beste Compiler prüft nur technische Korrektheit, nicht fachliche Richtigkeit. Ob ein Rabattmodell, eine Berechtigungslogik oder ein Abrechnungslauf das tut, was das Geschäft braucht, entscheidet weiterhin die fachliche Spezifikation – und die Tests, die daraus abgeleitet werden.

Einordnung für Web- und Softwareprojekte

Für Projekte im Web- und TYPO3-Umfeld heißt das vor allem: Investitionen in Testabdeckung, saubere Schnittstellen und reproduzierbare Deployments zahlen sich doppelt aus, weil sie zugleich die Grundlage für sinnvollen KI-Einsatz bilden. Die Technologiewahl sollte künftig stärker danach beurteilt werden, wie gut sich Ergebnisse automatisiert absichern lassen, und nicht allein danach, wie vertraut eine Sprache im Team ist. Und unabhängig davon, wer oder was den Code schreibt, bleibt die Verantwortung für Architektur, Sicherheit und fachliche Richtigkeit bei den Menschen im Projekt.

Quellen