Warum die Ausführung im Heredoc-Stil für KI-Agenten im Jahr 2026 besser geeignet ist als eine REPL

Frühe Coding-Agenten zeigten etwas überraschend Mächtiges: Gibt man einem Agenten Zugriff auf Bash, kann er fast alles – Code schreiben, Kontext sammeln, ganze Git-Workflows verwalten.

Diese Erkenntnis hat eine breitere Bewegung hin zu CLI-first-Software befeuert. Kommandozeilen-Schnittstellen galten zunehmend als Standardweg, um komplexe Anwendungen für KI-Agenten zugänglich zu machen – daraus entstand ein bekannter Slogan:

CLI ist alles, was Sie brauchen.

Aber es gibt versteckte Kosten. Agenten nutzen ein Terminal oft wie ein Mensch: kurzen Befehl ausführen, Ergebnis prüfen, dann entscheiden, was als Nächstes kommt. Je komplexer die Aufgabe, desto mehr Hin und Her zwischen Modell und Tools – und das bedeutet mehr LLM-Aufrufe, mehr verschwendeten Kontext und mehr Wartezeit.

Statt Agenten komplizierte Shell-Skripte zusammenbauen zu lassen, sollen sie Aufgaben lieber in einer Programmiersprache koordinieren, die sie schon kennen. Daraus ergibt sich eine leicht andere Architektur:

Die CLI bleibt der universelle Einstiegspunkt, aber Code ist der eigentliche Weg, mit der Software zu interagieren.

Der Agent übergibt einen Codeblock mit allen Operationen, Entscheidungen und Datenverarbeitungsschritten, die sonst auf mehrere Interaktionsrunden verteilt wären. Die lokale Laufzeit führt den Workflow dann aus.

ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and orchestrieren sie.

In diesem Artikel vergleichen wir Heredoc und REPL, zwei Arten, Code über eine CLI auszuführen, und zeigen die Ergebnisse aus ego-browser. Mit Heredoc erledigte der Agent dieselben Aufgaben in 44 % weniger Ausführungsrunden, mit 35,5 % weniger Tool-Aufrufen und zu 21,6 % geringeren Kosten.

„CLI ist alles, was Sie brauchen“ – was dann?

Die Behauptung „CLI ist alles, was Sie brauchen“ setzt voraus, dass das Modell die CLI bereits kennt.

Bei bekannten Tools wie Git, Docker oder FFmpeg ist das meist kein Problem: Modelle haben im Training unzählige Befehle, Tutorials, Skripte und Fehlermeldungen gesehen und kennen Argumente und Zusammenspiel der Befehle bereits.

Bauen wir aber eine brandneue CLI für Agenten, ändert sich das Bild. Jede CLI hat eigene Unterbefehle, Argumente, Ausgabeformate und Fehlerlogik. Für das Modell ist das im Grunde eine neue Mini-Sprache. Selbst mit vollständiger Dokumentation muss das Modell erst die Regeln lernen und dann durch wiederholte Aufrufe herausfinden, wie die Befehle zusammenspielen.

Stellt man dieselben Funktionen stattdessen als JavaScript-API oder API in einer anderen Sprache bereit, muss das Modell zwar noch die neuen Fachkonzepte lernen, aber nicht mehr Kontrollfluss, Datenstrukturen oder Komposition neu erlernen. Schleifen, Bedingungen, Fehlerbehandlung und Datenverarbeitung bleiben in einer Programmiersprache, die es bereits beherrscht.

Nehmen wir eine einfache Aufgabe: eine Webseite öffnen und die Hauptüberschrift lesen. Hätte ego-browser eine klassische, befehlsbasierte Schnittstelle, bräuchte der Agent dafür mehrere Schritte:

# First call: open the page
ego-browser open https://example.com

# Tool response: the page is open

# Second call: locate the main heading
ego-browser find --role heading

# Tool response: a heading was found

# Third call: read the heading
ego-browser read --role heading

Nach jedem Schritt wartet der Agent auf das Tool, liest das Ergebnis und entscheidet, was als nächstes zu tun ist.

Die Code-Schnittstelle, die ego-browser tatsächlich nutzt, erlaubt es, den gesamten Workflow auf einmal auszudrücken:

await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);

Beide Ansätze erledigen dieselbe Aufgabe. Die befehlsbasierte Schnittstelle zerlegt den Ablauf in mehrere Runden aus Modell-Tool-Interaktion; die Code-Schnittstelle lässt den Agenten den kompletten Ablauf einmal ausschreiben und an die lokale Laufzeit übergeben.

Genau das ist die eingangs erwähnte Idee: Die CLI bleibt der universelle Einstiegspunkt, Code wird aber zur eigentlichen Schnittstelle zur Software. So bleibt der Vorteil der CLI erhalten – leicht aufrufbar und zu integrieren – während das Modell seine vorhandenen Programmierfähigkeiten für Komposition und Orchestrierung einsetzen kann.

Wenn die CLI zum Einstiegspunkt für Code wird

Sobald eine CLI Code entgegennimmt, stellt sich die nächste Frage: Wie übergibt der Agent diesen Code an die Ausführungsumgebung?

Streng genommen ist Heredoc eine Shell-Eingabesyntax und REPL ein Ausführungsmodus des Interpreters – beide liegen nicht auf derselben Abstraktionsebene. Dieser Artikel vergleicht eigentlich die einmalige Codeausführung per Heredoc in ego-browser mit einer dauerhaften, interaktiven Sitzung auf Basis einer REPL. Der Kürze halber nennen wir sie im Folgenden einfach Heredoc und REPL.

Eine Option ist der Heredoc. In ego-browser übergibt der Agent dabei einen kompletten JavaScript-Block auf einen Schlag:

ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOF

Die Shell übergibt den Code an ego-browser, wartet auf dessen Abschluss, empfängt das Ergebnis und wird beendet. Für den Agenten verhält sich dies wie ein herkömmlicher Tool-Aufruf:

Submit command → wait for process → receive result

Eine REPL funktioniert anders: Der Interpreter bleibt am Leben, sodass der Agent wiederholt Code eingeben kann, während Variablen und Sitzungsstatus erhalten bleiben:

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

Ausdrucksstärke betrachtet sind beide praktisch gleichwertig: Eine REPL kann ein komplettes Programm mit Schleifen, Bedingungen und Fehlerbehandlung in einem Rutsch ausführen, und ein Heredoc kann genauso gut nur eine einzige Zeile übermitteln.

Der klare Unterschied liegt im Lebenszyklus des Prozesses: Bei einem Heredoc endet der Prozess, sobald der Code fertig ist; eine REPL hält den Interpreter-Prozess am Leben und wartet auf weitere Eingaben. Das stellt auch unterschiedliche Anforderungen an die Agent-Tools. Ein Heredoc läuft direkt nach dem bekannten Anfrage-Antwort-Modell:

submit the command → wait for the process to exit → get the result

Eine REPL verlangt dem Tool mehr ab: dauerhafte Prozesse, Sitzungsverwaltung, kontinuierliche Eingabe, Unterbrechung und Wiederherstellung. Die eingebauten Bash-Tools der meisten Agenten können das nicht. Unter den gängigen Produkten heute unterstützt das nur Codex einigermaßen gut. Und Tool-Unterstützung ist nur die Voraussetzung, um eine REPL überhaupt nutzen zu können – sie entscheidet nicht, wie das Modell sie tatsächlich einsetzt. Selbst wenn beide Umgebungen denselben Code ausführen können, schreibt das Modell den Code darin oft unterschiedlich.

Wie Modelle Code in jeder Umgebung schreiben

Theoretisch hat ein Modell in beiden Umgebungen dieselben Programmierfähigkeiten. In der Praxis haben wir aber einen durchgängigen Verhaltensunterschied beobachtet:

• In einer REPL neigt das Modell dazu, Code schrittweise einzugeben.
• In einem Heredoc generiert es eher ein vollständiges Programm auf einmal.

Software für Menschen muss Ergonomie mitdenken. Software für Agenten braucht dieselbe Disziplin – nennen wir es Model-Experience-Engineering. Eine Schnittstelle sollte zu den Verhaltensmustern passen, die Modelle im Training gelernt haben.

Der Unterschied zwischen REPL und Heredoc spiegelt die Verteilung ihrer Trainingsdaten wider.

REPL-Beispiele stammen meist aus Tutorials, Debugging-Sitzungen und Frage-Antwort-Austauschen. Ihr typisches Muster ist explorativ:

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Heredoc-Codeblöcke sehen eher aus wie Skripte oder Quelldateien. Sie haben klare Anfangs- und Endgrenzen, was das Modell zu einem durchgängigen Workflow ermutigt:

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

Das heißt nicht, dass eine REPL keine vollständigen Programme ausführen kann. Das Modell könnte denselben Codeblock auch in einem Schritt an eine REPL übergeben.

Der Unterschied liegt im Kontext. Eine REPL begünstigt ein ausführen, beobachten, weitermachen Muster. Ein Heredoc begünstigt ein erst organisieren, dann ausführen Muster.

Diese Tendenz bestimmt auch, wo der Kontrollfluss liegt. In einer REPL teilt das Modell die Aufgabe eher in mehrere Etappen auf und entscheidet nach jedem Ergebnis neu. In einem Heredoc packt es Schleifen, Bedingungen, Filterung und Datenverarbeitung eher direkt ins Programm und überlässt die Ausführung der lokalen Laufzeit.

Was die Experimente zeigten

Von den gängigen Agent-Tools, die sich zuverlässig integrieren ließen, bot nur Codex die Ausführungsfähigkeiten, die eine dauerhafte REPL braucht. Also haben wir einen automatisierten Benchmark auf Basis des Codex SDK gebaut: Derselbe Agent hat vier Arten realer Browseraufgaben sowohl über REPL als auch über Heredoc gelöst, und wir haben die Ergebnisse aus mehreren Durchläufen zum Vergleich zusammengefasst.

Die Aufgaben waren:

• X trending-post analysis (a typical social media scraping workload): Die Original-Posts von OpenAI der letzten sieben Tage sammeln, angepinnte Posts, Reposts und Antworten ausschließen, die Top 5 nach Aufrufen ranken und deren Engagement-Raten sowie den Gesamtdurchschnitt berechnen.
• OpenAI-Bewerbung: Die passende Cloud-Infrastructure-Stelle in San Francisco finden, einen Lebenslauf hochladen, das Bewerbungsformular ausfüllen und vor dem endgültigen Absenden stoppen.
• Redfin-Hypothekenberechnung: Immobilien in Austin nach Haustyp und Preis filtern, das erste Ergebnis nach dem Sortieren öffnen, die Anzahlung auf 20 % ändern und die aktualisierte geschätzte monatliche Rate abrufen.
• Expedia-Flugsuche: Einen einfachen Nonstop-Flug von JFK nach MIA finden, die günstigste Option einer bestimmten Airline auswählen, die Passagierdaten eingeben und vor der Zahlung stoppen.

These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.

Beide Ansätze schlossen die meisten Aufgaben erfolgreich ab. Heredoc erreichte eine Erfolgsquote von 77,5 %, REPL 75,0 % – der Unterschied bei der Zuverlässigkeit war gering.

Der größere Unterschied lag bei der Effizienz:

• Die durchschnittliche Ausführungszeit sank um 35.0%.
• Die mittlere Ausführungszeit sank um 30.7%.
• Die Tool-Aufrufe sanken um 35.5%.
• Der Tokenverbrauch sank um 29.8%.
• Die durchschnittlichen Kosten sanken um 21.6%.

Eine REPL kann zwar den Laufzeitstatus wiederverwenden, aber dieser Vorteil führte nicht zu weniger Interaktionen. In der Praxis brauchte der Heredoc-Agent weniger Tool-Aufrufe.

Die Ergebnisse bestätigten unsere früheren Beobachtungen. In der REPL führte der Agent oft ein kleines Codestück aus, prüfte das Ergebnis und entschied dann über den nächsten Schritt. Schleifen, Filter und Entscheidungen, die in einem einzigen Programm hätten stecken können, verteilten sich stattdessen über mehrere Model-Tool-Austausche.

Beide Umgebungen bieten ähnliche Ausdrucksstärke. Der Effizienzunterschied liegt vor allem daran, wie ihre Interaktionsmuster das Agentenverhalten prägen. Zumindest bei diesen vier Browser-Agent-Aufgaben brachte Heredoc das Modell durchgängiger dazu, ein vollständiges Programm zu schreiben, Schleifen, Filterung und Entscheidungen in den Code zu packen und die zusätzlichen Runden schrittweiser Entscheidungen zu vermeiden.

Wir haben außerdem geprüft, ob sich dasselbe Muster auch in größerem Maßstab zeigt, und dazu ego-browser mit einem vergleichbaren REPL-basierten Browser-Automatisierungsprodukt im Odysseys-Datensatz verglichen. Anders als im kontrollierten Experiment oben ging es hier um zwei vollständige Produkte, nicht um dasselbe Modell über zwei Schnittstellen. Der Vergleich taugt daher als grober Effizienzvergleich, die Unterschiede lassen sich aber nicht allein auf Heredoc gegenüber REPL zurückführen.

Das ist kein endgültiger Sieg für Heredoc

Wir glauben nicht, dass Heredoc einer REPL grundsätzlich überlegen ist.

Unser Fazit hängt von den Fähigkeiten der Modelle, der Verteilung ihrer Trainingsdaten und dem Design der Agent-Tools ab, so wie sie 2026 existieren.

Heutige Agenten sind generell besser darin, einen kompletten Codeblock auf einmal zu erzeugen. Ihre Shell-Tools sind zudem auf einen einfachen Lebenszyklus ausgelegt: Befehl absetzen, auf Abschluss warten, Ergebnis zurückgeben. Unter diesen Bedingungen macht es Heredoc leichter, Interaktionsrunden zu reduzieren und den Kontrollfluss in lokal ausgeführten Code zu verlagern.

Diese Voraussetzungen können sich schnell ändern.

Künftige Agent-Tools bieten vielleicht zuverlässige dauerhafte Sitzungen, strukturierte Ausgaben und robuste Zustandswiederherstellung. Agenten müssten sich dann nicht mehr selbst um REPL-Prompts, Prozessstatus und unterbrochene Sitzungen kümmern. Gezieltes Training könnte Modellen auch beibringen, von sich aus vollständige Programme in einer REPL einzureichen, statt in unnötige Schritt-für-Schritt-Interaktion zu verfallen.

Dann könnten REPLs die Vorteile der Zustandswiederverwendung und des direkten Feedbacks behalten, ohne mehr Modellaufrufe zu brauchen. Für Aufgaben mit teurer Initialisierung, langlebigem Zustand oder wirklich explorativem Ablauf könnten sie sogar die bessere Wahl sein.

Deshalb steht im Titel ausdrücklich 2026. Wir behaupten nicht, ein für alle Zeiten gültiges Gesetz entdeckt zu haben – das ist eine Momentaufnahme, basierend auf den heute verfügbaren Modellen und Agent-Tools.