Schreiben LLMs wirklich besseres Elixir als Python?

Vor einigen Monaten versetzte eine Untersuchung des Tencent AI Labs die Elixir-Community in helle Aufregung. Für die AutoCodeBench-Studie traten mehr als 30 große Sprachmodelle (LLMs) in 20 verschiedenen Programmiersprachen gegeneinander an – mit Elixir als unangefochtenem Spitzenreiter.

Die nackten Zahlen lasen sich geradezu spektakulär: Claude Opus 4 erzielte bei Elixir-spezifischen Aufgaben eine Lösungsquote von 80,3 Prozent. Java (55,9 %) und Python (lediglich 40,3 %) wurden weit abgeschlagen auf die hinteren Plätze verwiesen. Noch verblüffender war die kollektive „Obergrenze“ – jener Anteil an Problemen, die von wenigstens einem der getesteten Modelle geknackt wurden. Hier glänzte Elixir mit sagenhaften 97,5 Prozent und markierte damit den absoluten Bestwert im gesamten Testfeld.

Als jemand, der tagtäglich produktive Elixir-Systeme baut und Entwickler in KI-gestützter Programmierung schult, war ich natürlich mehr als geneigt, diesen Ergebnissen blind zu vertrauen.

Doch mein Entwicklerinstinkt verlangte nach dem Warum.

Der Benchmark ist echt, doch der Vergleich hinkt

Machen wir uns nichts vor: Die Studie vergleicht sprichwörtlich Äpfel mit Birnen. Drei fundamentale methodische Schwächen treiben die Elixir-Werte künstlich in die Höhe – und wer die Ergebnisse richtig einordnen will, muss diese Details kennen.

Erstens: Die Testfälle sind bloße Python-Übersetzungen. Lediglich für sechs der zwanzig untersuchten Sprachen wurden die Aufgaben nativ konzipiert. Die restlichen vierzehn Kandidaten – Elixir eingeschlossen – wurden mit übersetzten Problemstellungen abgespeist. Die Konsequenzen dieses Vorgehens sind massiv: Ein Problem, das dem objektorientierten Paradigma von Python auf den Leib geschneidert ist, schrumpft oft zu einer trivialen Fingerübung zusammen, sobald man es als reine Funktionstransformation formuliert. Weder GenServers noch Supervision-Trees oder klassische OTP-Muster tauchen in den Tests auf. Geprüft wird hier isoliertes, algorithmisches Elixir, nicht aber die Sprache in ihrem natürlichen Habitat.

Zweitens: Der Filter für den Schwierigkeitsgrad versagte bei Nischensprachen. Um allzu simple Aufgaben vorab auszusortieren, nutzten die Forscher ein kleineres Sprachmodell. Sie räumten jedoch selbst ein, dass dieser Filter „Schwierigkeiten hat, einfache Probleme in ressourcenarmen Sprachen zu identifizieren“. Während bei Python satte 25,1 Prozent der Aufgaben als zu banal verworfen wurden, dürfte das Sieb bei Elixir weitaus grobmaschiger gewesen sein. Schon diese methodische Unschärfe allein könnte einen signifikanten Teil des gewaltigen Punkteabstands erklären.

Drittens: Fehlende menschliche Qualitätskontrolle der Elixir-Tests. Eine manuelle Überprüfung der Testfälle fand ausschließlich bei den sechs nativ generierten Sprachen statt (wobei eine Korrektheit von 87,6 Prozent ermittelt wurde). Ob der Elixir-Datensatz von Übersetzungsfehlern oder falschen Testerwartungen durchsetzt ist, steht schlichtweg in den Sternen.

Auch die viel zitierte Obergrenze von 97,5 Prozent sollte eigentlich alle Alarmglocken schrillen lassen. Sie besagt im Grunde, dass der Schwarm der über 30 Modelle nahezu jedes einzelne Elixir-Problem knacken konnte. Zum Vergleich: Bei Python lag dieser Wert bei 63,3 Prozent. Dort gab es also echte, harte Nüsse, an denen sich sämtliche Modelle die Zähne ausbissen. Die logische Schlussfolgerung? Die Elixir-Aufgaben waren mit an Sicherheit grenzender Wahrscheinlichkeit schlichtweg leichter – und nicht per se besser für die Verarbeitung durch LLMs geeignet.

Das Zwischenfazit lautet also: Moderne LLMs beherrschen Elixir auf einem durchaus kompetenten Niveau. Die Sprache ist keineswegs „zu nischig“, um von KI-Programmierwerkzeugen erfasst zu werden. Doch die steile These, LLMs würden Elixir doppelt so gut schreiben wie Python, lässt sich aus der vorliegenden Datenlage beim besten Willen nicht ableiten.

Warum Elixir für LLMs dennoch gefühlt einfacher ist

Hier wird die Sache nun richtig spannend. Selbst wenn der Benchmark das Bild stark verzerrt, existieren handfeste strukturelle Gründe, weshalb ein LLM in Elixir schlicht weniger Angriffsfläche für Fehler findet. José Valim hat diese Aspekte in seinem Blogbeitrag vom Februar 2026 prägnant auf den Punkt gebracht, und seine Kernargumente sind in meinen Augen absolut stichhaltig.

Kein verborgener Zustand. Nirgendwo.

In der Welt der Objektorientierung kann ein simpler Aufruf wie project.updateVersion() klammheimlich jedes Objekt modifizieren, das von project aus referenziert wird – auch solche, die das LLM im aktuellen Kontext noch nie zu Gesicht bekommen hat. Das Modell steht somit vor einem Dilemma: Entweder es beschafft sich massiv zusätzlichen Kontext, um potenzielle Seiteneffekte zu antizipieren, oder es muss schlichtweg raten.

Und wo geraten wird, sprießen die Bugs.

Ein Elixir-Ausdruck wie project = Project.update_version(project) macht den Datenfluss hingegen glasklar und absolut transparent. Alles, was eine Funktion zur Ausführung benötigt, ist explizit in ihren Argumenten gekapselt. Alles, was sie als Resultat erzeugt, findet sich in ihrem Rückgabewert. Es existieren keine versteckten Mutationen, kein geteilter veränderlicher Zustand und keine „spukhafte Fernwirkung“ im Hintergrund.

Für ein LLM, das naturgemäß durch sein Kontextfenster limitiert ist, ist diese Eigenschaft Gold wert. Ein Mangel an verborgenem Zustand bedeutet ganz profan: Es gibt schlicht weniger Gelegenheiten, fatale Fehlentscheidungen zu treffen.

Pattern Matching zwingt zur Präzision

Betrachten wir folgendes Beispiel:

def process({:ok, data}), do: transform(data)
def process({:error, reason}), do: log_error(reason)elixir

Der Vertrag zwischen Aufrufer und Funktion ist hier direkt im Funktionskopf in Stein gemeißelt. Ein LLM, das derartigen Code generiert, wird durch das Muster in ein enges Korsett gezwungen – es muss jeden potenziellen Fall explizit abhandeln. Das Python-Äquivalent if result[0] == "ok" verlässt sich hingegen blind darauf, dass das Modell von sich aus daran denkt, sämtliche logischen Verzweigungen sauber abzuprüfen.

Vergessene Edge-Cases und unvollständige Verzweigungen zählen zu den absoluten Klassikern unter den KI-generierten Bugs. Das Pattern Matching in Elixir macht es auf struktureller Ebene erheblich schwerer, diese Art von Fehlern überhaupt erst in die Welt zu setzen.

Pipes denken wie LLMs

Der Pipe-Operator |> etabliert in Elixir einen eleganten Datenfluss von links nach rechts und von oben nach unten:

data
|> transform()
|> filter()
|> format()elixir

LLMs generieren ihre Token streng sequenziell. Ebenfalls von links nach rechts. Diese lineare, fließende Code-Struktur harmoniert auf ganz natürliche Weise mit der inneren Architektur des Modells. Tief verschachtelte Aufrufe à la format(filter(transform(data))) zwingen die KI hingegen dazu, ihre Logik von innen nach außen zu planen. Für einen sequenziellen Token-Generator ist das ein architektonischer Kraftakt.

Das mag auf den ersten Blick wie eine vernachlässigbare Nuance wirken, doch in der Masse summieren sich diese Kleinigkeiten zu einem echten Vorteil.

Weniger Stolperfallen, weniger Fehler

Python offeriert List Comprehensions, map(), Generator-Ausdrücke und klassische for-Schleifen – und all das für ein und denselben Anwendungsfall. JavaScript kontert mit Callbacks, Promises und Async/Await, garniert mit vier völlig unterschiedlichen Verhaltensweisen für das berüchtigte this-Binding. Ein LLM, das mit all diesen konkurrierenden Paradigmen gefüttert wurde, neigt schnell dazu, innerhalb einer einzigen Funktion völlig inkompatible Ansätze wild miteinander zu vermischen.

Die Standardbibliothek von Elixir ist hingegen ganz bewusst auf das Wesentliche reduziert. Wir sprechen hier von überschaubaren 120 Kernmodulen – ein drastischer Kontrast zu den rund 15.000 öffentlichen Funktionen in Python. Es gibt kein tückisches, implizites this. Kein unberechenbares Variable Hoisting. Keine mutierbaren Closures. Keine komplexe Klassenvererbung.

Ganze Fehlerkategorien, die LLMs in JavaScript und Python am laufenden Band ausspucken, sind in Elixir schlichtweg architektonisch ausgeschlossen.

Der Dokumentations-Vorteil

Diesen Aspekt halte ich persönlich für den überzeugendsten, denn hier sprechen die nackten Fakten für sich.

Elixir behandelt Dokumentation nicht als lästiges Beiwerk, sondern als erstklassiges Sprachfeature. Die Attribute @doc und @moduledoc versauern nicht in simplen Kommentaren, sondern werden direkt in den kompilierten Bytecode eingebettet. Jedes über Hex veröffentlichte Paket erhält vollautomatisch eine standardisierte Dokumentation auf HexDocs. Ein einheitliches Format, eine zentrale Plattform, eine durchgängig klare Struktur. Vergleichen Sie das einmal mit der völlig zersplitterten Landschaft in Python, wo Sphinx, MkDocs, ReadTheDocs und gleich drei konkurrierende Docstring-Formate einen ständigen Revierkampf ausfechten.

Das eigentliche Killer-Feature sind jedoch die Doctests:

@doc """
Adds two numbers.

    iex> Math.add(1, 2)
    3
"""
def add(a, b), do: a + belixir

Dieses iex>-Beispiel ist nicht nur Text, es wird bei jedem Durchlauf als echter Unit-Test ausgeführt. Liefert der Code ein falsches Ergebnis, schlägt die gesamte Test-Suite gnadenlos fehl. Der logische Umkehrschluss daraus ist gewaltig: Die Codebeispiele, die in die Trainingsdaten der LLMs fließen, sind nachweislich und mathematisch korrekt.

In den weitläufigen Ökosystemen von Python oder JavaScript sucht man einen vergleichbaren, flächendeckenden Mechanismus vergeblich. Dort verrotten Dokumentationsbeispiele regelmäßig und unbemerkt. In Elixir ist das schlicht unmöglich – der Compiler schiebt dem sofort einen Riegel vor.

Das ist weit mehr als nur ein theoretischer Vorteil. Es garantiert signifikant sauberere Trainingsdaten, und das auf einer enormen Skala.

Zwölf Jahre Stabilität

Kommen wir zu einem echten Elefanten im Raum, der in der Debatte viel zu oft ignoriert wird.

Eine auf der ICSE 2025 veröffentlichte Studie nahm sieben führende LLMs hinsichtlich ihrer Neigung zu veralteten Python-APIs unter die Lupe. Das erschreckende Resultat: Wurden die Modelle mit einem veralteten Code-Kontext konfrontiert, generierten ausnahmslos alle in 70 bis 90 Prozent der Fälle veraltete API-Aufrufe. Doch selbst bei einem hochaktuellen Kontext griffen sie noch in 9 bis 18 Prozent der Fälle auf veraltete Muster zurück. Auch der GitChameleon 2.0 Benchmark zeichnet ein düsteres Bild: Selbst die absoluten Spitzenmodelle kamen bei versionsspezifischen Python-Aufgaben auf eine magere Erfolgsquote von rund 50 Prozent.

Führen Sie sich einmal vor Augen, was das in der Praxis bedeutet. Das LLM hat ein volles Jahrzehnt des schmerzhaften Übergangs von Python 2 auf 3, zahllose radikale TensorFlow-Rewrites und das ständige Stühlerücken bei den Paketierungstools (pip, pipenv, poetry, PDM, uv) ungefiltert in sich aufgesogen. Es hat für exakt dieselben Aufgabenstellungen völlig widersprüchliche Lösungswege verinnerlicht. Wenn ein Modell heute Python-Code generiert, navigiert es faktisch blind durch ein Minenfeld aus veraltetem Halbwissen.

Und nun blicken wir auf Elixir.

Die Version 1.0 erblickte am 18. September 2014 das Licht der Welt. Heute, fast zwölf Jahre später, befinden wir uns noch immer im v1.x-Zyklus. Das Web-Framework Phoenix ist seit seinem initialen Release nie von v1.x abgewichen. Die letzte weitreichende Hauptversion von Ecto datiert auf das Jahr 2018. Um es mit den Worten von José Valim zu sagen: „Alles, was im letzten Jahrzehnt über Elixir oder Phoenix geschrieben wurde, funktioniert auch heute noch absolut fehlerfrei.“

Keine kognitive Dissonanz. Keine zermürbenden Versionskonflikte. Kein ständiges Rätselraten, welches Paradigma gerade als „veraltet“ und welches als „State of the Art“ gilt.

Wenn jedes einzelne Codebeispiel der letzten zwölf Jahre auf exakt denselben APIs aufbaut, muss das LLM nicht erst mühsam evaluieren, welche Version der Realität gerade Gültigkeit besitzt. Für mich ist genau das der ultimative Trumpf von Elixir. Es ist nicht irgendein synthetischer Benchmark-Score, der hier den Ausschlag gibt, sondern die reale, messbare Vermeidung jener immensen Kosten, die durch ein instabiles Ökosystem unweigerlich entstehen.

Die ehrlichen Gegenargumente

Es wäre schlichtweg unaufrichtig, an dieser Stelle nur die Sonnenseiten zu preisen. Die Argumentation pro Elixir hat durchaus ihre handfesten Schwachstellen, die wir nicht unter den Teppich kehren dürfen.

Der eklatante Mangel an Trainingsdaten. In den gigantischen Datensätzen der KI-Modelle macht Elixir schätzungsweise gerade einmal 0,05 bis 0,2 Prozent des Codes aus. Das ist ein Volumen, das etwa 50- bis 100-mal kleiner ist als das von Python. Eine Studie aus dem Jahr 2025 belegt eindrucksvoll, dass LLMs fast schon reflexartig auf Python zurückgreifen, selbst wenn andere Sprachen für das spezifische Problem weitaus besser geeignet wären. In satten 58 Prozent der Fälle fiel die Wahl blind auf Python. Ein derart massiver Bias lässt sich nicht einfach wegdiskutieren.

Ein funktionales Paradigma ist kein Allheilmittel. Die viel beachtete „Perish or Flourish“-Studie offenbarte bei OCaml eine erschreckende Kompilierungsfehlerrate von 43 Prozent. Auch Haskell schnitt mit 25 Prozent alles andere als rosig ab – insbesondere im direkten Vergleich zu Java, das mit lediglich 4,6 Prozent glänzte. LLMs leiden unter einem ausgeprägten „imperativen Bias“: Sie tendieren stark dazu, Muster mit veränderlichen Variablen zu generieren, selbst wenn sie sich tief in funktionalem Code bewegen. Die stark von Ruby inspirierte Syntax mag Elixir zwar vor den schlimmsten Auswüchsen dieses Phänomens bewahren, doch die Grundwahrheit bleibt bestehen: Ein rein funktionales Design ist per se noch kein Garant für besseren KI-Code.

Der Benchmark geht an der Realität vorbei. AutoCodeBench evaluiert ausschließlich isolierte, algorithmische Trockenübungen. Es geht dort nicht um komplexe Phoenix LiveView-Komponenten. Nicht um verschachtelte Ecto-Changesets. Und schon gar nicht um das anspruchsvolle Design robuster Supervision-Trees. Zach Daniel, der kluge Kopf hinter dem Ash Framework, merkte treffend an, dass LLMs ohne maßgeschneiderte Kontext-Dateien „für die Ash-Entwicklung praktisch nutzlos“ sind – wenngleich er im selben Atemzug eindrucksvoll demonstrierte, wie gezieltes Tooling dieses Blatt komplett wenden kann.

Die empirische Beweislage ist hauchdünn. Lässt man AutoCodeBench einmal beiseite, findet sich mit MultiPL-E gerade einmal ein einziger weiterer großer Code-Generierungs-Benchmark, der Elixir überhaupt auf dem Radar hat. Die Branchengrößen wie HumanEval, MBPP, SWE-bench oder BigCodeBench ignorieren die Sprache komplett. Ein einzelner Benchmark, der noch dazu mit gravierenden methodischen Mängeln zu kämpfen hat, ist ein denkbar wackeliges Fundament, um darauf derart weitreichende Thesen zu errichten.

Was ich im Alltag tatsächlich beobachte

In meinem beruflichen Alltag verschmelzen LLMs und Elixir nahtlos miteinander. Ich architekte produktive Systeme, konzipiere Schulungsmaterialien und setze KI-Tools intensiv beim Pair-Programming in anspruchsvollen Kundenprojekten ein. Wenn ich meine praktischen Erfahrungen resümiere, decken sich diese weitaus stärker mit den strukturellen Argumenten als mit den hochgejubelten Benchmark-Zahlen.

Für klassische Datentransformationen, komplexe Pattern-Matching-Logik und eleganten Pipeline-Code liefern LLMs durchweg sauberes, geradezu idiomatisches Elixir. Sie navigieren traumwandlerisch sicher durch die Standardbibliothek und produzieren nur äußerst selten Code, der bereits am Compiler scheitert.

Doch sobald es ans Eingemachte geht, geraten sie ins Straucheln. Bei tiefgreifenden, frameworkspezifischen Mustern. Bei der orchestrierten Kombination diverser Bibliotheken. Bei speziellen Nischenpaketen. Kurzum: bei exakt jenen Herausforderungen, die den absoluten Löwenanteil der realen Softwareentwicklung ausmachen.

Der immense Stabilitätsvorteil von Elixir ist im Arbeitsalltag hingegen omnipräsent. Es kommt in meiner Praxis so gut wie nie vor, dass mir ein LLM eine veraltete oder abgekündigte Elixir-Funktion serviert. Wer in Python-Projekten unterwegs ist, weiß: Dort gehört genau das zur frustrierenden Tagesordnung.

Microsoft Research hat mit dem phi-1 Modell eindrucksvoll bewiesen, dass ein geradezu winziges Modell, das ausschließlich mit handverlesenen Daten in „Lehrbuchqualität“ trainiert wird, Giganten übertrumpfen kann, die zehnmal so groß sind. Dieses fundamentale Prinzip – Datenqualität schlägt Datenquantität – lässt sich nahtlos auf das Elixir-Ökosystem übertragen. Die durch Doctests verifizierte Dokumentation und die extrem konsistenten APIs zahlen genau auf dieses Konto ein.

Ob diese qualitative Brillanz am Ende ausreicht, um eine 50- bis 100-fache Lücke beim reinen Volumen der Trainingsdaten zu schließen, muss die Zukunft zeigen. Doch die Indizien weisen unverkennbar in eine vielversprechende Richtung.

Wo wir also stehen

Die kühne Behauptung, Elixir sei die ultimative Sprache für die KI-gestützte Codegenerierung, fußt auf einem einzigartigen Zusammenspiel handfester architektonischer Eigenschaften: strikte Unveränderlichkeit, expliziter Datenfluss, mächtiges Pattern Matching, rigoros getestete Dokumentation und eine fast schon stoische API-Stabilität. Jeder dieser Aspekte ist für sich genommen absolut plausibel. In der Summe formen sie ein äußerst schlüssiges und überzeugendes Gesamtbild.

Dennoch dürfen wir die Augen nicht davor verschließen, dass der am häufigsten ins Feld geführte Benchmark massiv verzerrt ist. Der glorreiche erste Platz spiegelt die raue Realität schlichtweg nicht akkurat wider.

Was die Branche jetzt dringend benötigt, ist ein ehrlicher Benchmark. Ein Testfeld mit nativ konzipierten Elixir-Aufgaben, menschlich verifizierten Testfällen, einem intelligent kalibrierten, sprachübergreifenden Schwierigkeitsgrad und der Abdeckung realer Framework-Muster. Keine lieblosen, aus Python übersetzten Algorithmus-Übungen mehr.

Bis ein solcher Maßstab existiert, lautet meine ehrliche und ungeschönte Einschätzung: Elixir bringt fundamentale strukturelle Eigenschaften mit, die LLMs massiv dabei unterstützen, korrekten und robusten Code zu generieren. Die aktuell noch überschaubare Beweislage stützt diese Hypothese durchaus. Doch abschließend und rigoros getestet ist sie noch lange nicht.

Mich persönlich überzeugen die architektonischen Argumente voll und ganz, weshalb ich auch in Zukunft kompromisslos auf diesen Tech-Stack setze. Das KI-Ökosystem rund um Elixir entwickelt sich in einem atemberaubenden Tempo weiter. Doch am Ende des Tages argumentiere ich lieber ehrlich, fundiert und aus der Praxis heraus, anstatt einen methodisch fragwürdigen Benchmark künstlich in den Himmel zu loben.