Einfache Tools, selbstfahrende Entwicklung: Wie Muse sich selbst baut

TL;DR Muse ersetzt maßgeschneiderte Agenten-Orchestrierungskonsolen durch vier Tools, die jedes Software-Team ohnehin schon offen hat: Slack, Linear, GitHub und Claude Code. Kein Dashboard, keine SPA, kein von Menschen geschriebener Code. Jeder PR durchläuft sieben CI-Gates und ein KI-Reviewgremium mit drei Personas nach einer Zero-Findings-Merge-Policy. 40,000 gesammelte Stimmen, Foundation-Model-Evaluation 80% schneller.

Muse, kurz für Meshy Universal System for Evaluation, ist unsere interne Plattform zur Modellbewertung. Teams bei Meshy nutzen sie täglich, um herauszufinden, ob neue Modell-Checkpoints besser abschneiden als alte.

Eines Tages war ein heißer neuer Modell-Checkpoint gerade fertig gebraut. Er brauchte ein Arena-Match, um die nächste Trainingsstrategie zu bestimmen. Das Team stellte fest, dass es dafür ein neues Muse-Feature brauchte.

"@Linear erstelle dazu ein Muse-Issue"

sagte der Product Manager in Slack.

Eine Minute später wurde das Linear-Issue MES-12345 erstellt.

Der Muse-Plattform-Owner — ich — sah sich das Issue an. Es musste schnellstmöglich ausgeliefert werden, um die Eval-Aufgabe freizugeben. Dann wurde die Nachricht an Claude geschickt:

"Untersuche und behebe MES-12345"

Claude sah sich das Issue an und brachte zwei Designentscheidungen zur Sprache. Die Entscheidungen wurden getroffen, und ich verließ das Terminal, um an etwas anderem zu arbeiten.

Anderthalb Stunden später war eine neue Version von Muse deployt. Fertig.

Autonome Softwareentwicklung muss keine ausgefallene Agenten-Orchestrierungskonsole oder ein Dashboard sein. Und in diesem Artikel erkläre ich, wie wir das möglich gemacht haben.

Eine Galerie, ein Viewer und ein Abstimmungs-Button

Die Frage, die Muse beantwortet, ist trügerisch schwer: Ist der neue Modell-Checkpoint tatsächlich besser? Natürlich gibt es in jedem Trainingslauf quantitative Metriken, die man verfolgen kann, aber sie bilden bei Weitem nicht genau ab, wie „gut" bei der 3D-Generierung tatsächlich aussieht. Also macht Muse das Einfache, aber Wirksame: Doppelblindtests. Es stellt die Ausgaben zweier Modelle nebeneinander, mit demselben Eingabebild, zufällig links oder rechts angeordnet, und lässt Teammitglieder blind abstimmen.

Eine Evaluation ist ein Batch aus solchen Paaren. Jemand richtet Muse auf zwei Sätze generierter Meshes und einen Ordner mit Referenzbildern aus, und die App übernimmt den Rest: Sie paart die Modelle, verschleiert die Zuordnung und liefert jeweils einen Vergleich zur Zeit. Stimmen sammeln sich an, sobald jemand eine freie Minute hat. Die gesamte Oberfläche ist auf schnelle Häppchen ausgelegt und lässt sich fast vollständig über Hotkeys bedienen. Wer erst zur Maus greifen muss, stimmt seltener ab.

Die Muse-Voting-Oberfläche: zwei generierte Meshes, dasselbe Eingabebild, zufällig links oder rechts angeordnet.

Das ist das Produkt. Eine Galerie, ein Viewer und ein Abstimmungs-Button. An der Funktion von Muse ist nichts kompliziert, und genau deshalb eignet es sich so gut als sauberer Fallstudien-Kandidat. Ungewöhnlich ist nur, wie es gebaut wird.

Eine Architektur, die Agenten navigieren können

Das Muse-Projekt startete Ende 2025, als „Vibe Coding" gerade zum neuen Buzzword geworden war. Neben der Unterstützung von Meshys wachsenden Evaluationsbemühungen in Trainings- und Release-Zyklen hatte Muse auch ein ambitioniertes Ziel: Software für das gesamte Unternehmen zu bauen, mit null Zeilen von Menschen geschriebenem Code.

Heute sind die Ergebnisse hervorragend:

• Über 40,000 gesammelte Stimmen seit der ersten Auslieferung von Muse, bei über 30 Evaluationsprojekten pro Monat
• Mehr als 4 Teams nutzen Muse aktiv für ihre tägliche Arbeit
• Erste interne Codebasis, zu der aktiv mindestens 1 nicht-technisches Teammitglied beiträgt
• Erste interne Codebasis mit vollständig autonomer Entwicklung

Insgesamt schätzen wir, dass Muse unsere Foundation-Model-Evaluation um mindestens 80% beschleunigt und bei jedem Modell-Release mindestens 10 Personentage Arbeit eingespart hat. Ohne Muse wäre es nahezu unmöglich gewesen, den aktuellen Entwicklungs- und Release-Durchsatz von Meshys generativer Modellsammlung wie Geometrie, Textur und Smart Topology aufrechtzuerhalten.

Von Anfang an wurde Muse so gestaltet, dass es für Agenten so lesbar wie möglich ist. Bereits 2025 stellten wir fest, dass Agenten beim Umsetzen desselben Use Case in manchen Aspekten kämpften, während sie in anderen auf Anhieb erfolgreich waren. Viele dieser Iterationen mündeten schließlich in einen heute bewusst langweiligen Tech-Stack. Das Backend ist Python: FastAPI, Postgres für Datensätze, S3 für Meshes und Bilder. Das Frontend wird serverseitig gerendert: Jinja2-Templates, HTMX für partielle Seitenaktualisierungen, Tailwind fürs Styling, und eine einzige echte clientseitige Komponente, der WebGL-3D-Viewer, der die Meshes rendert. Es gibt keine SPA und kein separates Frontend-Modul. Die Kopplung zwischen den beiden Stacks ist die älteste im Web: Das Backend rendert HTML, der Browser zeigt es an. Wenn sich eine Seite ändern muss, fordert HTMX ein Fragment an, und der Server rendert auch das.

Hier ist die Architektur der Kern-Evaluationsanwendung in Muse:

Die geschichtete Architektur von Muses Kern-Evaluationsanwendung. Abhängigkeiten zeigen ausschließlich nach unten.

Zwei Eigenschaften dieser Struktur sind für Agenten wichtig. Erstens: Der Frontend-Zustand lebt auf dem Server. Das HTML, das ein Nutzer sieht, ist das HTML, das das Backend erzeugt hat, sodass ein Test (oder ein Agent) direkt darauf prüfen kann, ohne ein clientseitiges Framework antreiben zu müssen, um zu rekonstruieren, was der Nutzer gesehen hat. Zweitens: Jede Abhängigkeit wird maschinell erzwungen und zeigt ausschließlich nach unten. Ein Feature-Ordner darf seinen Nachbarordner nicht importieren; wenn zwei Features einander brauchen, injiziert die Composition Root eine Fähigkeit in die andere, sodass die Abhängigkeit in genau einer Datei sichtbar ist. Jeder Layer hat eine einzige Aufgabe, und diese Aufgaben stehen genau dort geschrieben, wo ein Agent über sie stolpern wird:

Abhängigkeiten zeigen immer nur nach unten in dieser Liste, und die Richtung wird durch eine Build-Prüfung erzwungen, nicht durch eine Konvention.

Drei weitere Eigenschaften machen die Codebasis bewusst für Agenten lesbar:

• Jedes Verzeichnis trägt seine eigene Dokumentation (was der Service tut, seine Layering-Regeln, die genauen Befehle, die einen Merge freigeben), sodass ein Agent, der kalt einsteigt, sich orientieren kann, ohne nachzufragen oder sich selbst etwas auszudenken.
• Nicht-triviale Module tragen Docstrings mit Rückverweisen auf Design-Dokumente, sodass das Warum neben dem Was erhalten bleibt.
• Keine Datei darf 500 Zeilen überschreiten, mit einer Sperrklinke für einige wenige Ausnahmefälle. Bei diesen Ausnahmen dürfen Dateien schrumpfen, aber nie wieder wachsen. Context Windows sind endlich; die Architektur trägt dem Rechnung.

Fortschritt sollte nicht in einem kleinen Raum leben

Heute, da LLM-Agenten deutlich leistungsfähiger sind als 2025, wollen wir, dass die Entwicklung von Muse vollständig autonom abläuft. Das heißt: Der Mensch weist den Agenten nur auf die Aufgabe hin. Der Agent orientiert sich selbst an Codebasis und Aufgabenkontext, arbeitet sich durch Implementierung, CI und Code-Review, und steuert den Pull Request am Ende selbst bis zum Merge. Der Mensch legt nur die Priorität der Issues fest und trifft die zentralen Designentscheidungen.

Der erste Gedanke bei vollständig autonomer Entwicklung sind meist maßgeschneiderte Plattformen: Orchestrierungskonsolen, agenten-native Workspaces, eine App nach der anderen, die verspricht, deine Agentenflotte zu verwalten. Wir haben uns das angeschaut und abgelehnt. Nicht, weil es keine großartigen Produkte wären, sondern wieder wegen der Lesbarkeit.

Wir wollen, dass die Arbeit der Agenten für Menschen lesbar ist, genau wie die Codebasis für Agenten lesbar sein soll. Wir sind ein einigermaßen großes Unternehmen. Steckt man autonome Entwicklung in eine eigene Konsole, wird ihr Fortschritt nur für die wenigen Menschen sichtbar, die in dieser Konsole leben.

Deshalb ist der Stack an Kollaborations- und Entwicklungstools wieder einmal bewusst langweilig. Alles in unserer Geschichte lief über vier Tools, die jedes Softwareunternehmen ohnehin schon offen hat: Slack, Linear, GitHub und Claude Code. Das macht den Fortschritt, den der Agent macht, genauso beobachtbar und durchsuchbar wie den jedes anderen Teammitglieds. Ein Product Manager öffnet Linear-Issues und prüft den Feature-Status genau wie immer. Der GitHub-Bugbot oder das Security-Review liest PR-Threads genau wie immer. Wer auch immer einen Bug meldet, fügt einen Screenshot in denselben Slack-Kanal wie immer ein, und der Fix taucht als ganz normaler Pull Request auf. Niemand muss irgendetwas lernen, um die „Maschine" zu beaufsichtigen.

Hier ist die Form eines einzelnen autonomen Issues, von Anfang bis Ende:

Ein autonomes Issue, von Anfang bis Ende. Der Mensch berührt die Schleife an genau zwei Stellen.

Der Mensch berührt diese Schleife an genau zwei Stellen: wenn er den Agenten auf das Linear-Issue ansetzt, und bei der Handvoll Entscheidungen, die der Agent aufwirft, bevor er Code schreibt. Alles dazwischen — die Implementierung, die Checks, das Review-Gespräch, der Merge und das Deployment — läuft ohne jemanden am Steuer. Wenn ein Check fehlschlägt oder ein Reviewer Einwände hat, liest der Agent den Fehler, behebt ihn und pusht erneut, und die Schleife dreht einfach eine weitere Runde. Sie endet erst, wenn der Branch grün ist, jeder Befund gelöst ist und die Queue ihn gemerged hat.

Was das möglich macht, ist keine maßgeschneiderte Integration. Es liegt daran, dass die drei Tools bereits Kommandoflächen bereitstellen, die ein Agent direkt bedienen kann — dieselben, die auch ein Mensch benutzt:

• GitHub, über seine CLI. Der Agent öffnet den Pull Request, liest Status und Logs jedes CI-Jobs zurück, antwortet in Review-Threads und markiert sie als gelöst, und reiht den Branch in die Merge-Queue ein — alles über ganz gewöhnliche gh-Befehle.
• Linear, über seinen MCP-Server. Der Agent liest das Issue, auf das er angesetzt wurde, folgt den Links zu verwandten Issues für Kontext, ändert den Status und legt Folge-Issues für Arbeit an, die er unterwegs entdeckt — alles als vollwertige Tool-Calls.
• Claude Codes eigene Monitor-Schleife. CI dauert Minuten, und die Merge-Queue dauert noch länger, und dabei schaut kein Mensch zu. Stattdessen schaut der Agent zu, und die Art, wie er zuschaut, ist es, die aus einem unbeaufsichtigten Lauf etwas Praktisches macht statt eines Token-Lagerfeuers.

Wenn der Agent einen Pull Request öffnet, sitzt er nicht da und aktualisiert eine Seite; er merkt sich, worauf er wartet — den CI-Lauf, die Review-Threads, den Merge-Queue-Eintrag — und beendet dann den Turn. Claude Codes Monitor-Feature ruft ihn erst wieder auf, wenn sich dieser beobachtete Zustand ändert: Ein Job wird rot, das Review-Gremium postet einen Befund, die Queue merged den Branch. Weil der Agent durch Nachrichten vom Monitor über jedes Status-Update geweckt wird, ergreift er die jeweils passende nächste Maßnahme — etwa das Log eines fehlgeschlagenen Jobs zu holen und einen Fix zu pushen, in einem Review-Thread zu antworten und ihn als gelöst zu markieren, oder den Branch einzureihen, sobald jedes Gate grün ist.

Nichts davon ist spezifisch für Muse. Jedes Repository, das über diese drei Tools erreichbar ist, lässt sich genauso steuern — genau deshalb haben wir uns für sie entschieden.

Vertrauen ist ein Build-Artefakt

Wir vertrauen nicht dem LLM selbst. Wir vertrauen dem LLM-Agenten innerhalb eines Harness, und dieses Harness lässt sich so konstruieren, dass es als Wächter für Zuverlässigkeit fungiert. Konkret ist das Harness unsere CI/CD-Pipeline plus die Review-Schicht obendrauf. Das durchläuft jeder Pull Request, ohne Ausnahme:

Jeder Pull Request durchläuft dasselbe Harness: zuerst automatisierte Checks, dann das KI-Reviewgremium.

Die einzelnen Jobs, mit typischen Zeiten, gemessen an kürzlichen echten PR-Läufen:

Die Guardrails sind die zuvor beschriebene Architektur, in Maschinen gegossen. Ein Import von einem Nachbarordner ist hier kein Review-Kommentar; er ist ein roter Build. Die visuellen Goldens werden in CI's eigener Rendering-Umgebung aufgenommen, sodass „funktioniert auf meiner Maschine" niemals ein Argument dafür sein kann, einen Bug in main zu mergen.

Bei der KI-Review-Schicht wird es interessant. Jeder PR wird von unserem eigenen Gremium aus drei Coding-Agent-Reviewern gelesen, die denselben Diff gegen die schriftlich festgehaltenen Designprinzipien des Repos lesen, jeder mit einer anderen zugewiesenen Persona. Hier zeigen wir einen Umriss der Prompts, die jedem Reviewer gegeben werden.

Der Principal Engineer:

Persona: Principal Engineer, Design-Review, großer Scope

Du prüfst auf Systemebene: Gehört diese Änderung hierher, passt sie zur Architektur, nutzt sie Vorhandenes wieder, und bleibt sie additiv — nicht, ob eine Zeile ordentlich aussieht.

Du siehst den Diff + die Guides, nicht das gesamte Repo. Beurteile Wiederverwendung und Muster-Konsistenz ...; behaupte keine Repo-weite Suche, die du nicht durchführen kannst.

Deine Linse: Beurteile den Diff anhand dieser Teile der bereitgestellten Guides ...

Lackmustest: „Würde ich das als Principal Engineer für diese Codebasis zurückschicken, weil es am falschen Ort liegt, eine vorhandene Fähigkeit dupliziert, oder einen zweiten Weg für etwas bereits Gelöstes hinzufügt?" Falls nein, gib [] zurück.

Der Senior Engineer:

Persona: Senior Engineer, Logik / Implementierung / Qualität

Du prüfst innerhalb der Änderung: Ist die Logik korrekt, sauber, testbar und sicher. Das ist das gründlichste Review, verfolge die Code-Pfade, überflieg nicht. Konzentriere dich auf den Diff und die Dateien, die er berührt (lies sie vollständig).

Deine Linse: Beurteile den Diff anhand dieser Teile der bereitgestellten Guides ...

Lackmustest: „Würde ich diese Logik freigeben, oder würde ich bei genauem Lesen einen Bug, eine nicht testbare Schnittstelle oder einen Sicherheitsfehler finden?" Sei konkret bei der fehlschlagenden Eingabe oder dem Code-Pfad. Wenn die Logik stimmig ist, gib [] zurück.

Der QA Engineer:

Persona: QA Engineer, funktioniert es, ist es getestet, wird es kaputtgehen

Du prüfst Verhalten und Risiko: Tut diese Änderung das, was sie behauptet, ist sie durch Tests abgedeckt, und könnte sie live oder in Produktion etwas kaputt machen? Lies Titel und Beschreibung des PR, und prüfe dann, ob der Diff das einlöst.

Deine Linse: Intent-Abgleich ...; Testabdeckung ...; Regressionsrisiko ...; Produktionsfallen ...

Lackmustest: „Würde ich das als QA beim Abnehmen blockieren, weil es nicht tut, was es behauptet, weil ungetestetes Verhalten ausgeliefert wird, oder weil eine Änderung Prod kaputt macht?" Wenn es sicher und abgedeckt ist, gib [] zurück.

Neben dem Blick auf denselben Code-Diff aus unterschiedlichen Blickwinkeln teilen sich die 3 Reviewer auch einen gemeinsamen Regelsatz, der die Entwicklung der gesamten Codebasis bestimmt, also die Guides:

• Dinge, die sich gemeinsam ändern, leben zusammen; unzusammenhängende Dinge bleiben trennbar. Das Ändern oder Löschen eines Concerns berührt genau eine Stelle.
• Business-Logik hängt nicht von den Details der Außenwelt ab. Eine Business-Logik-Funktion läuft in einem Test mit übergebenen Fakes, ohne echtes I/O. Der Austausch eines Backends berührt keine Business-Logik. Die App ruft nie ihre eigenen HTTP-Endpunkte auf.
• Wiederverwenden, nicht neu erfinden. Jede Fähigkeit hat eine Implementierung; ein neuer Consumer ruft die vorhandene Schnittstelle auf, statt sie zu kopieren.
• Features durch Hinzufügen ergänzen, nicht durch Bearbeiten. Ein Feature hinzuzufügen bedeutet „neue Dateien + eine Registrierungszeile", und es zu löschen berührt kein anderes Feature.
• Ein etablierter Weg für jede Sache. Ein Neuling kopiert das vorhandene Muster, statt zu wählen, und Tests brauchen weder Server noch DB.
• Code löschen, sobald er nicht mehr benutzt wird. Nichts wird ausgeliefert, das niemand aufruft; „behalten wir sicherheitshalber" ist kein Grund, denn git erinnert sich.
• Das Einfachste bevorzugen, das funktioniert; Komplexität nur hinzufügen, wenn man dazu gezwungen ist. Jede Abstraktion verdient sich ihren Platz durch einen konkreten aktuellen Bedarf. Die Änderung ist die kleinste, die das Problem löst.

Das Gremium postet jeden blockierenden Befund als Inline-Kommentar, verankert an der genauen Zeile, und diese Kommentare blockieren den Merge, bis sie gelöst sind.

So sieht ein Review aus einem kürzlichen Feature-PR aus:

[medium] Regressionsrisiko. Diese Funktion ist der gemeinsame Create-and-Sync-Flaschenhals; sie fasst jetzt Dateien mit View-Suffix in einer gruppierten Zeile zusammen. Jeder bereits vorhandene Datensatz, der unter dem alten Schema aufgenommen wurde, wird bei seinem nächsten Sync stillschweigend neu gruppiert, wobei die alten Sample-Identitäten gelöscht werden, auf die laufende Evaluationen noch verweisen. Kein Test deckt das erneute Synchronisieren eines vorhandenen Datensatzes durch die neue Gruppierung ab.

Dieser Befund war korrekt. Der Code hatte die vollständige Testsuite bestanden und eine erste Runde grüner CI. Die Tests waren richtig für den Code, so wie er geschrieben war. Der Reviewer erkannte, dass der geschriebene Code für die Daten, die wir tatsächlich haben, falsch war. Claude behob es, fügte den fehlenden Regressionstest hinzu, antwortete im Thread und löste den Befund. Der gesamte Austausch ist öffentlich im PR sichtbar, genau so, wie man einen Junior Engineer durch ein Code-Review mentoren würde.

Das war ein PR. Während wir den Agenten über die Zeit laufen lassen, entdecken wir darüber hinaus einige weitere typische Muster:

• Ein Fix, der ein neues Problem verursacht. Ein von uns ausgeliefertes Diagnosetool maß die Download-Geschwindigkeit. Das Review erkannte, dass die Berechnung MB (1,000,000 Bytes) verwendete, der Server aber MiB (1,048,576 Bytes) sendete, sodass jede Geschwindigkeit 5% zu niedrig angezeigt worden wäre. Ein paar Pushes später bemängelte das Review, dass der Fix zwei Konstanten hinterließ, die von Hand synchron gehalten werden mussten. Also forderte es, die Geschwindigkeit stattdessen aus den tatsächlich empfangenen Bytes zu berechnen. Der Reviewer entdeckte einen Bug, den die Bearbeitung seiner früheren Anmerkung selbst verursacht hatte.
• Sackgassen-Anwendungsfälle. Dieselbe Seite wurde mit einem Link ausgeliefert, der für jeden eingeloggten Nutzer sichtbar war, obwohl die Seite selbst eine bestimmte Berechtigung erforderte. Wer diese Berechtigung nicht hatte, klickte und landete bei einem 403-Fehler. Kein Test schlug fehl, da der Link angezeigt wurde und das Berechtigungs-Gate funktionierte. Der QA-Reviewer verglich beides und blockierte den Merge, bis der Link nur noch Personen angezeigt wurde, die die Seite tatsächlich öffnen konnten.
• Tests durch Tricksen bestehen. Der Test eines Fixes erzeugte künstlich genau die Exception, die er eigentlich abfangen sollte, sodass er auch dann bestand, wenn die echte Fehlerbehandlung kaputt war, weil der Test die „korrekte" Exception-Nachricht erhielt. Das Gremium markierte das, und der umgeschriebene Test lässt echte Fehler durch den echten Code laufen. Derselbe PR hatte auch einen Test, der auf der Maschine des Entwicklers bestand, aber in CI fehlschlug, weil er sich stillschweigend auf eine Credentials-Datei verließ, die nur auf unserer Dev-Box existiert. Beides waren Bugs in den Tests selbst, die von der Schicht darüber entdeckt wurden.

Unsere Merge-Policy lautet 0 KI-Review-Befunde. Jeder Befund wird behoben oder mit Belegen widerlegt, bevor die Queue den PR übernimmt. Wir haben die Widerlegung zu einer gangbaren Option gemacht, weil das Review-Gremium in einem tolerierbaren Maß überflaggt. Aufzuschreiben, warum ein Befund falsch ist, kann umgekehrt gelegentlich einen Fehler in der eigenen Argumentation des Review-Gremiums aufdecken.

Nach den Checks validiert die Merge-Queue jeden Branch erneut gegen die sich bewegende Spitze von main, und ein Merge deployt automatisch in Produktion, ohne dass ein Mensch im Loop ist.

Nach jedem Gate validiert die Merge-Queue den Branch erneut, und ein Merge deployt in Produktion.

Codezeilen sind nur ein kleiner Teil der Geschichte

Über den Verlauf vieler selbstfahrender PRs hinweg fanden wir ein auffälliges, aber nachvollziehbares Muster: Die Zeit, um über Checks und Reviews zu iterieren, ist viel länger als die Zeit, um die erste Implementierung zu schreiben, und das Verhältnis variiert außerdem stark je nach Art der Aufgabe. Hier vergleichen wir zwei Arten von Entwicklungsaufgaben in derselben Woche.

Fall A: ein totes Feature abschalten. Ein kleines Legacy-Feature ging offline; sein Link, der Bestätigungsdialog, die Übersetzung, die Tests und die Screenshot-Baseline mussten alle weg. Vom Anlegen des Linear-Issues bis zum gemergten PR auf main dauerte es nur 16 Minuten, wovon die ersten 2 Minuten auf das Schreiben von Code entfielen. Reviews waren nur beratend.

Fall B: eine größere Verbesserung am Netzwerk-Diagnose-Feature. Es war nach Zeilenzahl eine ähnlich große Änderung, deren erste Version in 5 Minuten fertig war, während die gesamte Zeit bis zum Merge etwa 3 Stunden betrug. Im Verlauf dessen löste der Agent 5 Review-Runden und 7 merge-blockierende Befunde.

Auch die Zeitverläufe unterscheiden sich deutlich:

Zwei Aufgaben mit vergleichbarer Zeilenzahl, mit Verifikationsaufwand im Verhältnis zum Risiko.

Die zweite Aufgabe dauert elfmal länger, nicht weil der Code schwieriger zu schreiben war, sondern weil das Risiko ein anderes war und der Verifikationsaufwand proportional dazu investiert wurde. Fall A war eine Löschung: das schlimmste Ergebnis war ein kaputter Link, der ohnehin nicht hätte besucht werden sollen. Fall B war ein Messwerkzeug: das schlimmste Ergebnis war, dass jeder Nutzer einer falschen Zahl vertraut. Das Review-Gremium fand die Fehler und verbrachte dann drei weitere Runden damit, Teil-Fixes abzulehnen, bis die Fehlerbehandlung typisiert, vollständig und gründlich getestet war. Jede Runde machte die Implementierung strikt enger. Keiner dieser Fehler ließ einen Test fehlschlagen, und alle hätten es in Produktion geschafft.

Das ist der Teil, den One-Shot-Codegenerierung von Natur aus falsch macht. One-Shot-Generierung optimiert die Metrik, die am leichtesten zu sehen ist: die Zeit vom Prompt bis zu Code, der kompiliert und läuft. Beide unserer Fälle erreichten diese Metrik in wenigen Minuten, und hätten wir dort aufgehört, wäre Fall B ein paar Minuten nach dem Start fertig gewesen — und monatelang falsch.

Dieselbe Pipeline, die eine Löschung in 16 Minuten durchwinkte, hielt ein Messwerkzeug 3 Stunden lang zurück, ohne dass ein Mensch entschied, welche Behandlung jedem zustand. Wenn Leute fragen, ob man KI-geschriebenem Code in Produktion vertrauen kann, lautet die Antwort: Der Code ist genau so vertrauenswürdig wie die Verifikation, die ihn umgibt, und Verifikationstiefe ist jetzt etwas, das man mit Agenten-Stunden kauft statt mit Engineer-Tagen. Ein falscher Geschwindigkeitsbericht kostet mehr als drei Stunden, sobald jemand eine Netzwerkbeschwerde das erste Mal danach ausrichtet.

Was wir gelernt haben und was als Nächstes kommt

Heute gilt: Autonomie ist eher eine Eigenschaft des Harness als eine Eigenschaft des Modells. Jedes Modell-Upgrade hat unsere Agenten besser gemacht; die Modellfähigkeit selbst liefert jedoch keine Garantie mit, dass man dem Agenten vertrauen darf, seine Pull Requests frei zu mergen. Statt mehr menschliche Aufmerksamkeit zu investieren oder blind das teuerste Frontier-Modell einzusetzen, haben wir uns entschieden, die „Hände" und „Augen" zu bauen, damit Agenten mit allem ausgestattet sind, was sie brauchen, um korrekten Produktionscode zu erzeugen. Und da sich die Modellfähigkeit weiterentwickelt, lässt uns das auch auf der Welle mitreiten, statt das Gerüst immer wieder neu zu bauen, um die Grenzen der Modelle auszugleichen.

Die Rolle des Menschen konzentriert sich, sie verschwindet nicht. Was übrig bleibt, ist der irreduzible Kern: entscheiden, was es wert ist, gebaut zu werden, es klar genug aufschreiben, und in den Momenten Urteilsvermögen ausüben, die die Maschinen als mehrdeutig kennzeichnen. Designgeschmack und die Qualität von Spezifikationen sind jetzt die Engineering-Fähigkeit mit der größten Hebelwirkung in diesem Team.

Und die interessanteste Erkenntnis über Agenten-Teams ist, dass der Wert des Teams aus Konflikt statt aus Zusammenarbeit entsteht. Es kann sinnvoll sein, eine Full-Stack-Aufgabe zwischen einem Frontend- und einem Backend-Agenten aufzuteilen. Es ergibt weniger Sinn, einen Frontend-Agenten und einen Backend-Agenten nur deshalb miteinander sprechen zu lassen, um die Aufgabe abzuschließen. Der Nutzen des Teams entsteht, wenn die Mitglieder widersprüchliche Ziele haben. Unser Muse-Entwicklungsagent will den Code ausliefern. Unsere KI-Review-Agenten wollen finden, wo der Code falsch ist oder schlecht designt wurde. Es ist ihre Spannung, die das Ergebnis vertrauenswürdig macht und den wahren Arbeitsaufwand einer Entwicklungsaufgabe ehrlich offenlegt.

Wichtiger noch: Wir stellen fest, dass unsere Erkundungen uns zu einer entstehenden Art führen, Software zu entwickeln: einer autonomen Engineering-Organisation. Auch wenn wir gezeigt haben, dass Agenten einzelne Aufgaben mit den vorhandenen Tools autonom erledigen können, laden einige fehlende Teile und offene Fragen zu künftigen Vorhaben ein:

• Wie weit können wir solche Systeme skalieren? Während autonome Organisationen an immer größeren Aufgaben und Projekten mit mehr parallelen Agenten arbeiten, welche neuen Probleme werden entstehen?
• Wie können die eigenen Ausgaben des Harness, etwa First-Shot-CI-Erfolgsraten und KI-Review-Befunde, zu Evaluationssignalen werden? Wie messen wir die Leistung eines Agenten in der Organisation, und wie machen wir sie selbstweiterentwickelnd?
• Wie lassen sich der Design- und Produktgeschmack von Menschen in solche Systeme einbacken? Wenn Engineering mit spärlichen menschlichen Urteilen autonom gemacht werden kann, wie weit können wir das treiben, um die Fragen zu lösen, für wen wir die Software bauen sollten und wie sie aussehen sollte?

Zum Schluss: Danke, dass du bis ganz zum Ende gelesen hast. Die To-do-Liste, um Antworten auf diese Fragen zu finden, lebt passenderweise in Linear, wo sich unser nächster Agent — oder du — ihrer annehmen könnte.