Zeroshot: Der Agent, der den Code schreibt, genehmigt ihn nie. Unabhängiges Review und begrenzte Reparatur

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Zeroshot verwandelt ein Softwareziel in einen expliziten Multi-Agenten-Graphen: Ein Agent implementiert, unabhängige Agenten prüfen, Fehlschläge gehen in eine begrenzte Reparaturschleife, und nichts wird ausgeliefert, bevor alle Prüfungen bestehen. Der Implementierer genehmigt nie seine eigene Arbeit. Das Werkzeug ersetzt weder Claude Code noch Codex oder Copilot, sondern führt eines davon als Worker und als Reviewer aus. Man kann eine eigene Topologie mitbringen und als Profil speichern. Version 8 nutzt eine native Binärdatei, die über npm verteilt wird. Läuft lokal, nutzt die bestehende Anmeldung des gewählten Harness. Das README nennt keine Benchmarks, der Nutzen stützt sich daher derzeit auf die Entwurfslogik und nicht auf Messwerte.

Das Problem

Der häufigste Fehler von KI-Coding-Agenten ist nicht, dass sie keinen Code schreiben können. Sie schreiben ihn und erklären dann selbst, die Arbeit sei fertig.

Wenn dasselbe Modell Code schreibt und abnimmt, bewertet es seine eigene Prüfung. Zeroshot beruht auf einer einzigen Aussage: Der Agent, der den Code schreibt, soll nicht derjenige sein, der entscheidet, ob er funktioniert. Das Team sagt, es habe das Werkzeug gebaut, weil es leid war, von Agenten getäuscht zu werden, die kaputten Code als fertig bezeichneten.

Kernarchitektur: ein expliziter Multi-Agenten-Graph

Zeroshot verwandelt ein Softwareziel in einen expliziten Multi-Agenten-Graphen. Ein Agent implementiert. Unabhängige Agenten prüfen. Besteht ein Review nicht, geht die Arbeit zurück in eine begrenzte Reparaturschleife. Nichts wird ausgeliefert, bevor die Prüfungen des Graphen bestanden sind. Der implementierende Agent genehmigt nie seine eigene Arbeit. Das ist die harte Regel des Entwurfs.

Die Positionierung ist ebenso wichtig wie der Mechanismus. Zeroshot ersetzt weder Claude Code noch Codex noch GitHub Copilot. Es führt eines davon als Worker und als Reviewer aus. Es ist also kein weiteres Coding-Modell, sondern eine Orchestrierungs- und Verantwortungsschicht um die Agenten, die man ohnehin nutzt. Man kann den eingebauten Graphen verwenden oder eine eigene Topologie mitbringen: Reviewer, Tests und Reparaturschleifen hinzufügen und die Konfiguration als Profil für die nächste Aufgabe speichern.

Funktionsweise und Ablauf

Die Installation ist ein einziger Befehl: npm install -g @the-open-engine-company/zeroshot. Der Installer verlangt Node.js 18 oder neuer. Er installiert eine geprüfte native Binärdatei für Linux x64 oder arm64, macOS x64 oder arm64 oder Windows x64. Außerdem installiert er auf Benutzerebene einen Zeroshot-Skill für Codex, GitHub Copilot und Claude Code. Für die lokale Ausführung muss man Codex, Claude Code oder GitHub Copilot installieren und anmelden. Zeroshot kann die bestehende Anmeldung dieses Harness wiederverwenden, auch abonnementgestützte Sitzungen. Ein Lauf braucht zwei JSON-Dateien. input.json enthält die Aufgabe, zum Beispiel: dem status-Befehl eine JSON-Ausgabe hinzufügen und gezielte Tests dazu schreiben. runtime.json benennt die Laufzeit: das Harness (etwa codex), den Anbieter (etwa openai), das Modell und die Stufe effort (etwa high). Dann ruft man zeroshot run mit --template software-change und --uniform-runtime-config runtime.json auf. Dem Namen nach wendet die Option eine einheitliche Laufzeitkonfiguration auf alle Agenten im Graphen an. Mit --validate-only prüft man vorab Graph, Laufzeitkonfiguration und Eingabe, ohne etwas zu starten.

Eine Tatsache verdient eine Warnung. Der Worker bearbeitet den aktuellen Git-Arbeitsbaum. Die Dokumentation rät daher, in einem sauberen, nur für diese Aufgabe gedachten Arbeitsbaum zu beginnen.

Warum unabhängige Prüfung eine solide Ingenieurentscheidung ist

Dieser Abschnitt ist unsere Analyse, keine vom Projekt veröffentlichte Angabe. Erstens durchbricht die Trennung von Ausführendem und Prüfendem die Schleife der Selbstbestätigung. Der Kontext des implementierenden Agenten ist voller eigener Gründe, warum die Änderung richtig sei. Ein Reviewer ohne diese Vorgeschichte sieht Versäumtes leichter. Zweitens hat die Reparaturschleife eine Grenze.

Ein unbegrenzter Zyklus aus Prüfen, Beheben und erneutem Prüfen kann das Kontingent ohne Ende verbrauchen. Eine Grenze macht Kosten und Zeit vorhersehbar. Drittens erlaubt eine Topologie, die konfigurierbare Daten statt einer festen Pipeline ist, den Graphen an das Risiko anzupassen. Eine Dokumentationskorrektur von einer Zeile kann einen leichten Graphen nutzen. Eine Änderung an der Zahlungslogik kann mehrere Reviewer und Tests bekommen.

Leistung und Kosten

Wir sagen es deutlich: Das von uns gelesene Material enthält keine veröffentlichten Benchmark-Zahlen. Wir können keine Erfolgsquote, keine Fehlerfangrate und keine Latenzänderung nennen. Das Video im README ist als gestellt gekennzeichnet, also eine Illustration und kein Beleg.

Die Kostenstruktur dagegen ist klar. Mehr Agenten bedeuten mehr Modellaufrufe und längere Laufzeit. Nutzt ein lokaler Lauf eine Abo-Anmeldung wieder, fallen die Grenzkosten auf das Kontingent dieses Abos. Die Preise für Zeroshot Cloud stehen auf der Produktseite zeroshot.sh.

Folgen für Entwickler und Unternehmen

Für einzelne Entwickler macht Zeroshot aus der manuellen Gewohnheit, einen anderen Agenten noch einmal schauen zu lassen, einen wiederholbaren Befehl. Für Teams bietet es eine Prüfschicht, die nicht an einen Modellanbieter gebunden ist. Darunter kann Codex, Claude Code oder Copilot laufen.

Das Projekt steht unter der MIT-Lizenz und wird über npm verteilt. Das Repository zeigt Badges für Build, Abdeckung und Dokumentation, was auf eine Pflege wie bei Produktionssoftware hindeutet. Das Projekt behauptet außerdem Sterne von Ingenieuren großer Technologiefirmen. Das ist die eigene Aussage des Projekts, und wir haben sie nicht unabhängig geprüft.

Grenzen und Herausforderungen

Erstens gibt es keinen öffentlichen Benchmark, das Nutzenversprechen stützt sich derzeit auf die Entwurfslogik. Zweitens ist unabhängige Prüfung nur so gut wie ihre Unabhängigkeit. Stammen Reviewer und Implementierer aus derselben Modellfamilie, teilen sie womöglich dieselben blinden Flecken.

Drittens heißt eine begrenzte Reparaturschleife, dass eine Aufgabe innerhalb der Grenze scheitern kann, und Nutzer brauchen einen Plan für diesen Fall. Viertens ist es riskant, ohne sauberen Ausgangspunkt zu starten, weil der Worker den aktuellen Arbeitsbaum direkt ändert. Fünftens ist Version 8 ein harter Schnittstellenwechsel: Sie ersetzt die Node.js-Laufzeit durch eine native Binärdatei, und Nutzer älterer Versionen müssen migrieren.

Ausblick

Veröffentlichen die Maintainer reproduzierbare Benchmarks, etwa Einzel-Agenten-Läufe gegen Läufe mit Review-Graph bei denselben Aufgaben, mit Erfolgsquote und Gesamtkosten, wird der Wert solcher Werkzeuge messbar. Eine weitere Richtung ist der Austausch von Profilen.

Teams, die abgestimmte Graphen je Risikostufe speichern, bauen nach und nach einen internen Lieferstandard auf. So oder so wird der Grundsatz, dass der Autor nicht selbst abnehmen darf, in der KI-gestützten Programmierung immer schwerer zu umgehen.

Sources