AI-Coding-Agenten reißen Sprachbarrieren in der Programmierung ein
(railsatscale.com)- Durch die Weiterentwicklung von AI-Coding-Tools entsteht eine Umgebung, in der Entwickler schnell in neue Sprachen einsteigen können
- Der Autor war 10 Jahre lang ausschließlich Ruby-Entwickler, kann aber dank der Zusammenarbeit mit AI-Coding-Agenten in diesem Jahr (z. B. Cursor, Claude Code) praktisch zu Systemsprachen wie C, C++ und Rust beitragen
- Tools wie Claude Code und Cursor helfen besonders stark bei Sprachsyntax, Idiomen und allgemeiner Theorie
- AI ist kein Codegenerator, sondern ein „Pair Engineer als Sprachexperte“ und maximiert in Kombination mit bestehender Erfahrung die Lerneffizienz durch Fragen in Echtzeit, Kontexterklärungen und Analyse von Beispielen
- Auch wenn AI nicht den gesamten projektspezifischen Kontext oder tiefe interne Strukturen kennt, kann sie bei Sprachsyntax, typischen Mustern und Standardbibliotheken sofort beraten, sodass praktische Beiträge ohne mehr als 100 Stunden Vorablernen möglich werden
- Der Einsatz von AI-Tools verändert das traditionelle Verständnis von Expertise in Programmiersprachen rasant, und es entsteht ein Umfeld, in dem immer mehr Entwickler produktiv in mehreren Sprachen arbeiten können
10 Jahre Ruby-Entwickler, Wechsel in die Mehrsprachigkeit
- Der Autor war von 2014 bis 2024 ausschließlich im Ruby- und Rails-Ökosystem tätig
- In dieser Zeit sammelte er Erfahrung bei der Entwicklung und Wartung zentraler Tools des Ruby-Ökosystems wie Rails, IRB, RDoc und dem
debug-Gem
- In dieser Zeit sammelte er Erfahrung bei der Entwicklung und Wartung zentraler Tools des Ruby-Ökosystems wie Rails, IRB, RDoc und dem
- Seit 2025 trägt er zu System-Layer-Projekten außerhalb von Ruby bei, etwa Sorbet (C++), dem RBS-Parser (C) und ZJIT (Rust)
- Ermöglicht wurde dieser Wandel durch die Einführung von AI-Coding-Agenten (Cursor, Claude Code)
- Auch innerhalb von Shopify wird die aktive Nutzung dieser AI-Tools gefördert
Eine perfekt entstandene Gelegenheit
- Es lag nicht nur an AI, sondern auch daran, dass mehrere wichtige Bedingungen zusammenkamen
- Durch eine Änderung der Roadmap des Ruby-DX-Teams wurde RBS-Support in Sorbet erforderlich → damit war C/C++-Erfahrung zwangsläufig gefragt
- Mitglieder des Ruby-&-Rails-Infrastrukturteams bei Shopify teilten ihr Know-how und boten ein aktives Tutoring-Umfeld
- Gute Mentoren und reale Projektchancen gab es zwar schon vorher, aber AI hat Lernbarrieren und Lernkurve radikal verkürzt
Die Komplexität der Systemprogrammierung
- Fallbeispiel des ZJIT-Projekts (ein neuer JIT-Compiler für Ruby):
- Es werden gleichzeitig vielfältige, komplexe Kenntnisse und Fähigkeiten benötigt
- Rust (Hauptsprache), C (Implementierungssprache des Ruby-Kerns), JIT-/Compiler-Theorie, ZJIT-spezifische Struktur und Architektur, interne Funktionsweise von Ruby, Ruby-Build-Systeme (
autoconf,Makefileusw.) - Ein einzelner Pull Request behandelt oft gleichzeitig 2 bis 4 Bereiche
- Die Effizienz von Claude Code
- Bei Syntax, allgemeiner Compiler-Theorie sowie Sprachgrammatik und Ausdrucksmustern in Rust/C/C++ ist die Genauigkeit hoch
- Beim projektspezifischen Kontext, der internen Ruby-Implementierung und der Unterstützung komplexer Build-Systeme sind die Möglichkeiten etwas eingeschränkt
- Trotzdem sinkt die Einstiegshürde im Lernprozess um mehr als die Hälfte
- AI unterstützt sofort beim Erlernen von Sprachsyntax, Theorie und Mustern, während der projektspezifische Kontext weiterhin Sache des Menschen bleibt
Pair Programming mit AI
- Der Autor begann, AI nicht als bloßen Codegenerator, sondern als ergänzenden Partner zu sehen
- Konkrete Form der Zusammenarbeit
- Der Entwickler übermittelt Aufgabenanforderungen und Kontext
- Die AI erkennt Muster und übernimmt die Rolle eines Sprachexperten
- Der Entwickler fragt nach den Gründen hinter dem Design
- Die AI überarbeitet den Code oder untersucht die Theorie und liefert die Ergebnisse
- Durch interaktives Lernen werden die Sprache selbst und ihre praktische Anwendung gleichzeitig erlernt
- Beispiel: Bei einer Aufgabe zum Profiling von Ruby-Bytecode-Instruktionen kann man die AI bitten, frühere PRs zu durchsuchen und sie Zeile für Zeile zu erklären
- Auch „dumme Fragen“ lassen sich ohne Hemmungen stellen („Warum braucht ein JIT-Compiler Profiling?“ usw.)
- Man erhält sofort Feedback zu ungewohnter Syntax
- Es gibt auch Fehlschläge
- Wenn die Projektrichtung falsch läuft, ist am Ende doch Korrektur durch einen Kollegen oder Mentor nötig
- Letztlich bleibt die Fähigkeit menschlicher Experten zur Kurskorrektur unverzichtbar
Der Abbau von Sprachbarrieren in der Programmierung
- Wir leben jetzt in einer Zeit, in der man nicht mehr 100 Stunden vorlernen muss, um zu einem neuen C-Projekt beizutragen
- Selbst Sprachen mit hoher Einstiegshürde wie C und Rust ermöglichen mit Hilfe von AI sofortige Beiträge
- AI erkennt typische Anfängerfehler (Syntaxfehler, Typfehler, Missverständnisse bei der Tool-Nutzung usw.) schnell, sodass sofort praktische Beiträge möglich werden
- Tiefe Expertise bleibt wichtig, aber produktives Arbeiten in mehreren Sprachen wird für mehr Entwickler erreichbar
- Syntax/Standardfunktionen/Muster kann man der AI überlassen, während sich Entwickler auf echte Problemlösung konzentrieren
- Dass ein Ruby-Spezialist wie der Autor innerhalb eines Jahres zum Mehrsprachen-Entwickler wurde, ist ein revolutionärer Trend
- Der Übergang vom „Entwickler, der nur eine Sprache nutzt“ zum „mehrsprachig produktiven Entwickler“ wird Realität
- Möglich, dass dies der Anfang eines Wandels ist, bei dem sich schon das Konzept sprachspezifischer Expertise verändert
Fazit
- AI-Coding-Agenten senken die Einstiegshürden in Programmiersprachen drastisch und eröffnen
eine neue Ära, in der Entwickler in mehreren Sprachen sofort produktiv arbeiten können
5 Kommentare
Code zu generieren ist das eine, aber wer übernimmt die Prüfung oder das Review des Codes...
Auch wenn man eine weniger vertraute Sprache nicht wirklich schreiben kann, kann man sie oft zumindest grob lesen, daher dürfte man im Vergleich zu früher tatsächlich Zeit sparen.
Ich habe das Gefühl, dass man bei Technologien, die man noch nicht ausprobiert hat, oder in Bereichen, mit denen man noch keine Erfahrung hat, wirklich viel schneller vorankommen kann als früher.
Hacker-News-Kommentare
Ich frage mich, ob AI wirklich die Lernkurve verändert oder nur Erfahrung bequemer macht.
Auf den Erfahrungsbericht von jemandem, der 10 Jahre lang nur Ruby gemacht hat und innerhalb eines Jahres zum Entwickler für mehrere Sprachen geworden ist und das als revolutionär empfand, würde ich eher sagen: Das ist vielmehr etwas, das er „10 Jahre lang nicht versucht hat“.
Die erste Programmiersprache zu lernen und nach einigen Jahren Erfahrung eine neue Sprache zu lernen, sind völlig unterschiedliche Erfahrungen.
Ich denke genauso.
Mit Entwicklern, die 10 Jahre lang nur eine Sprache gemacht haben, kann ich mich schwer identifizieren.
Anfangs hatte ich eine starke Identifikation mit der gewählten Sprache, aber von wirklich erfahrenen Entwicklern habe ich gelernt, dass „Sprachen nur Werkzeuge sind“.
Wenn man mehrere Sprachen kennenlernt, erweitert das den Blick enorm, und man gewinnt Einsichten, die sich schwer in Worte fassen lassen.
Dass ich diese Erfahrung machen durfte, macht mich wirklich glücklich.
Die Aussage „Auch ohne AI hätte man in einem Jahr problemlos mehrere Sprachen lernen können“ ist meiner Meinung nach bis zu einem gewissen Grad zutreffend.
In meiner Erfahrung bin ich bei kleinen Python-Projekten mit o4 auf interessante Edge Cases gestoßen; ohne AI hätten viele davon die Arbeit ausgebremst.
Beispiele wären etwa, wie unraid XML-VMs verarbeitet oder Probleme, die in dockers auftreten, und wenn man das selbst untersucht, kann das locker einen ganzen Tag dauern.
Da AI einen dabei inzwischen anleitet, kommt man über solche Stellen viel reibungsloser hinweg.
Das ist auch ein bisschen beängstigend, aber es funktioniert wirklich gut.
Meine erste Programmiersprache war übrigens das alte BASIC.
AI macht Mainstream-Sprachen noch populärer.
Die Sprachen, in denen AI am wenigsten Fehler macht, sind meist Python, JS oder Ruby — also Sprachen mit großen Communities und riesigen Datensätzen.
Daher ist der Effekt einer niedrigeren Zugangshürde bei Nischensprachen nicht besonders groß.
Denn die meisten Programmierer sind in Nischensprachen nicht geübt genug, um auch kleine Bugs zuverlässig zu erkennen.
Wie schon die Lehren aus dem Machine Learning zeigen, ist am Ende die Seite mit mehr Trainingsdaten im Vorteil.
AI ist stark im Pattern Matching.
Wenn man ein Problem in bekannte Muster übersetzt, liefert sie sofort gute Codebeispiele.
Je komplexer oder ungewöhnlicher das Problem ist, desto weniger nützlich ist AI.
Menschen können mit abstrakteren und dynamischeren Konzepten flexibler umgehen.
Wer Nischensprachen benutzt, legt meist mehr Wert auf andere Dinge als Popularität (z. B. Effizienz, Geld, Lernen usw.).
Wenn Sprachpopularität wichtig ist, könnten Experten viele gute idiomatische Beispielcodes bereitstellen, und AI könnte daraus verschiedene Varianten erzeugen — so ließe sich die Einstiegshürde stark senken.
Wenn kleine Coding-Aufgaben leichter werden, interessieren sich die Leute womöglich auch stärker für die Sprache selbst.
LLMs neigen dazu, in Nischensprachen häufiger Unsinn zu produzieren.
Ich bin Scala-Entwickler, und meiner Ansicht nach hängt der größte Teil der Diskussion über den Nutzen von AI davon ab, welche Sprache man verwendet.
Bei einer Sprache wie JS könnte sie nützlicher sein.
Ich mache mir Sorgen, dass Leute neue Sprachen oder Frameworks meiden könnten, wenn AI sie anfangs nicht präzise genug unterstützt.
Dann wirkt der Aufwand womöglich größer als der Nutzen.
Mit jedem neuen Release werden AI-freundliche MCP-Dokumentation oder ergänzende Materialien fast unverzichtbar.
Ich persönlich hatte mit claude und Elm sehr positive Erfahrungen.
Dank des statischen Typsystems war die Genauigkeit hoch und die Hilfe groß.
Natürlich kommen manchmal seltsame Antworten, aber ich vermute, das kennen alle.
Ich glaube, wir leben de facto in einer Zeit, in der es zwischen großen Sprachen kaum noch Barrieren gibt.
Selbst wenn man nur die zehn Sprachen betrachtet, die heute breit in der Anwendungsentwicklung genutzt werden, stammen die meisten aus der C- oder ALGOL-Familie und teilen ähnliche Syntax, call-by-reference und automatisches Speichermanagement.
Ein professioneller Entwickler sollte zwischen diesen Sprachen ohne allzu große Mühe wechseln können.
Speichermanagement zum ersten Mal zu lernen kann etwas mühsam sein, aber mit vertrauten Mustern, Warnungen und Lintern ist das gut machbar.
Wirklich steile Lernkurven haben eher Sprachen wie Rust, Ada SPARK, Lisp, Forth oder ML, und das sind keine Mainstream-Sprachen.
Ich nutze AI als unterstützenden Programmierpartner.
Ich verwende die „breite, aber flache Wissensbasis“ von AI zunächst zur Orientierung und ziehe sie dann hinzu, wenn ich in einen bestimmten Bereich tiefer einsteigen will.
Ich nutze sie weniger zum Lernen neuer Programmiersprachen als vielmehr für neue Konzepte oder Technologien (z. B. WebAuthn-Backends oder die Integration von Passkeys).
Auch für Anfänger ist AI eine große Hilfe.
Allerdings hat AI mir auch schon falsche Beispiele geliefert, etwa veraltete Dependencies — am Ende war das sogar gut, weil ich dadurch ein tieferes Verständnis gewonnen habe.
Ich möchte AI nicht die vollautomatische Entwicklung einer App überlassen.
Kleine Fehler kommen immer wieder vor, daher ist Prüfung zwingend nötig.
AI hilft mir sehr beim Einarbeiten in eine Swift-Codebasis, mit der ich erst seit Kurzem zu tun habe.
Sie klärt offene Fragen schnell und beschleunigt mein Lernen.
Um in komplexen Projekten tatsächlich substanziell beizutragen, sind aber weiterhin Skill und Erfahrung unverzichtbar.
Schon in Sprachen, die ich kenne, liegt sie oft daneben; in unbekannten Sprachen wird selbst das Review schwierig.
Wenn man bei jeder neuen Sprache so tief einsteigen muss, um die Ergebnisse zu prüfen, dauert das lange, bis man ausreichend vertraut ist.
Es heißt oft, die Sprachbarrieren würden kleiner, aber in der Praxis sieht man auch Fälle wie WhatsApp, das statt einer Desktop-App zu einer Web-App wechselt — die Barrieren sind also nicht vollständig verschwunden.
Das erinnert mich daran, wie Microsoft früher mit der .Net-Plattform dafür geworben hat, dass Teams mit J#, Fortran.Net, Cobol# und anderen Sprachen gemeinsam in einem Team arbeiten können.
Es hieß damals sogar, dass auf diese Weise selbst herausragende #Intercal-Talente ihre Produktivität vervierfachen könnten.
Ich erwarte, dass sich Programmiersprachen durch AI eher in Richtung starker Hindley-Milner-Typsysteme entwickeln.
Haskell ist schwer zu lernen, aber mit ausreichend Datensätzen wäre es ein perfektes Ziel für Coding Agents.
Es ist High-Level, formal verifizierbar und lässt sich leicht mit Sprachservern und AI verbinden.
In der Realität sieht es eher so aus, als würde Haskell bei der AI-Unterstützung sogar eher außen vor bleiben.
Wenn man funktionale Sprachen mag, sollte man sich fragen, warum Natural-Language-Programming so attraktiv wirkt.
Natürliche Sprache kann Ergebnisse mehrdeutig ausdrücken, und die Maschine füllt diese Unschärfe automatisch auf.
Für eine echte Innovation bräuchte es eher eine Programmierweise mit starker Logik + Mehrdeutigkeit, etwa auf Basis logischer Systeme wie MTL.
Leider ist die Forschung in diesem Bereich fast zum Stillstand gekommen, während neuronale Netze dominieren.
Haskell ist aus Sicht von LLMs wegen seiner tiefgreifenden Spracheigenschaften weniger zugänglich.
LLMs arbeiten nun einmal primär mit Textmustern.
Sprachen mit einfachen Eigenschaften und hilfreichen Compiler-Fehlermeldungen (z. B. Go) liegen AI besser.
Ich persönlich mag starke Typinferenz, aber aus AI-Sicht ist das etwas anderes.
Ich habe LSP-MCP-Tools + LLM ausprobiert und war etwas enttäuscht.
LSP wurde ursprünglich für menschliche Nutzer entworfen und passt daher nicht perfekt zu AI.
LLMs sind stark im Pattern Matching, und wenn die Typstruktur einfach ist, treten fast keine Typfehler auf.
Bei komplexeren Strukturen schafft das LLM die Lösung womöglich nicht, oder der Nutzer versteht sie nicht.
Es kam auch die Frage auf, ob es mit Haskell groß angelegte Fälle von formaler Verifikation gibt; seL4, CompCert usw. basieren größtenteils auf C oder auf Coq + OCaml.
Die Nutzung von Dependently Typed Languages wie Agda könnte zunehmen.
Wenn die Datensätze allerdings zu klein sind, könnte der Wissenstransfer für AI schwierig werden.
Es ist gut, AI als Pair-Programming-Partner zu behandeln.
Je mehr der Nutzer lernt, desto stärker verschiebt sich die Rolle von AI: anfangs Grundlagenerklärungen und kleine Codegenerierung, später fortgeschrittene Diskussionen + größere Codeblöcke und Code-Reviews.
Mit der Zeit entdeckt man selbst immer mehr Bugs.
Wenn man AI nicht nur als simplen Codegenerator sieht, sondern als Partner mit ergänzenden Fähigkeiten, ist sie wirklich hilfreich.
In einer unbekannten Sprache sollte man die vorgeschlagenen Lösungen von AI gründlich hinterfragen.
Wenn man konkret fragt wie „Warum macht man das so?“ oder „Und in anderen Szenarien?“, hilft das beim Lernen enorm.
Durch Fragen bestätigt AI zwar oft meine Gedanken, aber nach einigen Wiederholungen fällt es schwer, ihr vollständig zu vertrauen.
Es ist auch sinnvoll, sich anzugewöhnen, AI dazu zu bringen, klare Fragen zu stellen.
So kann man Missverständnisse oder logische Lücken früh erkennen.
Ich habe Gemini auf seine Codegenerierung getestet und um ein bash-Skript gebeten, aber es enthielt Fehler.
Zum Glück kenne ich bash und konnte das sofort korrigieren, aber wenn es eine unbekannte Sprache gewesen wäre, würde ich nicht sagen, dass damit wirklich eine Sprachbarriere beseitigt ist.
Ich denke, das ist eher ein spezielles Problem von bash.
Als ich zum Beispiel ähnliche Automatisierungsaufgaben in Go einem LLM gegeben habe, hat es auf Anhieb funktioniert.
Ich würde das weniger als Problem von bash oder Gemini sehen; Kritik nur mit einem Markennamen zu üben, ohne genaue Informationen über das AI-Modell zu nennen, überzeugt mich nicht.
Mit Einstellungen wie „Gemini 2.5 Pro (Jan 2025), Temperatur 0.15“ erzeugt es tatsächlich sofort ein ausgezeichnetes idiomatic bash script.
(Beispielcode ausgelassen)
Ich hatte allerdings auch Probleme mit Zeilenenden in Dateien, die unter WSL2 mit Windows Notepad bearbeitet wurden, und Gemini hat mir freundlich die Lösung erklärt.
Interessant ist auch, dass bash selbst die Einschränkung hat, dass die letzte Zeile ohne abschließenden Zeilenumbruch nicht korrekt verarbeitet wird.
In PowerShell ist dieselbe Aufgabe fast als Einzeiler möglich, und dort gibt es auch kein Problem, wenn am Ende kein Zeilenumbruch steht.
Mit Hilfe von Gemini konnte ich auch PowerShell auf kurzen Code hin optimieren.
https://ruby-news.kr/articles/…
Eine Zusammenfassung aus einem Dienst, den ich betreibe. Es ist eine Übersetzung, also ähnlich, aber GeekNews ist etwas besser aufbereitet und angenehmer zu lesen.