Warum Rust und LLMs besser zusammenpassen als man denkt

Ein aktueller Forbes-Artikel trägt den Titel “Rust: The Unlikely Engine of the Vibe Coding Era” und trifft damit etwas, das wir in einem unserer jüngsten Pilotprojekte direkt erlebt haben.

Die Kernthese: Rust ist nicht trotz seiner Strenge eine gute Sprache für KI-gestützte Entwicklung, sondern wegen ihr.

Was der Forbes-Artikel argumentiert

Die Beobachtung des Artikels ist simpel, aber treffend: Wenn ein LLM Code schreibt, braucht man kein Sicherheitsnetz aus Disziplin und Erfahrung mehr, sondern ein formales, maschinelles Sicherheitsnetz. Und genau das liefert Rust.

Drei Punkte stachen in dem Artikel für uns besonders heraus:

Bei der Generierung von Rust-Code erweist sich der Compiler als unwahrscheinlicher Verbündeter. Rusts Typsystem und Ownership-Modell fangen eine ganze Klasse von Fehlern ab, bevor Code überhaupt läuft. Das ist bei manuell geschriebenem Code schon wertvoll, bei KI-generiertem Code ist es entscheidend, weil LLMs keine Intuition für Laufzeitverhalten haben. Sie optimieren für plausiblen Code, nicht für korrekten.

Weiterhin scheinen typensichere Sprachen den Wettbewerb zu gewinnen. TypeScript statt JavaScript, Rust statt C/C++. Der Trend geht eindeutig in Richtung Sprachen, die Fehler zur Kompilierzeit statt zur Laufzeit aufdecken. Wenn Entwickler nicht mehr jede Zeile selbst schreiben, wird die Sprache zum Korrektiv. Wer auf dynamische Typisierung setzt, verlagert Fehler nur in die Produktion.

Und zu guter Letzt: Die Sprachbarriere verschwindet. Wer früher Rust gescheut hat, weil der Einstieg zu steil war, hat mit einem LLM als Partner einen anderen Ausgangspunkt. Die lästigen Teile — Lifetime-Annotationen, Borrow-Checker-Fehler, komplexe Trait-Bounds — werden nicht ignoriert, aber sie sind nicht mehr der Engpass. Der Mensch definiert das Was, das Modell findet heraus, wie der Compiler zufriedengestellt wird.

Was wir selbst erlebt haben

Diese Einschätzung deckt sich nahtlos mit unseren Erfahrungen aus dem MAKI-Projekt: einem vollständigen Digital Asset Manager, dessen erste produktive Version in unter 3 Wochen mit Claude Code als Entwicklungspartner entstanden ist.

Der Satz, den wir in unserem Erfahrungsbericht geschrieben haben, klingt wie ein Direktzitat aus dem Forbes-Artikel:

„Rust als Sprache passt hervorragend. Der Compiler fängt viele Fehler ab, die bei dynamischen Sprachen durchrutschen würden. Wenn Claude einen Typ falsch verwendet oder einen Ownership-Fehler macht, sagt cargo build sofort Bescheid.”

Ein konkretes Beispiel: Beim Einbau der KI-Autotagging-Funktion in die Web-Oberfläche gab es einen Compilerfehler, weil der Axum-Router seinen Typ ändert, wenn man with_state() aufruft. Claude hat drei Anläufe gebraucht, um das richtig zu lösen. Aber: Alle drei Anläufe sind am Compiler gescheitert, nicht erst in der Laufzeit. Kein kaputter Deploy, kein stiller Fehler. Der Compiler hat getan, wofür er gebaut wurde.

Das ist das eigentliche Argument für Rust im KI-Zeitalter: nicht Geschwindigkeit, nicht Memory Safety in Theorie, sondern der Feedback-Zyklus. LLMs iterieren schnell. Rust-Compiler schließen den Loop sofort. Das passt gut zusammen.

Die andere Seite

Der Forbes-Artikel bleibt nicht unkritisch, und das zu Recht. LLMs haben bei Rust-Code noch deutliche Schwächen: Je weiter der Code von gängigen Patterns abweicht, desto schlechter wird die Ausgabe und Rust hat schlicht weniger Trainingsbeispiele als Python oder TypeScript. Komplexe Lifetime-Szenarien, fortgeschrittene Trait-Kombinationen oder ungewöhnliche Async-Patterns fordern den Menschen noch häufiger heraus als bei anderen Sprachen.

Das haben wir ebenfalls erlebt: Für die grundlegende Architektur, für Datenbankdesign und für systemübergreifende Entscheidungen war menschliche Führung nötig. Claude hat die Richtung nicht selbst gefunden. Er hat sie zuverlässig ausgeführt, sobald sie klar war.

Fazit

Der Forbes-Artikel und unsere eigenen Erfahrungen zeigen: Für LLMs sind vorgegebene Strukturen und gut etablierte Patterns sehr nützlich, um funktionsfähigen Code zu schreiben, wie wir bereits in unserem Artikel zu Rails und Claude festgestellt haben. Ein strenger Abnahmeprüfer, wie der Rust-Compiler, treibt dies noch weiter. Wer ein LLM als Entwicklungspartner nutzt, braucht kein nachsichtiges Ökosystem. Er braucht ein ehrliches. Dies macht Rust zu einer naheliegenden Option für viele Projekte.

Weiterlesen

Wer mehr über den konkreten Projektverlauf und die Arbeitsweise mit Claude Code erfahren möchte:

• In 17 Tagen zum fertigen Digital Asset Manager: Ein Erfahrungsbericht mit Claude Code — wie das DAM-Projekt entstanden ist und was dabei gelernt wurde.
• Whitepaper: Agentic Coding — was Agentic Coding bedeutet und wie es sich vom klassischen Prompting unterscheidet.

Sie möchten KI-gestützte Entwicklung in Ihrem Team einführen? Sprechen Sie uns an — wir unterstützen Sie bei der Auswahl und dem Einsatz der richtigen Tools.