Was wird die erste agentennative Programmiersprache sein?

Programmiersprachen wurden entworfen, damit Menschen Maschinen Anweisungen geben können.

Ihre Syntax trägt diese Geschichte in sich. Wir verwenden lesbare Variablennamen, einprägsame Schlüsselwörter, Einrückung, Kommentare, Dateien, Klassen und Abstraktionen, die zu menschlichen Denkmodellen passen. Compilerfehler sind für Menschen formuliert. Dokumentation ist für Menschen geordnet. Quell-Repositorien sind so aufgebaut, dass Menschen sich darin zurechtfinden.

Doch Menschen sind rasch immer weniger dafür zuständig, den eigentlichen Code zu schreiben.

Über Senternet, das Software-Studio, in dem ich Produkte baue und mit KI-gestützter Entwicklung experimentiere, entsteht ein Großteil meiner Software inzwischen dadurch, dass ich Coding-Agenten anleite. Ich beschreibe, was ich will, prüfe das Ergebnis, teste das Verhalten und schicke den Agenten zurück, um zu korrigieren, was nicht stimmt. Der Agent erzeugt weiterhin TypeScript, Python, SQL und anderen üblichen Quellcode, aber das fühlt sich zunehmend wie ein Überbleibsel des bestehenden Ökosystems an und nicht wie eine Anforderung der Arbeit.

Der Agent schreibt vor allem deshalb menschenlesbaren Code, weil unsere Compiler, Bibliotheken, Betriebssysteme, APIs, Paketmanager und Deployment-Infrastruktur ihn erwarten.

Daraus folgt eine Frage, die mich nicht loslässt:

Welche wird die erste Programmiersprache sein, die vorrangig für Agenten und nicht für Menschen entworfen ist?

Menschenlesbarer Code wird zum Zwischenformat

Fast die gesamte Computergeschichte hindurch hatte Quellcode zwei Zielgruppen.

Die erste war der Rechner, der ihn kompilieren oder interpretieren würde. Die zweite war jeder Mensch, der ihn später verstehen, debuggen, warten oder erweitern müsste.

Diese zweite Zielgruppe hat nahezu jede wichtige Entwurfsentscheidung bei Sprachen geprägt.

Python betont Lesbarkeit. Ruby will natürlich und ausdrucksstark wirken. TypeScript ergänzt Struktur, die großen Gruppen hilft, über JavaScript nachzudenken. Rust macht Besitz und Speichersicherheit explizit, damit Entwickelnde Verhalten verstehen und steuern können, das andere Sprachen verbergen würden.

Das sind wertvolle Eigenschaften, weil menschliche Aufmerksamkeit traditionell die knappe Ressource war.

Agentisches Programmieren verschiebt diese Ökonomie.

Ein Agent braucht keine Syntax, die leicht zu tippen ist. Er braucht keine Schlüsselwörter, die man sich gut merkt. Er braucht keine Sprache, die sich in einem Semester lehren oder in einem Bücherregal erklären lässt. Er ermüdet nicht, wenn er ein riesiges Repository durchquert. Er kann Darstellungen verarbeiten, die für einen Menschen mühsam, weitschweifig oder unverständlich wären.

Ihm nützen womöglich ganz andere Eigenschaften:

• eindeutige Semantik
• kompakte Token-Darstellung
• explizite Abhängigkeiten und Seiteneffekte
• deterministische Transformationen
• formale Verifikation
• automatische Parallelisierung
• maschinenlesbare Diagnosen
• eingebaute Herkunftsnachweise
• inkrementelle Kompilierung
• hardwarespezifische Optimierung
• die direkte Formulierung von Randbedingungen und Tests

Sobald Agenten die Hauptautoren von Software sind, ist menschliche Lesbarkeit nicht mehr die zentrale Entwurfsbedingung.

Sie wird nicht wertlos. Sie wird zu einer erzeugten Schnittstelle.

Die maschinennahe Darstellung könnte zur Quelle der Wahrheit werden, während Menschen jeweils die gerade nützlichste Ansicht erhalten: eine Erklärung, ein Diagramm, eine Verhaltensspezifikation, einen Sicherheitsbericht, einen Testplan oder auch erzeugtes TypeScript.

Menschenlesbarer Code ist am Ende vielleicht nicht grundlegender als die grafische Ansicht eines Datenbankschemas.

Warum Agenten weiterhin Python und TypeScript schreiben

Das größte Hindernis für jede neue Sprache ist nicht ihre Syntax.

Es ist das Ökosystem.

Eine neue Sprache braucht Compiler, Debugger, Bibliotheken, Dokumentation, Paketverwaltung, Editorunterstützung, Deployment-Werkzeuge, Sicherheitsanalyse und Zugang zu bestehenden Plattformen. Entwickelnde zögern, eine Sprache zu übernehmen, die sie alles neu bauen lässt, was sie schon haben.

Agenten beseitigen dieses Problem nicht, können es aber drastisch verkleinern.

Historisch musste eine neue Sprache außerdem Millionen Menschen davon überzeugen, sie zu lernen. Es brauchte Schulungen, Beispiele, Bücher, Community und genug Zuversicht, um Karrieren und Unternehmen auf unvertraute Technik zu setzen.

Ein Agent braucht keine monatelange Einarbeitung. Sobald ein Modell oder ein Coding-System eine Sprache zuverlässig erzeugen kann, hat jede Nutzerin dieses Systems sofort Zugang dazu.

Damit fällt eine der größten historischen Hürden für die Verbreitung von Sprachen weg.

Das Ökosystemproblem bleibt, was bedeutet: Die erste erfolgreiche agentennative Sprache wird Python, JavaScript, Rust und C++ vermutlich nicht auf einen Schlag ersetzen. Sie wird sie aufsaugen.

Sie mag über LLVM kompilieren, auf WebAssembly zielen, bestehende C-Schnittstellen aufrufen, heutige Pakete importieren und mit etablierten APIs sprechen. Sie mag als Zwischendarstellung unter einem Coding-Agenten beginnen und nicht als Sprache, die Entwickelnde bewusst auswählen.

Der Übergang könnte geschehen, ohne dass die meisten es bemerken.

Teile davon passieren bereits

Es gibt noch keine weit verbreitete, universelle Programmiersprache, die vorrangig von Agenten geschrieben und gelesen wird. Es gibt aber mehrere frühe Projekte, die in diese Richtung gehen.

Forschende stellten 2025 Quasar als Sprache für Code-Aktionen vor, die von Agenten auf Basis großer Sprachmodelle ausgeführt werden. Agenten erzeugen üblicherweise Python, wenn sie Werkzeuge aufrufen oder Kontrollfluss bauen müssen; die Forschenden argumentierten jedoch, dass Python die für diese Arbeit nötigen Eigenschaften bei Leistung, Sicherheit und Zuverlässigkeit fehlen.

Quasar ergänzt automatische Parallelisierung, Nachverfolgung von Unsicherheit und Mechanismen zur Prüfung potenziell unsicherer Aktionen. In der aktuellen Umsetzung schreibt das Modell eine eingeschränkte Teilmenge von Python, die nach Quasar transpiliert wird. Die Forschenden berichteten von 42 Prozent kürzerer Ausführungszeit, wo Parallelisierung möglich war, und von 52 Prozent weniger nötigen Freigabeinteraktionen, wo die Sicherheitsmechanismen griffen.

Quasar ist nicht die Endform einer agentennativen Sprache. Der Agent gibt weiterhin Python-ähnlichen Code aus. Aber der Druck wird deutlich: Eine für Menschen entworfene Sprache ist womöglich nicht das beste Ausführungsmodell für Agenten.

Pel ist eine weitere experimentelle Sprache, die eigens zur Orchestrierung von KI-Agenten entstand. Sie nutzt eine minimale Grammatik und betont eingeschränkte Generierung, Fähigkeitskontrolle, Kommunikation zwischen Agenten, sichere Ausführung und automatische Parallelisierung.

Pel ist von Sprachen wie Lisp, Elixir, Gleam und Haskell beeinflusst, doch ihr Entwurf setzt voraus, dass die leichte, zuverlässige Erzeugbarkeit durch ein Modell selbst ein Sprachmerkmal ist.

Das ist eine bedeutsame Verschiebung der Prioritäten. Klassische Sprachentwerfende fragen, ob die Syntax für einen Menschen verständlich ist. Entwerfende agentennativer Sprachen fragen vielleicht stattdessen, ob ein Modell sie konsistent erzeugen, mechanisch validieren und sich ohne menschliches Zutun von Fehlern erholen kann.

Coding-Agenten beginnen außerdem zu zeigen, dass sie unvertraute Sprachen nicht auf menschliche Weise lernen müssen.

In einer Studie von 2026 über Coding-Agenten im Umgang mit esoterischen Programmiersprachen schrieben führende Agenten häufig Python-Programme, die den unvertrauten Zielcode erzeugten und debuggten. Als die Forschenden diese Metaprogrammier-Strategie untersagten, brach die Leistung deutlich ein.

Das ist eine primitive, aber wichtige Form der Zukunft, die ich beschreibe.

Ein Agent kann eine Zieldarstellung erschließen, einen Generator dafür bauen, das Ergebnis testen und den Generator überarbeiten. Er muss den Zielcode im menschlichen Sinne weder verstehen noch pflegen. Die Zielsprache ist einfach eine weitere Maschinendarstellung, die er manipulieren kann.

Die erste agentennative Sprache sieht vielleicht nicht wie eine Sprache aus

Wenn Menschen sich eine neue Programmiersprache vorstellen, stellen sie sich meist eine neue Syntax vor.

Das ist womöglich der unwichtigste Teil.

Eine agentennative Sprache könnte eine strukturierte Darstellung sein von:

• gewünschtem Verhalten
• Schnittstellen
• Randbedingungen
• Berechtigungen
• Invarianten
• Tests
• Ressourcengrenzen
• Leistungszielen
• Sicherheitsrichtlinien
• akzeptablen Fehlermodi

Coding-Agent und Compiler könnten gemeinsam entscheiden, wie diese Anforderungen umzusetzen sind.

Für die eine Arbeitslast wäre das Ergebnis nativer Maschinencode. Für eine andere WebAssembly. Für eine weitere ein Datenbank-Abfrageplan, ein GPU-Kernel, eine Serverless-Funktion oder eine Komposition bestehender Dienste.

Womöglich gibt es gar keine dauerhafte Quelldatei, die der Implementierung entspricht.

Das bleibende Artefakt wären die Absicht und der Nachweis, dass die Implementierung sie erfüllt.

Das legt eine Entwicklung in drei Stufen nahe.

Stufe eins: Agenten schreiben menschliche Programmiersprachen

Hier stehen wir heute. Agenten erzeugen Code, der aussieht wie etwas, das eine menschliche Entwicklerin hätte schreiben können.

Stufe zwei: Agenten schreiben maschinenorientierte Zwischendarstellungen

Menschen prüfen vor allem Verhalten, Tests, Spezifikationen, erzeugte Erklärungen und Änderungen an Fähigkeiten. Die zugrunde liegende Implementierung wird für die Routineprüfung weniger wichtig.

Stufe drei: Agenten erzeugen ausführbare Systeme direkt

Die Quelle der Wahrheit wird eine Sammlung aus Absicht, Richtlinien, Schnittstellen, Randbedingungen und Verifikationsnachweisen. Der Agent erzeugt und erneuert ausführbare Implementierungen nach Bedarf.

An diesem Punkt ergibt die Frage, in welcher Programmiersprache eine Anwendung „geschrieben“ ist, womöglich kaum noch Sinn.

Menschenlesbar heißt nicht menschlich prüfbar

Das stärkste Argument gegen diese Zukunft lautet, dass Quellcode nicht nur zum Schreiben von Software dient.

Er dient auch dem Debuggen, dem Auditieren, der Governance, der Sicherheitsprüfung, der Wartung und der Rechenschaft.

Wir können wichtige Systeme, deren Verhalten niemand einsehen kann, nicht sicher betreiben.

Aber lesbarer Quellcode ist schon jetzt ein schwacher Ersatz für tatsächliches Verstehen. Eine große moderne Anwendung kann Millionen Zeilen eigenen Codes enthalten und über Pakete, generierte Dateien, Clouddienste, Betriebssysteme und Firmware von Millionen weiteren abhängen. Fast niemand versteht das ganze System.

Code kann lesbar sein, ohne dass das System begreifbar wäre.

Ein agentennatives System müsste stärkere Formen der Einsicht bieten als einen Haufen Quelldateien. Es könnte erzeugen:

• Erklärungen konkreter Verhaltensweisen
• Karten der Datenbewegung
• Beweise wichtiger Eigenschaften
• Berichte über Rechte und Fähigkeiten
• Historien von Abhängigkeiten
• Simulationen vorgeschlagener Änderungen
• ausführbare Tests
• Aufzeichnungen, warum jede Entscheidung so getroffen wurde
• menschenlesbare Implementierungen, wo nötig

Das Ziel sollte nicht sein, lesbaren Code um jeden Preis zu bewahren.

Das Ziel sollte sein, menschliche Kontrolle zu bewahren.

Das ist nicht dasselbe.

Die Umweltkosten menschenfreundlichen Codes

Es gibt noch einen Grund, warum Agenten die heutigen Programmiersprachen irgendwann hinter sich lassen könnten: Energie.

Eine viel zitierte Studie von 2017 zur Energieeffizienz von 27 Programmiersprachen verglich Laufzeit, Speicherbedarf und Energieverbrauch über zehn Benchmark-Aufgaben.

In den normalisierten Ergebnissen verbrauchte Python rund 76-mal so viel Energie wie C und benötigte etwa 72-mal so viel Ausführungszeit. Bei der Energieeffizienz lag Python nahe am Ende des Feldes.

Dieses Ergebnis wurde oft zu der Behauptung verkürzt, Python sei eine der umweltschädlichsten Programmiersprachen.

Die Wirklichkeit ist komplizierter.

Eine Neuauswertung der Energieeffizienz von Programmiersprachen aus dem Jahr 2024 ergab, dass solche Vergleiche die Sprache mit ihrer Implementierung, der Qualität des Benchmark-Programms, der Zahl aktiver Prozessorkerne, dem Verhalten von Bibliotheken, der Speicheraktivität und weiteren Ausführungsdetails vermischen können.

Nach Kontrolle dieser Faktoren kamen die Forschenden zu dem Schluss, dass die Implementierung der Programmiersprache über die Ausführungszeit hinaus keinen signifikanten Effekt auf den Energieverbrauch hatte.

Das Kernproblem war nicht, dass die Syntax einer Sprache irgendwie mehr Strom verbraucht. Langsamere Programme verbrauchten insgesamt mehr Energie, weil die Hardware länger aktiv blieb.

Diese Unterscheidung lässt das Problem nicht verschwinden.

Standard-Python ist bei rechenintensiver Arbeit oft deutlich langsamer als optimierter kompilierter Code. Ein Programm, das für dieselbe Aufgabe dramatisch länger braucht, kann dramatisch mehr Energie verbrauchen, selbst wenn der Prozessor währenddessen ähnlich viel Leistung zieht.

Die gute Nachricht ist, dass diese Ineffizienz nicht unvermeidlich ist.

Eine Studie von 2025 zu kompilierten Python-Implementierungen verglich CPython mit mehreren Kompilierungs- und Optimierungssystemen, darunter PyPy, Numba, Codon, Cython, Nuitka, Mypyc und Pyston-lite.

Die Forschenden stellten fest, dass Kompilierung Ausführungszeit, Speicherbedarf und Energieverbrauch deutlich verbessern kann. Codon, PyPy und Numba erzielten bei einigen der getesteten Arbeitslasten Verbesserungen von über 90 Prozent bei Geschwindigkeit und Energie.

Der genauere Schluss lautet nicht, dass Python von Natur aus umweltzerstörend sei.

Er lautet, dass Menschen Programmiersprachen oft nach menschlicher Produktivität ausgewählt und Ausführungseffizienz als zweitrangig behandelt haben.

Python ist erfolgreich, weil es lesbar, ausdrucksstark und nachsichtig ist und von einem enormen Ökosystem getragen wird. In vielen Organisationen ist es die zusätzliche Rechenzeit wert, Entwicklerzeit zu sparen.

Agenten stehen nicht vor derselben Abwägung.

Ein Coding-Agent braucht keine freundliche Syntax, um produktiv zu bleiben. Er braucht keine Sprache, die leicht zu lehren, zu tippen oder zu merken ist. Er könnte eine für die konkrete Arbeitslast gewählte Darstellung erzeugen, sie für die vorhandene Hardware kompilieren, das Ergebnis messen und sie ersetzen, sobald eine effizientere Implementierung verfügbar ist.

Energieverbrauch könnte zu einer erstklassigen Eigenschaft des Programmierens werden statt zu einer Optimierung, die man versucht, wenn die Software längst geschrieben ist.

Das zählt, weil Agenten menschlich geschriebenen Code nicht einfach Zeile für Zeile ersetzen werden. Sie dürften die Gesamtmenge erzeugter und ausgeführter Software erhöhen.

Agenten können Dutzende Implementierungen erzeugen, Tausende Tests laufen lassen, Wegwerfprogramme für einzelne Aufgaben schreiben und funktionierende Systeme fortlaufend neu erzeugen. Ineffizienz, die erträglich war, solange Software langsam von Menschen entstand, wiegt schwerer, wenn Maschinen nahezu unbegrenzt Code erzeugen können.

Die erste agentennative Sprache könnte daher mehr optimieren als Korrektheit und Geschwindigkeit. Sie könnte berücksichtigen:

• den gesamten Energieverbrauch
• die erwartete Ausführungshäufigkeit
• verfügbare Prozessoren und Beschleuniger
• Speicherbewegungen
• die Kompilierkosten
• die Kohlenstoffintensität des verfügbaren Stroms
• ob sich eine Last verschieben oder verlagern lässt
• ob eine Implementierung einmal oder milliardenfach läuft

Womöglich gibt es keine universell optimale Darstellung.

Eine einmalige Datenkonvertierung spricht für minimalen Kompilieraufwand. Ein Dienst, der Milliarden Anfragen bedienen soll, rechtfertigt aggressive native Optimierung. Eine Last auf einem batteriebetriebenen Gerät stellt Energie über Latenz. Ein Job im Rechenzentrum ließe sich nach der Verfügbarkeit kohlenstoffärmeren Stroms einplanen.

Ein Agent könnte solche Entscheidungen automatisch treffen.

Vielleicht bestünde der Umweltfehler nicht darin, Agenten unlesbaren Code schreiben zu lassen. Er bestünde darin, sie weiter Python schreiben zu lassen, bloß weil Menschen es gern lesen.

Was wird aus der Programmiererin?

Nichts davon bedeutet, dass Menschen aufhören, Software zu bauen.

Es bedeutet, dass unsere Arbeit nach oben rückt.

Statt den Großteil der Zeit damit zu verbringen, Implementierungsschritte in einer für Compiler entworfenen Syntax zu beschreiben, werden wir mehr Zeit damit verbringen, zu definieren:

• was das System leisten soll
• was es niemals tun darf
• welche Kompromisse akzeptabel sind
• wer worauf zugreifen darf
• wie Erfolg gemessen wird
• wie mit Fehlern umzugehen ist
• welche Nachweise vor dem Ausrollen nötig sind

Das ist immer noch Programmieren.

In vieler Hinsicht ist es unmittelbarer Programmieren, als diese Entscheidungen von Hand in Schleifen, Klassen, Funktionen und Konfigurationsdateien zu übersetzen.

Die Rolle der Programmiererin dreht sich weniger um das Erzeugen von Quellcode als um das Festlegen von Absicht, Randbedingungen, Architektur und Urteilsvermögen. Das ist ein weiterer Grund, warum ich immer wieder auf den Gedanken zurückkomme, dass Geschmack der Engpass ist, sobald das Bauen selbst billig wird.

Das Schwierige an der Softwareentwicklung war nie das Tippen der Syntax. Das Schwierige war zu entscheiden, was geschehen soll.

Agenten entfernen die Übersetzungsschicht.

Wer wird sie erschaffen?

Die erste wirklich agentennative Sprache wird womöglich nicht auf einer Entwicklerkonferenz vorgestellt.

Sie hat vielleicht keinen cleveren Namen, keine öffentliche Spezifikation und keine Community, die über ihre Syntax streitet.

Sie könnte still im Inneren einer Agentenplattform entstehen, als private Zwischendarstellung zum Planen, Erzeugen, Verifizieren, Optimieren und Kompilieren von Software. Sie könnte anfangs herkömmliche Sprachen und bestehende Toolchains anvisieren und dann nach und nach mehr davon umgehen.

Bis Menschen sie als Programmiersprache erkennen, schreiben Agenten damit vielleicht schon einen erheblichen Teil der Software dieser Welt.

Gewinnen wird nicht zwangsläufig die Sprache, die Menschen am liebsten lesen.

Es wird die Darstellung sein, mit der Agenten die zuverlässigsten, sichersten, effizientesten und überprüfbarsten Systeme hervorbringen können, ohne den Menschen die tatsächliche Kontrolle über das Ergebnis zu nehmen.

Programmiersprachen wurden erfunden, damit Menschen Computern sagen können, was sie tun sollen.

Die nächste wird vielleicht erfunden, damit Computer es sich selbst sagen können.