Eine Funktion erwartet eine Zahl, aber irgendwo im Projekt wird stattdessen eine Zeichenkette übergeben. Der Compiler sagt nichts, die Tests decken den Fall nicht ab, und der Fehler tritt erst auf, wenn ein Kunde in der Produktion genau diesen Codepfad auslöst. Wer mit dynamisch getypten Sprachen arbeitet, kennt diese Klasse von Bugs: Typen werden erst zur Laufzeit geprüft, der Compiler trifft über sie von sich aus keine Annahmen.

Python, Ruby und JavaScript funktionieren nach diesem Prinzip, die funktionale Programmiersprache Elixir ebenfalls. Der Komfort: Code bleibt knapp und lässt sich leicht umbauen. Der Preis: Fehler werden erst sichtbar, wenn das Programm auf den unerwarteten Wert trifft.

Ein Beispiel zeigt, was sich bei Elixir mit dem am 3. Juni 2026 erschienenen Release 1.20 ändert. Die folgende Funktion nimmt eine Map entgegen, Elixirs Schlüssel-Wert-Struktur (geschrieben %{schlüssel: wert}, vergleichbar einem Dictionary in Python oder einem Hash in Ruby), und wandelt das darin enthaltene Feld age in eine Zeichenkette um:

defmodule Report do
  def user_age_to_string(user) do
    Integer.to_string(user.age)
  end
end

# An anderer Stelle im Projekt:
Report.user_age_to_string(%{age: "42"})

Integer.to_string/1 ist dabei Elixirs übliche Schreibweise für eine Funktion: Modul, Funktionsname und nach dem Schrägstrich die Stelligkeit (Arity), also die Zahl der Argumente. Bis einschließlich Version 1.19 schwieg der Compiler zu diesem Code; dass age eine Zeichenkette statt einer Zahl enthält, fiel erst zur Laufzeit auf. Ab 1.20 erscheint eine Warnung beim Übersetzen:

warning: incompatible types given to Report.user_age_to_string/1:

    Report.user_age_to_string(%{age: "42"})

given types:

    %{age: binary()}

but expected one of:

    %{..., age: integer()}

Zwei Notationen darin sind erklärungsbedürftig (Typnamen tragen in Elixir stets leere Klammern). binary() ist Elixirs Typ für Zeichenketten, denn Strings sind in Elixir intern UTF-8-kodierte Binärdaten. Und die Ellipse in %{..., age: integer()} steht für beliebige weitere Schlüssel: Gemeint ist jede Map, die mindestens den Schlüssel age mit einem integer(), einer ganzen Zahl, enthält.

Niemand hat dem Compiler mitgeteilt, welchen Typ user.age haben soll. Er hat es selbst erschlossen: Integer.to_string/1 verlangt eine ganze Zahl, also muss das Feld age eine ganze Zahl enthalten, also muss jeder Aufrufer eine Map mit genau diesem Merkmal übergeben. Die Schlussfolgerung klingt trivial, aber sie steckt in keiner Typannotation, also keinem expliziten Typhinweis im Quelltext, wie ihn typisierte Sprachen verlangen (name: string in TypeScript, String name in Java). In Elixir 1.20 übernimmt der Compiler diese Arbeit von selbst.

Das dahinterstehende Typsystem, das seit Version 1.17 schrittweise in die Sprache einzog, analysiert inzwischen jedes Sprachkonstrukt. Es erkennt nicht nur fehlerhafte Argumente wie im Beispiel oben, sondern verfolgt auch, wie sich das Wissen über einen Wert durch mehrere Fallunterscheidungen hindurch verfeinert, und deckt dabei toten Code und widersprüchliche Zugriffe auf. Was abstrakt klingt, markiert einen Wendepunkt in der Geschichte von Elixir.

Sämtliche Vorteile des neuen Typsystems gibt es automatisch und ohne eigenes Zutun. An der Arbeitsweise muss sich nichts ändern, bestehender Code kompiliert unverändert weiter, niemand muss Typannotationen schreiben oder neue Syntax lernen; die zusätzliche Fehlersuche läuft bei jedem Übersetzen einfach mit.

Elixir kurz erklärt

Elixir ist eine funktionale, dynamisch getypte Sprache, die der Brasilianer José Valim 2012 veröffentlichte. Sie läuft auf der BEAM, der virtuellen Maschine von Erlang, und erbt von dort leichtgewichtige Prozesse im Millionenbereich (von der VM verwaltet, keine Betriebssystemprozesse) sowie eine ausfallsichere Laufzeit durch Supervisoren: überwachende Prozesse, die abgestürzte Teile des Systems automatisch neu starten.

Bekannt ist Elixir vor allem durch das Web-Framework Phoenix, das Embedded-Framework Nerves (Firmware-Images für Geräte vom Raspberry Pi bis zur Industriesteuerung) und Nx, das Elixir in die Welt des maschinellen Lernens bringt. Allen gemein ist ein Programmierstil, den eine kleine Funktion illustriert; sie übersetzt das Ergebnis einer Operation in einen lesbaren Satz:

defmodule Ergebnis do
  def beschreibe({:ok, wert}),        do: "Erfolg: #{wert}"
  def beschreibe({:error, :timeout}), do: "Zeitüberschreitung"
  def beschreibe({:error, grund}),    do: "Fehler: #{grund}"
  def beschreibe(:pending),           do: "läuft noch"
end

Vier Klauseln, vier Fälle. Eine Funktion darf in Elixir aus mehreren Definitionen gleichen Namens bestehen, den Klauseln; welche läuft, entscheidet kein if oder switch, sondern die Form des Arguments. Diesen Musterabgleich nennt man Pattern Matching. Die erste Klausel greift für einen Tupel, eine geordnete Sammlung fester Länge in geschweiften Klammern, dessen erstes Element das Atom :ok ist; den zweiten Wert bindet sie an die Variable wert und fügt ihn per #{...} in den Antwortsatz ein, Elixirs String-Interpolation, vergleichbar mit f-Strings in Python. Atome wie :ok oder :pending sind benannte Konstanten, deren Wert ihr eigener Name ist, vergleichbar mit Symbols in Ruby. Die zweite Klausel fängt den speziellen Fehlerfall :timeout ab, die dritte jeden anderen Fehler, die vierte das schlichte Atom :pending. Das do: ist die einzeilige Kurzform des do ... end-Blocks aus dem ersten Beispiel.

Zwei Bausteine gehören noch zum Rüstzeug. Erstens: Tupel wie {:ok, wert} und {:error, grund} heißen Result-Tupel; fast jede Elixir-Bibliothek meldet Erfolg oder Misserfolg in dieser Form. Zweitens lassen sich Klauseln durch Guards verfeineren, Prüfbedingungen hinter dem Schlüsselwort when: def halbiere(x) when is_integer(x) greift nur für ganze Zahlen. Patterns, Klauseln und Guards ersetzen in Elixir einen großen Teil des klassischen Kontrollflusses. Und genau dieser Stil galt lange als Hindernis für ein klassisches Typsystem.

Vom dynamischen Liebling zum typisierten Werkzeug

Die Idee, Elixir ein Typsystem zu verpassen, ist alt. Bereits der aus der Erlang-Welt stammende Dialyzer, den Kostis Sagonas an der Universität Uppsala mitentwickelt hat, kann Elixir-Code analysieren. Seine Stärke, das sogenannte Success Typing, liegt darin, nur solche Fehler zu melden, die sich aus dem Code unzweifelhaft ergeben. Sein Potenzial entfaltet er allerdings erst, wenn Entwicklerinnen und Entwickler ihre Funktionen mit @spec-Annotationen versehen: von Hand geschriebene Typsignaturen, die zusätzlich zum eigentlichen Code gepflegt werden wollen und mit ihm auseinanderdriften können. Dazu kommen langsame Analysen, sperrige Integration und schwer entzifferbare Meldungen. In die breite Masse der Elixir-Entwickler hat es Dialyzer deshalb nie geschafft.

José Valim kündigte 2022 in seiner Keynote auf der ElixirConf EU an, dass die Sprache ein eigenes Typsystem bekommen werde, finanziert über ein Promotionsstipendium des französischen Forschungszentrums CNRS und des Unternehmens Remote. Die wissenschaftliche Grundlage lieferte der Informatiker Giuseppe Castagna (CNRS, Paris) mit seiner Arbeit zu set-theoretischen Typen, einem Formalismus, der Typen als Mengen begreift. Castagnas Doktorand Guillaume Duboc übernahm den Großteil der Implementierung, unterstützt durch Valim selbst; die Designprinzipien dokumentieren die drei in einem gemeinsamen Paper. Für eine Sprache, in der Pattern Matching ohnehin um die Form von Werten kreist, passte dieser Ansatz besser als klassische Typsysteme nach dem Vorbild von ML oder Haskell.

Die Entwicklung verlief in vier Etappen (Abbildung 1). Elixir 1.17 legte im Juni 2024 den Grundstein: erste Typen, abgeleitet aus den Patterns einer Funktion, erste Warnungen bei offensichtlichen Widersprüchen. Elixir 1.18 brachte im Dezember 2024 das Typchecking von Funktionsaufrufen, dazu eingebaute JSON-Unterstützung und Schnittstellen für die offizielle Language-Server-Initiative. Elixir 1.19 dehnte die Prüfungen im Oktober 2025 auf Protokolle und anonyme Funktionen aus und machte das Übersetzen großer Projekte bis zu viermal schneller. Version 1.20 schließt den Kreis: Der Compiler inferiert jetzt die Typen sämtlicher Sprachkonstrukte.

Den Rollout hat das Kernteam in einem öffentlichen Phasenplan organisiert, der die Inferenz in drei Phasen durch die Release Candidates trug (siehe Kasten). Alle drei stecken im stabilen Release, das Anfang Juni kurz nach dem ursprünglich angepeilten Mai-Termin erschien.

Zunehmender Tokenverbrauch und die Umstellung auf verbrauchsbasierte Abrechnungsmodelle werden laut Prognose der Marktforscher von Gartner Coding mit generativer KI zunehmend verteuern. 2028 dürften die Tokenkosten pro Entwickler dann laut Gartner den globalen Durchschnittslohn eines Entwicklers übersteigen. Die Prognose basiert auf einem weltweiten Mittelwert von rund 2.000 US-Dollar pro Monat – also deutlich unter dem, was man in Deutschland in der Branche verdient.

Gartner-Analyst Nitish Tyagi betonte auch, dass die Kosten natürlich nicht jedes Entwicklergehalt auf der Welt übersteigen würden – in den USA werde etwa deutlich besser bezahlt als in Indien. Laut Gartnerdaten würden aber schon sechs Prozent der Unternehmen Token-Kosten von über 2000 US-Dollar pro Entwickler pro Monat erreichen, was über dem typischen Gehalt indischer Entwickler mittlerer und höherer Erfahrungsstufen liege.

„Unternehmen gehen rasch von der Testphase zur groß angelegten Einführung von KI-Codingsagenten über, doch viele unterschätzen die finanziellen Auswirkungen des steigenden Token-Verbrauchs“, führte Tyagi weiter aus. Mehr Disziplin beim Tokenverbrauch werde aber nicht allein aus den Entscheidungen der Entwickler erwachsen. Die neigten Tyagis Ansicht nach eher zu Komfort und Schnelligkeit als zu Kosteneffizienz. Ohne ein geregeltes Betriebsmodell für die Entwicklung könnten die Kosten in den Unternehmen schneller steigen als die Produktivitätsgewinne, die KI-Tools erreichen sollen.

Kein ROI, nirgends?

„Führungskräfte im Bereich Softwareentwicklung sind zunehmend besorgt, da sich tokenbasierte KI-Ausgaben immer schwerer rechtfertigen lassen und Budgets oft früher als erwartet aufgebraucht sind“, sagte Tyagi. Unter anderem hatte im April der Uber-CTO Praveen Neppalli Naga mit der Aussage für Aufsehen gesorgt, dass das jährliche Token-Budget der Firma bereits aufgebraucht sei. Darauf legte Uber-Präsident Andrew Macdonald im Mai in einem Podcast nach, dass der Nutzen des KI-Einsatzes auch nicht klar sei. Ein Zuwachs an nützlichen Funktionen für Verbraucher habe sich nicht abgezeichnet. Ein ähnliches Bild zeigt sich auch in Deutschland, wo laut einer Bitkom-Umfrage rund ein Drittel der befragten Unternehmen von den Kosten ihres KI-Einsatzes überrascht worden ist.

Laut Gartner mangelt es bei den Anbietern auch an Transparenz bei der Berechnung und Abrechnung des Token-Verbrauchs. Integrierte Funktionen zur Kostenoptimierung in ihren KI-Codierungsagenten hätten die Anbieter ebenfalls noch nicht bereitgestellt. Das mache es den Unternehmen schwerer, Kosten genau zu prognostizieren und zu kontrollieren.

Transparenz und Steuerung fehlen

Hinzu komme ferner die mangelhafte Steuerung der Nutzung in den Unternehmen, die für übermäßige Ausgaben sorge. Als häufige Fehlerquellen nennt Gartner etwa unkontrollierte Autonomie in agentengesteuerten Arbeitsabläufen sowie überladene Kontextfenster. Insgesamt dürfte sich die Preisspirale noch weiter drehen, schätzt Tyagi ein: „Die Kosten für KI-Coding werden weiter steigen, da Infrastrukturinvestitionen und Herausforderungen bei der Rentabilität die Modellpreise in die Höhe treiben.“

Um die Kosten im Griff zu halten, empfehlen die Gartner-Analysten unter anderem Tokenschwellenwerte und automatisierte Überwachung einzuführen. Ebenfalls sollten Aufgaben für die KI möglichst segmentiert werden, damit sie auch von kleineren Modellen bewältigt werden können. Spitzenmodelle sollten lediglich für komplexe Aufgaben mit hoher Wertschöpfung zum Einsatz kommen. Ferner sollten Entwickler geschult werden, ihre KI-Prompts auf Sparsamkeit zu optimieren, indem sie nur relevante Informationen einbeziehen und Inhalte nach Möglichkeit zusammenfassen.

(axk)

Wie wirkt sich KI auf Teams aus? Mit Jasmine Simons-Zahno spricht Richard Seidl darüber, wie der zunehmende KI-Einsatz unser soziales Miteinander verändert: Kommunikation wird sachlicher, Vertrauen erodiert langsam, und das soziale Lernen, das gerade junge Menschen am Anfang ihrer Karriere brauchen, findet schlicht nicht mehr statt.

Jasmine Simons-Zahno erklärt, warum Reibung im Team kein Fehler ist, sondern eine Voraussetzung für Innovation, und warum der Allwissende in der Tasche uns gegenüber anderen glatter, aber nicht vertrauenswürdiger macht. Ihr Vorschlag klingt einfach, braucht aber echte Entscheidung: KI wie ein neues Teammitglied integrieren, also mit klaren Rollen, expliziten Vereinbarungen und dem Bewusstsein, dass dieser Aufwand kein Nice-to-have ist.

„Es gibt eine hohe Korrelation zwischen Vulnerabilität und Likeability.“ – Jasmine Simons-Zahno

Jasmine Simons-Zahno brennt für die menschliche Seite der Produktentwicklung. Sie coacht mit Leichtigkeit, Leidenschaft und Anspruch in Führungskontexten beliebiger Flughöhen in Unternehmen verschiedenster Größen. Ihre Stärke ist es, authentischer Spiegel für Menschen zu sein, die sich entwickeln dürfen, aber dem Ruf dazu gerade noch allzu gerne ausweichen möchten. Als Mitgründerin der Agile Growth, dreifache Mutter und ambitionierte Hobby-Köchin lässt sie nichts anbrennen.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, die die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)