Ruby und KI: Warum die beliebte These nur teilweise stimmt

Seit einem Jahr dominiert in Ruby-Foren eine Behauptung: Ruby und Rails seien der KI-freundlichste Tech-Stack. Weniger Tokens, weniger Halluzinationen, sauberer generierter Code. Doch stimmt das wirklich? Eine aktuelle Studie hat 13 reale Ruby-Codebasen analysiert – und die Ergebnisse sind überraschend differenziert.

Warum Ruby tatsächlich KI-freundlich ist

Ein Teil der These hält einer kritischen Prüfung stand – und das aus gutem Grund. Ruby on Rails folgt dem Prinzip "Konvention vor Konfiguration". Das bedeutet: Ein Modell, das bereits tausende Rails-Anwendungen analysiert hat, kennt die typischen Strukturen von Modellen, Jobs oder Controllern. Es muss nicht raten, wo welche Komponente hingehört oder wie Methoden wie has_many zu interpretieren sind. Diese Konventionen sind nicht nur für menschliche Entwickler hilfreich – sie geben auch KI-Modellen klare Orientierungspunkte.

Daher überrascht es nicht, dass KI-Modelle in Rails-Projekten häufig präzisere Codevorschläge liefern. Aufgaben wie das Erstellen eines Service-Objekts oder das Hinzufügen eines Scopes gelingen oft mit weniger Fehlern und in kürzerer Zeit. Die Studie bestätigt: Für solche lokalen Aufgaben ist Ruby tatsächlich ein idealer Kandidat für KI-Unterstützung. Doch hier endet auch schon der Konsens.

Navigieren in komplexen Ruby-Projekten: Ein fundamentales Problem

Die eigentliche Herausforderung liegt woanders – und genau hier scheitern viele KI-Modelle. Die Studie untersuchte nicht, ob KI Code generieren kann, sondern ob sie komplexe Abhängigkeiten in großen Ruby-Projekten korrekt identifizieren kann. Das ist entscheidend, denn falsche Annahmen über Abhängigkeiten führen zu fehlerhaften Änderungen und im schlimmsten Fall zu gebrochenen Deployments.

Während das Lesen einer einzelnen Datei noch relativ einfach ist, erfordert das Navigieren durch ein großes Projekt strukturelles Verständnis: Welche Dateien greifen auf eine bestimmte Klasse zu? Wo liegt der Blast Radius einer Änderung? Diese Informationen sind selten in einem einzelnen Dokument enthalten – sie verteilen sich über das gesamte Projekt. Die Studie testete zwei Ansätze:

• Ein reines KI-Modell, das Dateien durchsucht und Abhängigkeiten inferiert.
• Dasselbe Modell, unterstützt durch eine strukturelle Karte des Projekts, die Abhängigkeiten explizit auflistet.

Die Ergebnisse sind eindeutig: In kleineren, gut strukturierten Projekten wie llm.rb oder raix reicht das reine Modell oft aus. Doch in größeren Codebasen wie Chatwoot, Mastodon oder GitLab stiegen die Fehlerquoten massiv an – von 29 % auf 97 % bei Chatwoot, von 28 % auf 83 % bei Mastodon. Die strukturelle Karte verbesserte die Genauigkeit deutlich, doch selbst dann blieben einige Projekte eine Herausforderung.

Warum Größe und Struktur alles entscheiden

Die Analyse zeigt zwei klare Gruppen von Ruby-Projekten:

• Kleinere, gut strukturierte Projekte: Hier arbeiten Modelle mit hoher Genauigkeit. Beispiele sind llm.rb, raix oder Solidus. Diese Projekte folgen klaren Namenskonventionen, und Abhängigkeiten sind leicht zu verfolgen. Selbst ohne strukturelle Hilfsmittel liefern die Modelle akzeptable Ergebnisse.

• Große, komplexe Projekte: Hier versagen reine KI-Modelle oft. Beispiele sind Chatwoot, Mastodon oder Forem. In solchen Projekten verteilen sich Abhängigkeiten über mehrere Dateien, nutzen Polymorphie, Concerns oder Konfigurationsregistries – und entziehen sich damit der einfachen Suche. Selbst mit struktureller Unterstützung bleiben Fehlerquoten hoch.

Ein besonders aufschlussreiches Beispiel ist langchainrb. Dieses Projekt wurde zwar von Modellen gut erkannt, aber die trainierten Daten basierten auf einer älteren Version. Das Modell generierte Abhängigkeiten basierend auf veralteten Strukturen – ein Risiko, das insbesondere bei häufigen Updates oder weniger bekannten Projekten besteht.

Überraschende Erkenntnisse: Modellgröße und Prominenz

Die Studie brachte zwei unerwartete Ergebnisse zutage:

• Kleinere Modelle performen überraschend gut: Die besten Ergebnisse lieferten nicht die größten Frontier-Modelle, sondern das kleinste Open-Source-Modell im Test – Devstral. Es erreichte eine Verbesserung von 0,24 im Vergleich zum reinen Modell, nur knapp hinter dem Top-Modell Opus (0,26). Die Erklärung: Strukturelle Karten kompensieren fehlendes Domänenwissen. Je weniger ein Modell aus dem Kontext lernt, desto mehr profitiert es von expliziten Strukturdaten.

• Prominenz ist kein Garant für korrekte Ergebnisse: Projekte wie Forem (Betreiber von dev.to) oder Rails selbst sind in den Trainingsdaten von Modellen prominent vertreten. Dennoch schnitten sie in der Studie schlecht ab. Das Problem: Modelle neigen dazu, bekannte Projekte auswendig zu lernen – und scheitern dann daran, die tatsächlichen, aktuellen Strukturen zu erfassen. Bei langchainrb führte das sogar zu falschen Abhängigkeiten, weil die trainierte Version veraltet war.

Die Illusion der Kontrolle: Warum Sie sich nicht in Sicherheit wiegen sollten

Viele Entwickler lesen solche Studien und denken: „Mein Projekt ist gut strukturiert. Ich gehöre bestimmt zur unteren Gruppe.“ Doch die Grenze zwischen „klein und lesbar“ und „zu komplex für KI“ ist fließend. Ein Projekt, das heute noch problemlos von KI-Tools navigiert werden kann, wird morgen durch Wachstum oder Refactoring zur Herausforderung.

Die Studie zeigt: Ruby und Rails sind zwar hervorragend für die Codegenerierung geeignet, doch beim Navigieren in komplexen Abhängigkeiten stoßen selbst moderne KI-Modelle an Grenzen. Die Lösung liegt nicht darin, auf KI zu verzichten – sondern darin, sie gezielt einzusetzen und durch Tools wie strukturelle Karten oder Dependency-Tracking zu ergänzen. Die Zukunft gehört nicht den Modellen, die alles können, sondern denen, die wissen, wo ihre Grenzen liegen.

Künftige KI-Tools müssen lernen, strukturelle Kontexte besser zu erfassen. Bis dahin bleibt die Empfehlung: Nutzen Sie KI für lokale Aufgaben, aber prüfen Sie komplexe Änderungen manuell – bevor sie zu kostspieligen Fehlern werden.