EuRuKo 2026

Einen Lösungsansatz liefert Matz mit Spinel, einem sogenannten AOT-Compiler. Vereinfacht gesagt wird Ruby-Code damit bereits vor der Ausführung in eine Form übersetzt, die schneller ausgeführt werden kann. Für komplette Rails-Anwendungen ist Spinel noch nicht ohne Weiteres geeignet. Ein erstes Experiment mit der Chat-Anwendung Campfire zeigte aber, wie viel Performance und Ressourcen sich so gewinnen lassen. Für unsere Projekte ist Spinel damit noch kein Thema, die Richtung ist aber vielversprechend.

Spannend war auch der Blick hinter die Kulissen: Spinel entsteht komplett per Vibe Coding. Matz gibt nur noch die Leitplanken vor und trifft größere Architekturentscheidungen. Den Code schreibt die KI, und das in beeindruckendem Tempo. Für unsere Kundenprojekte ist dieser Ansatz trotzdem keine Option. Bei einem experimentellen Projekt ist es vertretbar, dass der Entwickler den Code nicht bis ins Detail kennt. Anwendungen, die über Jahre zuverlässig und sicher laufen und von verschiedenen Entwicklern gewartet werden, stellen andere Anforderungen: Schwer nachvollziehbarer Code, unbemerkte Sicherheitslücken und wachsende technische Schulden wiegen hier deutlich schwerer. Wir setzen KI deshalb gezielt als Unterstützung ein. Die Verantwortung für den Code bleibt bei unseren Entwicklern.

Hana Harencarova, Senior Software Engineer bei GitHub, zeigte, wie dort täglich mehr als 1.000 Änderungen an einer großen Rails-Anwendung ausgeliefert werden. Dafür werden große Features in kleine Änderungen aufgeteilt und kontinuierlich veröffentlicht. Feature Flags sorgen dafür, dass neue Funktionen technisch ausgerollt werden können, für Nutzer aber verborgen bleiben, bis sie vollständig implementiert und getestet sind. Automatisierte Prüfungen vor jeder Auslieferung und ein geordnetes, schrittweises Zusammenführen der Änderungen sorgen dafür, dass trotz des hohen Tempos alles stabil läuft.

GitHub betreibt eine der größten Rails-Anwendungen der Welt und spielt damit in einer ganz eigenen Liga. Eine solche Größenordnung erreichen auch unsere großen Projekte nicht. Spannend ist der Ansatz für uns trotzdem, denn über langwierige Release-Prozesse mit vielen gebündelten Änderungen haben wir uns bereits Gedanken gemacht und intern diskutiert, wie sie sich verschlanken lassen. Der Vortrag lieferte dafür wertvolle Impulse: Kleinere, häufigere Releases machen jede einzelne Änderung überschaubarer und senken so das Risiko. Für unsere Kunden heißt das im besten Fall: Neue Funktionen und Fehlerbehebungen kommen schneller bei ihnen an, statt auf das nächste große Release warten zu müssen.

Mit RubyLLM 2.0 zeigte Carmine Paolino, Gründer und CEO von Chat with Work, wie sich KI-Funktionen direkt in Ruby- und Rails-Anwendungen integrieren lassen. Bereits auf der EuRuKo 2025 hatte er die Bibliothek vorgestellt. Eine gemeinsame Schnittstelle zu aktuell 17 KI-Anbietern ermöglicht es, Modelle oder Anbieter zu wechseln, auch zwischen Cloud und lokal betriebenen Modellen, ohne die gesamte Anwendungslogik neu schreiben zu müssen. Für einen ersten Chat genügt eine einzige Zeile Code.

Spannend war vor allem der Blick auf den produktiven Einsatz. Sobald KI-Funktionen dauerhaft in Anwendungen laufen, werden Kosten, Ausfallsicherheit und Nachvollziehbarkeit wichtig. RubyLLM 2.0 setzt dafür unter anderem auf Caching und Batch-Verarbeitung, alternative Modelle bei Ausfällen eines Anbieters, Quellenangaben zu den Antworten und eine bessere Nachverfolgung komplexer KI-Abläufe. Neue oder kleinere Anbieter lassen sich außerdem einfacher ergänzen. Für uns ist RubyLLM vor allem mit Blick auf künftige KI-Funktionen in Kundenprojekten interessant: Eine einheitliche Schnittstelle hält Anwendungen unabhängig von einzelnen Anbietern, und Funktionen wie Fallbacks und Quellenangaben machen KI-Features verlässlicher im täglichen Einsatz.