Agent-First-Design: Warum Zero existiert und was es eintauscht

Die Frage, die Zero stellt

Die Prämisse hinter Zero ist einfach: Wenn ein KI-Agent – nicht nur ein Mensch – Code liest, schreibt und repariert, wie soll dann die Sprache selbst aussehen?

Existierende Sprachen wurden lange entworfen, bevor Agenten Code schreiben konnten. Ihre Prioritäten – knappe Syntax, ausdrucksstarke Idiome, Bibliotheks-Cleverness – ergeben Sinn für Menschen, die in Editoren tippen. Sie tolerieren Mehrdeutigkeit und implizite Konvertierungen, weil Menschen gut darin sind, Lücken zu füllen. Agenten nicht. Sie generieren exakten Text aus Wahrscheinlichkeitsverteilungen, und sie bezahlen jede unscharfe Kante der Sprache mit einem falschen Token irgendwo weiter unten.

Zero fängt von vorn an, die Einschränkung umgedreht: für Agenten entwerfen, akzeptieren, dass Menschen den Code immer noch lesen werden, und schauen, was dabei herauskommt.

Prinzip 1: Eine kleine, reguläre Oberfläche

Die meisten Programmiersprachen wachsen mit der Zeit. Jedes neue Release ergänzt eine kleine Bequemlichkeit – einen neuen Operator, eine neue syntaktische Form, einen neuen Weg, etwas auszudrücken, was die Sprache schon konnte. Jede Ergänzung zahlt sich in menschlicher Ergonomie aus. Jede Ergänzung kostet einen Agenten: noch eine Variante zu lernen, noch ein Weg, falsch zu liegen.

Zero hält die Oberfläche bewusst winzig:

• Eine Binding-Form (let).
• Eine Funktionsform (fun, optional pub).
• Eine Schleife heute (while).
• Einen Weg, Produkttypen zu modellieren (shape).
• Einen Weg, Summentypen mit Payloads zu modellieren (choice).
• Einen Weg, beschriftete Summen zu modellieren (enum).
• Ein Pattern-Matching-Konstrukt (match).

Kein Operator-Overloading, keine Decorators, keine Makros, keine impliziten Konvertierungen, keine Wahrheits-Koerzion, kein Ternär. Jede Abwesenheit ist ein Feature: Sie entfernt einen Ort, an dem ein Agent die falsche Variante wählen könnte.

Der Preis ist offensichtlich – weniger Bequemlichkeits-Features. Der Nutzen ist, dass ein Agent, der während einer Sitzung Zero lernt, auf die richtige Syntax konvergieren kann, ohne sieben Beinahe-Äquivalente abwägen zu müssen.

Prinzip 2: Explizite Effekte

Die meisten Sprachen lassen jede Funktion an jeder Stelle I/O machen. console.log in JavaScript, printf in C, print in Python. Die Signatur der Funktion gibt keinen Hinweis darauf, ob sie in eine Datei schreiben oder ins Netzwerk gehen könnte. Der einzige Weg, es zu wissen, ist, den Body zu lesen, rekursiv.

Zero nimmt die gegenteilige Position ein: Jeder Effekt, den eine Funktion hat, taucht in ihrer Signatur auf.

• I/O ist durch die World-Capability gesperrt. Eine Funktion, die kein World nimmt, kann keine I/O machen. Das Typsystem erzwingt das.
• Fehler sind durch raises und check gesperrt. Eine Funktion, die fehlschlagen kann, sagt das in ihrer Signatur. Jeder Aufrufer bestätigt es mit check oder einem anderen expliziten Konstrukt.

Allein aus der Signatur einer Funktion kannst du zwei Fragen beantworten, die ein Agent (oder ein statischer Analyzer oder ein menschlicher Reviewer) tief interessieren:

• „Könnte das die Außenwelt berühren?" – ja genau dann, wenn World auftaucht.
• „Könnte das fehlschlagen?" – ja genau dann, wenn raises auftaucht.

Diese Eigenschaft existiert in Mainstream-Sprachen nicht, und sie ist keine kleine.

Der Preis ist Parameter-Plumbing. Der World-Wert wird überallhin gereicht, wo I/O nötig ist; die raises-Klausel wiederholt sich, wo Fehler fließen. Zero akzeptiert das als Preis für die Eigenschaft.

Prinzip 3: Deterministisches Tooling

Das dritte Prinzip ist das, was am direktesten auf Agenten zielt: Jede Ausgabe, die der Compiler produziert, ist strukturierte Daten.

JSON-Diagnostik ist das Schlagzeilen-Beispiel:

{
    "code": "NAM003",
    "message": "unknown identifier",
    "line": 3,
    "repair": { "id": "declare-missing-symbol" }
}

Drei Eigenschaften unterscheiden das von einer normalen Compiler-Fehlermeldung:

1. Stabile Codes. NAM003 heißt heute und morgen dasselbe, egal wie die menschen-orientierte Meldung formuliert ist.
2. Strukturierte Repair-Pläne. Wenn der Compiler glaubt zu wissen, wie eine Diagnostik zu fixen ist, gibt er einen Plan als Daten aus – eine Edit-Liste, keinen englischen Vorschlag.
3. Mehrere strukturierte Kanäle. Diagnostik, Abhängigkeitsgraphen, Size-Reports und Erklärungen leben alle hinter --json-Modi.

Der ganze Sinn ist, dass ein Tool – Agent oder anders – nie Englisch parsen muss, um auf Compiler-Ausgabe zu reagieren. Einen stabilen Code nachschlagen ist exakt; Prosa parsen ist unscharf. Zero behandelt Ersteres als Vertrag und Letzteres als Bequemlichkeit für Menschen.

Prinzip 4: Eine Bibliothek, die in der Sprache lebt

Agenten sind gut darin, Code zu schreiben, der existierenden Mustern folgt. Sie sind schlechter darin, die richtige externe Abhängigkeit aus einem Meer von Optionen auszuwählen, sie richtig zu integrieren und nachzuverfolgen, wenn ihre API driftet. Jede externe Abhängigkeit ist Reibung.

Zeros Design schiebt Capabilities in die Standardbibliothek – explizit dokumentiert, kohärent und stabil, sobald die Sprache sich stabilisiert. Das Ziel ist, dass ein Zero-Programm für Routineaufgaben selten außerhalb der Standardverteilung greifen muss. Das hält die Oberfläche, über die ein Agent reasonieren muss, eingegrenzt.

Das ist eher eine Aspiration als ein fertiger Zustand heute. Die pre-1.0-Standardbibliothek ist real, wächst aber noch. Das Prinzip gibt die Richtung an, nicht das Ziel.

Was Zero eintauscht

Jede Designentscheidung kostet etwas. Ehrliche Trade-offs, die Zero eingeht:

• Wortreichtum statt Knappheit. Reine Funktionen brauchen kein World. I/O-fähige Funktionen schon. Fehler tauchen in Signaturen auf. Das Resultat sind mehr Annotationen als in einer JavaScript- oder Python-Entsprechung.
• Explizit statt magisch. Keine reflektierende Metaprogrammierung, keine Decorators, die still Verhalten verpacken, keine impliziten Globals. Dinge, die in dynamischen Sprachen so aussehen, als „funktionierten sie einfach", müssen von Hand verdrahtet werden.
• Statisch statt dynamisch. Typen sind an Parametern, Rückgabewerten und Shape-Feldern erforderlich. Der Compiler erledigt viel Arbeit; der Preis ist, dass jede Signatur etwas ist, das Autor (oder Generator) schreiben muss.
• Stabilität statt Änderungstempo. Die Sprache ist pre-1.0 und ändert sich schnell, aber die Designabsicht ist, die Oberfläche festzunageln, sobald sie sich gesetzt hat. Der Preis ist, dass es später schwerer wird, ein cleveres neues Bequemlichkeits-Feature zu ergänzen, weil die Latte für Ergänzungen lautet: „hilft das einem Agenten mehr, als es ihn kostet?"

Ob die Trades sich lohnen, hängt davon ab, wofür du optimierst. Bist du ein Mensch, der ein einmaliges Skript schreibt, ist die Reibung real und die Agent-Vorteile abstrakt. Betreibst du einen Agenten, der tausende kleiner Programme pro Tag produziert, zahlt sich die Reibung vielfach aus.

Was Zero nicht zu sein versucht

Ein paar negative Aussagen sind es wert, explizit gemacht zu werden:

• Nicht „die Zukunft aller Programmierung." Zero ist eine Hypothese, kein Manifest. Die Hypothese ist, dass Agent-first-Beschränkungen eine nützliche Sprache erzeugen. Ob Mainstream-Sprachen diese Beschränkungen übernehmen sollten, ist eine separate, längere Diskussion.
• Kein Feature der Vercel-Deployment-Plattform. Obwohl Zero von Vercel Labs kommt, ist es nicht an Next.js oder Vercel-Hosting gebunden. Es ist eine eigenständige Systems-Sprache.
• Kein Ersatz für Rust, Go oder Zig in Produktion. Pre-1.0. Experimentell. Nutze es zum Lernen und für Feedback; liefere noch keine Kundensoftware damit aus.
• Nicht fertig. Teile der Standardbibliothek, Syntax für Mutability, Fehlerbehandlungsformen und Constraints für Generics können sich vor 1.0 noch bewegen.

Was interessant ist, auch wenn du es nicht verwendest

Selbst wenn du nie eine Zeile Zero schreibst, ist das Experiment aufschlussreich:

• Es ist das klarste Beispiel eines echten, funktionierenden, Capability-basierten Effekt-Systems in einer kleinen Systems-Sprache. Das mentale Modell – die Erlaubnis übergeben, den Effekt in der Signatur sehen – ist portabel.
• Die Diagnostik-Geschichte ist das, was jeder Compiler in den letzten zehn Jahren hätte tun sollen. Strukturierte Ausgabe schlägt Prosa jedes Mal, und Zeros Verpflichtung zu stabilen Codes ist etwas, das andere Tools ohne Sprachänderungen übernehmen könnten.
• Das Prinzip „ein Weg für jedes Ding, bewusst kleine Oberfläche" läuft gegen den Strom des Sprachdesigns, wie es üblicherweise praktiziert wird. Zu beobachten, wo dieses Prinzip hilft und wo es kneift, ist unabhängig davon nützlich, in welcher Sprache du morgen schreibst.

Wo es als Nächstes weitergeht

Wenn du den Rest dieser Doku durchhast, sind die nützlichsten nächsten Lesestoffe extern:

• Das Zero-Repository auf github.com/vercel-labs/zero – Beispiele, Quellcode und AGENTS.md für die eigene Absichtserklärung der Maintainer.
• Die offizielle Seite auf zerolang.ai – Getting-Started-Anweisungen und die kanonische Einführung.

Beide entwickeln sich weiter. Was du dort findest, wird aktueller sein als jedes Drittanbieter-Tutorial. Die Prinzipien in diesem Dokument sind der langsam-bewegliche Teil; die Syntax drumherum wird sich bewegen, während sich die Sprache setzt.