- Experiment mit einem internen Beta-Softwareprodukt, bei dem 0 Zeilen manuell geschriebener Code als feste Vorgabe galten und Codex Anwendungslogik, Tests, CI-Konfiguration, Dokumentation, Observability und sogar interne Tools schrieb
- Die Codebasis, die mit einem leeren git-Repository begann, wuchs in etwa 5 Monaten auf rund 1 Million Zeilen an; drei Engineers betrieben Codex und eröffneten und mergten etwa 1.500 PRs – ein hohes PR-Volumen
- Die Hauptaufgabe von Engineers verlagerte sich vom Schreiben von Code hin zu Umgebungsdesign, der Spezifikation von Absichten und dem Aufbau von Feedback-Loops, damit Agenten verlässlich arbeiten können
- Repository-Wissen wird über ein kurzes
AGENTS.md, strukturiertedocs/, Ausführungspläne, Linter und CI verwaltet, während UI, Logs, Metriken und Traces in eine für die Anwendung lesbare Form überführt werden, die Codex direkt lesen und verifizieren kann - Mit steigendem Durchsatz wurde es praktikabel, Merge-Gates zu minimieren und Korrekturen über nachgelagerte Ausführungen vorzunehmen, doch langfristige architektonische Konsistenz und die Kodierung menschlicher Urteilskraft bleiben weiterhin Lernaufgaben
Interne Beta mit 0 Zeilen manuell geschriebenem Code
- In den vergangenen 5 Monaten lief ein Experiment, bei dem ein internes Beta-Softwareprodukt mit 0 Zeilen manuell geschriebenem Code aufgebaut und veröffentlicht wurde
- Das Produkt hat interne tägliche Nutzer sowie externe Alpha-Tester und befindet sich in einem Zustand, in dem es reale Releases, Deployments, Ausfälle und Fixes durchläuft
- Jede einzelne Codezeile – von Anwendungslogik über Tests, CI-Konfiguration, Dokumentation, Observability bis hin zu internen Tools – wurde von Codex geschrieben; geschätzt wurde es in etwa einem Zehntel der Zeit aufgebaut, die man für handgeschriebenen Code gebraucht hätte
- Menschen steuern, Agenten führen aus
- Innerhalb weniger Wochen musste das Endergebnis veröffentlicht werden, das schließlich einen Umfang von 1 Million Zeilen erreichte; dafür verlagerte sich die Hauptarbeit des Engineering-Teams vom Schreiben von Code hin zu Umgebungsdesign, der Spezifikation von Absichten und dem Aufbau von Feedback-Loops
Start mit einem leeren git-Repository
- Der erste Commit im leeren Repository erfolgte Ende August 2025
- Das anfängliche Scaffold – Repository-Struktur, CI-Konfiguration, Formatierungsregeln, Package-Manager-Setup und Application-Framework – wurde von Codex CLI mit GPT-5 erstellt, unterstützt durch Hinweise aus einigen bestehenden Templates
- Auch die anfängliche Datei
AGENTS.md, die beschreibt, wie Agenten im Repository arbeiten sollen, wurde von Codex geschrieben - Es gab keinen bestehenden von Menschen geschriebenen Code, der das System trug; das Repository wurde von Anfang an durch Agenten geformt
- Fünf Monate später umfasste das Repository etwa 1 Million Zeilen über Anwendungslogik, Infrastruktur, Tools, Dokumentation und interne Developer-Utilities hinweg
- Drei Engineers betrieben Codex und eröffneten und mergten etwa 1.500 PRs, was einem Durchschnitt von 3,5 PRs pro Engineer und Tag entspricht
- Auch nachdem das Team auf sieben Engineers gewachsen war, stieg der Durchsatz weiter
- Das Ergebnis ist kein Output nur um des Outputs willen; das Produkt wird von Hunderten internen Nutzern verwendet, darunter interne Power User
- Während des gesamten Entwicklungsprozesses trugen Menschen keinen Code direkt bei, und kein manuell geschriebener Code war eine Kernphilosophie des Teams
Neudefinition der Engineer-Rolle
- Die Einschränkung, dass Menschen nicht direkt coden, führt eine andere Art von Engineering-Arbeit ein, die sich auf Systeme, Scaffolding und Hebelwirkung konzentriert
- Der frühe Fortschritt war langsamer als erwartet, nicht wegen mangelnder Fähigkeiten von Codex, sondern weil die Umgebung nicht ausreichend spezifiziert war
- Dem Agenten fehlten die nötigen Tools, Abstraktionen und internen Strukturen, um auf hochrangige Ziele hin Fortschritte zu machen
- Die Hauptaufgabe des Engineering-Teams besteht darin, Agenten in die Lage zu versetzen, nützliche Arbeit zu leisten
- Die tatsächliche Arbeit folgt einem Depth-First-Ansatz: große Ziele werden in kleinere Bausteine wie Design, Code, Review und Tests zerlegt, Agenten werden per Prompt dazu gebracht, diese Bausteine zu erstellen, und sie dienen anschließend als Grundlage für komplexere Aufgaben
- Bei Misserfolgen lautet die Lösung nicht „sich mehr anzustrengen“, sondern herauszufinden, welche Fähigkeit fehlt, damit Codex die Arbeit erledigen kann, und diese so bereitzustellen, dass der Agent sie lesen und befolgen kann
- Menschen interagieren mit dem System überwiegend per Prompt: Ein Engineer beschreibt die Aufgabe, startet den Agenten und lässt ihn einen PR eröffnen
- Beim Abschließen eines PR führt Codex lokal ein Review der eigenen Änderungen durch, fordert lokal und in der Cloud zusätzliche Agent-Reviews an, reagiert auf menschliches oder agentisches Feedback und wiederholt das Ganze, bis alle Agent-Reviewer zufrieden sind – in einem Ablauf nahe der Ralph Wiggum Loop
- Codex nutzt Standard-Entwicklungstools wie
gh, lokale Skripte und in das Repository eingebaute Skills direkt, um Kontext ohne menschliches Copy-and-paste zu sammeln - Menschen können PRs reviewen, sind aber nicht zwingend erforderlich; im Laufe der Zeit verlagerte sich fast die gesamte Review-Arbeit auf die Interaktion zwischen Agenten
Die Anwendung besser lesbar machen
- Mit steigendem Code-Durchsatz verlagerte sich der Engpass auf die menschliche QA-Kapazität
- Da menschliche Zeit und Aufmerksamkeit die feste Beschränkung waren, wurden UI, Logs und App-Metriken selbst so gestaltet, dass Codex sie direkt lesen kann, um die Fähigkeiten der Agenten zu erweitern
- Die Anwendung wurde so aufgebaut, dass sie pro git worktree gestartet werden kann, sodass Codex für jede Änderung eine eigene Instanz ausführen und bedienen kann
- Das Chrome DevTools Protocol wurde an die Agent-Runtime angebunden und es wurden Skills für DOM-Snapshots, Screenshots und Navigationsaufgaben erstellt
- Dadurch kann Codex Bugs reproduzieren, Fixes verifizieren und das Verhalten der UI direkt erschließen
- Logs, Metriken und Traces werden Codex über einen lokalen Observability-Stack zugänglich gemacht, der temporär für einen bestimmten worktree existiert
- Codex arbeitet auf einer vollständig isolierten App-Version, die auch Logs und Metriken umfasst; nach Abschluss der Arbeit werden die zugehörigen Logs und Metriken entfernt
- Agenten fragen Logs mit LogQL und Metriken mit PromQL ab
- Prompts wie „Sicherstellen, dass der Service-Start in unter 800 ms abgeschlossen ist“ oder „Sicherstellen, dass kein Span in vier zentralen User Journeys 2 Sekunden überschreitet“ werden in ausführbare Arbeit übersetzt
- Es kommt häufig vor, dass ein einzelner Codex-Lauf mehr als 6 Stunden an einer Aufgabe arbeitet – oft in der Zeit, in der Menschen schlafen
Repository-Wissen als System of Record
- Eine der zentralen Herausforderungen, um Agenten bei großen und komplexen Aufgaben effektiv zu machen, ist das Kontextmanagement
- Codex braucht keine 1.000-seitige Anleitung, sondern eine Karte
- Kontext ist eine knappe Ressource; riesige Anweisungsdateien verdrängen Aufgaben, Code und relevante Dokumente, wodurch Agenten zentrale Constraints übersehen oder auf die falschen Constraints optimieren
- Zu viel Anleitung ist keine Anleitung mehr; wenn alles wichtig ist, ist nichts wichtig, und Agenten bleiben bei lokalem Pattern Matching, statt bewusst zu explorieren
- Ein einzelnes riesiges Handbuch veraltet sofort und läuft Gefahr, zu einem Friedhof veralteter Regeln und zu einer verlockenden, aber nicht gepflegten Ablenkung für Menschen zu werden
- Eine einzelne monolithische Datei ist mechanisch schwer auf Abdeckung, Aktualität, Ownership und Cross-Links zu prüfen, sodass Drift unvermeidlich wird
AGENTS.mdwird nicht als Enzyklopädie, sondern als Inhaltsverzeichnis behandelt- Die Wissensbasis des Repositories liegt in einem strukturierten
docs/-Verzeichnis, das als System of Record behandelt wird - Ein kurzes
AGENTS.mdmit etwa 100 Zeilen wird in den Kontext injiziert und dient als Karte, die auf tiefere Quellen der Wahrheit verweist - Designdokumente werden zusammen mit einem zentralen Satz von Überzeugungen katalogisiert und indexiert, die Verifizierungsstatus und agentenzentrierte Betriebsprinzipien definieren
- Das Architekturdokument liefert die oberste Karte von Domäne und Package-Ebenen
- Qualitätsdokumente bewerten jede Produktdomäne und jede Architekturebene und verfolgen Lücken über die Zeit
- Pläne werden als Artefakte erster Klasse behandelt: Für kleine Änderungen werden temporäre, leichte Pläne verwendet, während komplexe Aufgaben als Ausführungspläne mit Fortschritt und Entscheidungslog im Repository committet werden
- Aktive Pläne, abgeschlossene Pläne und bekannte technische Schulden werden alle versioniert und gemeinsam abgelegt, sodass Agenten arbeiten können, ohne auf externen Kontext angewiesen zu sein
- Diese Struktur ermöglicht progressive Offenlegung: Agenten starten mit einem kleinen, stabilen Einstiegspunkt und lernen, wo sie als Nächstes hinschauen müssen, statt von Anfang an überwältigt zu werden
- Dedizierte Linter und CI-Jobs verifizieren Aktualität, Cross-Links und strukturelle Korrektheit der Wissensbasis
- Ein wiederholt laufender Agent zur Dokumentationspflege findet veraltete oder obsolete Dokumente, die das tatsächliche Codeverhalten nicht mehr widerspiegeln, und erstellt PRs zu deren Korrektur
Agentenlesbarkeit als Ziel
- Da die gesamte Codebasis von Agenten erzeugt wurde, ist die Lesbarkeit für Codex das wichtigste Optimierungsziel
- So wie man Code für neue Engineers leicht navigierbar macht, besteht das Ziel menschlicher Engineers darin, Agenten den gesamten Geschäftsbereich direkt aus dem Repository erschließen zu lassen
- Alles, was aus Sicht des Agenten im Laufzeitkontext nicht zugänglich ist, existiert praktisch nicht
- Wissen in Google Docs, Chat-Threads oder den Köpfen von Menschen ist für das System nicht zugänglich; sichtbar für Agenten sind nur Code, Markdown, Schemas und Ausführungspläne als lokal versionierte Artefakte im Repository
- Selbst wenn sich das Team in einer Slack-Diskussion auf ein Architekturmuster geeinigt hat, ist dieses Wissen für einen Agenten genauso unsichtbar wie für einen neuen Mitarbeiter nach drei Monaten, wenn es nicht auffindbar ist
- Codex mehr Kontext zu geben bedeutet nicht, beliebige Anweisungen hineinzuschütten, sondern die richtigen Informationen so zu organisieren und offenzulegen, dass der Agent damit schlussfolgern kann
- Wie bei einem neuen Teammitglied, das in Produktprinzipien, Engineering-Normen, Teamkultur und sogar Emoji-Präferenzen eingearbeitet wird, führt auch die Bereitstellung dieser Informationen für Agenten zu besser ausgerichteten Outputs
- Bevorzugt werden Abhängigkeiten und Abstraktionen, die vollständig innerhalb des Repositories verankert und erschließbar sind
- Häufig ist „langweilige“ Technologie für Agenten leichter modellierbar – wegen Komponierbarkeit, API-Stabilität und ihrer Repräsentation in Trainingsdaten
- In manchen Fällen ist es günstiger, dass der Agent einen Teil einer Funktionalität neu implementiert, als das intransparente Verhalten höherer Ebenen einer öffentlichen Library zu umgehen
- Statt ein generisches Paket im Stil von
p-limitzu verwenden, wurde ein eigenermap-with-concurrency-Helper implementiert, der eng mit OpenTelemetry-Instrumentierung integriert ist, 100 % Testabdeckung hat und sich exakt im Einklang mit den Laufzeiterwartungen verhält - Je mehr vom System in eine Form gebracht wird, die Agenten direkt inspizieren, verifizieren und ändern können, desto größer wird nicht nur der Hebel für Codex, sondern auch für andere Agenten wie Aardvark, die an derselben Codebasis arbeiten
Architektur und Durchsetzung von Präferenzen
- Dokumentation allein reicht nicht aus, um Konsistenz in einer vollständig von Agenten erzeugten Codebasis zu bewahren
- Statt Implementierungen im Detail zu kontrollieren, werden Invarianten erzwungen, damit Agenten schnell ausliefern können, ohne das Fundament zu untergraben
- Von Codex wird gefordert, Datenformen an den Grenzen zu parsen, ohne den konkreten Weg dorthin vorzuschreiben
- Agenten sind am effektivsten in Umgebungen mit strikten Grenzen und vorhersagbaren Strukturen, daher ist die Anwendung um ein robustes Architekturmodell herum aufgebaut
- Jede Geschäftsdomäne ist in einen festen Satz von Ebenen aufgeteilt, und Abhängigkeitsrichtungen sowie zulässige Verbindungen werden streng verifiziert
- Diese Constraints werden mechanisch durch von Codex erzeugte Custom-Linter und Strukturtests durchgesetzt
- Innerhalb jeder Geschäftsdomäne darf Code nur vorwärts entlang der festen Ebenen
Types → Config → Repo → Service → Runtime → UIabhängen - Querschnittsthemen wie Authentifizierung, Connectoren, Telemetrie und Feature Flags dürfen nur über eine einzelne explizite Schnittstelle namens
Providerseingebunden werden - Andere Abhängigkeiten sind nicht erlaubt und werden mechanisch blockiert
- Eine solche Architektur verschiebt man normalerweise auf den Zeitpunkt, an dem es Hunderte Engineers gibt; in einer Umgebung mit Coding-Agenten ist sie jedoch eine frühe Voraussetzung, um Geschwindigkeit aufrechtzuerhalten und gleichzeitig Verfall sowie Architektur-Drift zu verhindern
- Im laufenden Betrieb werden die Regeln durch Custom-Linter, Strukturtests und einen kleinen Satz „geschmacklicher Invarianten“ durchgesetzt
- Strukturierte Logs, Namenskonventionen für Schemas und Typen, Dateigrößenlimits und plattformspezifische Zuverlässigkeitsanforderungen werden per Custom-Lint statisch erzwungen
- Die Fehlermeldungen der Custom-Lints sind so geschrieben, dass sie Korrekturanweisungen in den Agentenkontext einspeisen
- In menschzentrierten Workflows mögen solche Regeln pedantisch oder zu einschränkend wirken; in einer Agentenumgebung werden einmal kodierte Regeln jedoch zu Multiplikatoren, die überall gleichzeitig angewendet werden
- Zentral werden Grenzen, Korrektheit und Reproduzierbarkeit streng kontrolliert; innerhalb dieses Rahmens haben Teams oder Agenten große Freiheit darin, wie sie Lösungen ausdrücken
- Der resultierende Code entspricht nicht immer den Stilpräferenzen von Menschen, aber wenn er korrekt, wartbar und für künftige Agentenläufe lesbar ist, erfüllt er den Maßstab
- Menschliche Präferenzen fließen weiterhin über Review-Kommentare, Refactoring-PRs und nutzerseitige Bugs in Dokumentationsupdates oder Tools zurück
- Wenn Dokumentation nicht ausreicht, wird die Regel in Code überführt
Wie Durchsatz die Merge-Philosophie verändert
- Mit steigendem Codex-Durchsatz wurden viele bestehende Engineering-Normen kontraproduktiv
- Das Repository wird mit minimalen blockierenden Merge-Gates betrieben
- PRs werden kurz gehalten
- Test-Flakes werden oft über nachgelagerte Läufe behandelt, statt den Fortschritt unbegrenzt zu blockieren
- In einem System, in dem Agentendurchsatz die menschliche Aufmerksamkeit deutlich übersteigt, sind die Kosten für Fixes niedrig und die Kosten des Wartens hoch
- In Umgebungen mit niedrigem Durchsatz wäre ein solcher Ansatz unverantwortlich, in dieser Umgebung ist er jedoch oft der richtige Trade-off
Der tatsächliche Umfang von „agentenerzeugt“
- Wenn gesagt wird, dass die Codebasis von Codex-Agenten erzeugt wird, ist damit alles in der Codebasis gemeint
- Dinge, die der Agent erstellt
- Produktcode und Tests
- CI-Konfiguration und Release-Tools
- interne Developer-Tools
- Dokumentation und Designhistorie
- Evaluierungs-Harnesses
- Review-Kommentare und Antworten
- Skripte zur Verwaltung des Repositories selbst
- Definitionsdateien für Produktions-Dashboards
- Menschen bleiben immer im Loop, arbeiten aber auf einer höheren Abstraktionsebene als zuvor
- Menschen priorisieren Arbeit, übersetzen Nutzerfeedback in Akzeptanzkriterien und validieren Ergebnisse
- Wenn Agenten Schwierigkeiten haben, wird das als Signal behandelt, herauszufinden, ob Tools, Guardrails oder Dokumentation fehlen; auch diese Korrekturen werden von Codex geschrieben und zurück in das Repository eingespeist
- Agenten nutzen Standard-Entwicklungstools direkt, holen Review-Feedback ab, antworten inline, pushen Updates und squaschen und mergen oft sogar ihre eigenen PRs
Höheres Maß an Autonomie
- Weil Tests, Verifizierung, Reviews, Feedback-Verarbeitung und Recovery stärker in das System kodiert wurden, wurde kürzlich ein Schwellenwert überschritten, ab dem Codex neue Features von Anfang bis Ende vorantreiben kann
- Aufgaben, die der Agent mit nur einem einzigen Prompt erledigen kann
- den aktuellen Zustand der Codebasis validieren
- einen gemeldeten Bug reproduzieren
- ein Video aufzeichnen, das den Fehler zeigt
- einen Fix implementieren
- den Fix durch direkte Interaktion mit der Anwendung verifizieren
- ein zweites Video aufzeichnen, das die Lösung zeigt
- einen PR eröffnen
- auf Feedback von Agenten und Menschen reagieren
- Build-Fehler erkennen und beheben
- nur dann an Menschen eskalieren, wenn Urteilsvermögen nötig ist
- die Änderung mergen
- Dieses Verhalten hängt stark von der spezifischen Struktur und den Tools dieses Repositories ab und sollte ohne ähnliche Investitionen nicht als allgemein verallgemeinerbar angenommen werden
Entropie und Garbage Collection
- Vollständige Agentenautonomie bringt auch neue Probleme mit sich
- Codex repliziert Muster, die bereits im Repository existieren, auch wenn diese uneinheitlich oder nicht optimal sind
- Mit der Zeit führt diese Wiederholung zu Drift
- Anfangs wurde das manuell von Menschen behandelt; das Team nutzte jeden Freitag, also 20 % der Woche, zum Aufräumen von „AI slop“
- Dieser Ansatz war nicht skalierbar, daher wurden „goldene Prinzipien“ direkt im Repository kodiert und ein wiederkehrender Bereinigungsprozess aufgebaut
- Goldene Prinzipien sind meinungsstarke, mechanische Regeln, die die Codebasis für künftige Agentenläufe lesbar und konsistent halten
- Ein Beispielprinzip ist, gemeinsame Utility-Packages gegenüber handgebauten Helpern zu bevorzugen, um Invarianten zu zentralisieren
- Ein weiteres Beispiel ist, Daten nicht im „YOLO-Stil“ zu untersuchen, sondern Grenzen zu validieren oder sich auf typisierte SDKs zu stützen, damit Agenten nicht versehentlich auf Formen aufbauen, die sie nur geraten haben
- Regelmäßig scannen Hintergrund-Codex-Jobs nach Abweichungen, aktualisieren Qualitätsbewertungen und erzeugen gezielte Refactoring-PRs
- Die meisten Refactoring-PRs lassen sich in weniger als einer Minute reviewen und automatisch mergen
- Der Prozess funktioniert wie Garbage Collection
- Technische Schulden sind wie hochverzinste Kredite; fast immer ist es besser, sie fortlaufend in kleinen Einheiten abzutragen, als sie anwachsen zu lassen und später schmerzhaft auf einmal zu begleichen
- Menschlicher Geschmack kann, sobald er einmal erfasst ist, dauerhaft auf jede Codezeile angewendet werden
- Schlechte Muster lassen sich täglich erkennen und beheben, bevor sie sich über Tage oder Wochen in der Codebasis ausbreiten
Noch im Lernprozess
- Diese Strategie hat bisher für interne Releases und Einführungsschritte bei OpenAI gut funktioniert
- Der Aufbau realer Produkte für reale Nutzer hält die Investition in der Realität verankert und lenkt sie auf langfristige Wartbarkeit
- Wie sich architektonische Konsistenz in einem vollständig agentenerzeugten System über Jahre hinweg entwickelt, ist noch unbekannt
- Ebenso wird weiter gelernt, wo menschliches Urteilsvermögen den größten Hebel bietet und wie sich dieses Urteilsvermögen so kodieren lässt, dass ein kumulativer Effekt entsteht
- Auch wie sich dieses System weiterentwickelt, wenn Modelle im Laufe der Zeit leistungsfähiger werden, ist noch offen
- Klar geworden ist, dass der Bau von Software weiterhin Disziplin erfordert, diese Disziplin sich jedoch stärker im Scaffolding als im Code zeigt
- Die Bedeutung von Tools, Abstraktionen und Feedback-Loops zur Wahrung der Konsistenz einer Codebasis nimmt weiter zu
- Die derzeit schwierigste Aufgabe besteht darin, Umgebungen, Feedback-Loops und Kontrollsysteme zu entwerfen, die Agenten helfen, komplexe und verlässliche Software im großen Maßstab zu bauen und zu warten
- Je größere Teile des Software-Lebenszyklus von Agenten wie Codex übernommen werden, desto wichtiger werden diese Fragen
- Die frühen Erkenntnisse helfen dabei zu beurteilen, wo Aufwand investiert werden sollte, um einfach etwas bauen zu können
1 Kommentare
Hacker-News-Kommentare
Der Durchsatz ist auf einem absurden Niveau. Ich frage mich, welche Baseline man ansetzen sollte. Vor dem agentischen Coding, wie viele PRs erwartete man normalerweise von einem Engineer? Vielleicht 2 bis 10 pro Tag?
Ich frage mich auch, ob sich Software in den letzten 6 Monaten tatsächlich besser anfühlt. Wenn die Zahl der Engineers ähnlich geblieben ist, müsste der Iterationszyklus großer Software-Apps ungefähr 5-mal schneller geworden sein, aber so wirkt es nicht. AI-Apps ändern sich sehr schnell, aber das ist als so neues Feld erwartbar; außerhalb davon ist es kaum spürbar.
Hier sind es 1.500 PRs für 1 Million Zeilen, also ein Nettozuwachs von etwa 650 Zeilen pro PR. Das heißt nicht, dass ein PR insgesamt 650 Zeilen hat, sondern dass nach Abzug der Löschungen ein Nettozuwachs von +650 Zeilen bleibt.
Für sorgfältige Leser ergeben sich einige Fragen. Wie sieht ein Projekt in 10 Jahren aus, das pro Jahr um ungefähr eine Firefox-Codebasis wächst? Was sagt die Zeilenzahl über die Geschwätzigkeit der Werkzeuge aus, und was sagt es über das Ergebnis, dass der Zweck des Projekts nicht klar offengelegt wurde? Gibt es in einer Welt, in der Menschen den Code nicht direkt schreiben, überhaupt noch einen Grund, sich um Zeilenzahlen zu kümmern? Wenn die Codebasis viel größer wird, was passiert dann mit dem Token-Verbrauch? Falls sich bestätigt, dass LLM-Nutzung die Zeilenzahl explodieren lässt, was bedeutet das dann für eine Codebasis, die nach ein paar Monaten Nutzung wegen der Kosten wieder zum manuellen Coden zurückkehren will?
Seltsamerweise werden die meisten Einsatzfälle für „Agenten“ wieder dafür verwendet, ein anderes AI-Produkt zu bauen. Es ist Turtles all the way down. Vielleicht sagt das weniger über die Stärke von „Agenten“ aus als vielmehr über den Bereich, in dem Harness tätig ist.
Bei MS Office sieht man zuletzt viele kleine Änderungen, und die meisten nerven. Zum Beispiel verliert Word den Fokus, wenn man in Kommentaren Kollegen mit @ taggt, oder man muss in Outlook doppelklicken, um in das Suchfeld zu tippen, oder der mobile Datumswähler in Outlook scheint die Funktion verloren zu haben, gleichzeitig meine Verfügbarkeit und die der Teilnehmer anzuzeigen.
Der Durchsatz wirkt also hoch, aber leider werden dabei Funktionen kaputtgemacht, die vorher gut funktioniert haben. Oder es wird Zeit auf Unwichtiges verwendet, etwa darauf, dass die OneDrive-Suchstatusleiste um das Eingabefeld kreist.
Die meiste Zeit soll der geschriebene Code unter meiner Kontrolle am Steuer entstehen, während AI dazu dient, den Flow-Zustand zu verstärken und Blockaden zu beseitigen. Das Tool soll möglichst wenig echte Codegenerierung übernehmen.
Ich habe in den letzten 5 Monaten bei tsz[1] dasselbe Experiment gemacht und bin zu sehr ähnlichen Schlussfolgerungen gekommen. Man braucht viele Harnesses, um eine gute Architekturtrennung zu erzwingen, und außerdem viele Tests und viel CI.
Das Ziel beim Bau von tsz ist zu lernen, wie man mit AI sehr große Projekte umsetzt. Letztlich lassen sich derselbe Workflow und dieselbe Haltung auch auf kundenorientierte Produkt-Apps mit UI anwenden. OpenAI scheint sogar automatisierte Browser-Tests und Videos als Teil des Workflows zu nutzen. Je besser die Modelle werden, desto plausibler erscheint diese Richtung der Softwareentwicklung am Ende, aber ich glaube nicht, dass wir schon so weit sind. Im Gegensatz zu den vagen Behauptungen von OpenAI kann man sich hier immerhin das Ergebnis direkt ansehen, weil es geteilt wurde.
Lösungen wie Lovable, die einen sehr hohen Grad an Automatisierung bieten, sind etwas zu optimistisch und nicht eng genug mit vielen automatisierten Tests gekoppelt.
[1] https://github.com/tsz-org/tsz
Das deckt sich exakt mit meiner Vorgehensweise. Claude/Codex gibt die Mittel, die eigene Arbeit zu verifizieren: Browser, Smoke-Tests, End-to-End-Tests, hochgradig realitätsnahe lokale Umgebungen und Ähnliches.
Den gesamten Kontext, also Issue-Tracking, Dokumentation, Ideen, Pläne und Arbeitsprotokolle, lege ich im Repository ab (https://github.com/shepherdjerred/monorepo/tree/main/package...).
Ich gebe Claude/Codex Zugriff auf Observability-Tools wie Grafana, Prometheus, Tempo und PagerDuty und lasse gute Engineering-Richtlinien befolgen, etwa schnelles Scheitern, Typsicherheit und Parsing an den Grenzen.
Vollständige Autonomie habe ich im Homelab wegen der Kosten und der CI-Last aber noch nicht erreicht.
Ich habe vor Kurzem ein Video über Arbeiter in einer E-Zigaretten-Fabrik gesehen. Sie greifen sich am Fließband ein Bündel E-Zigaretten, ziehen etwa 5 Sekunden kräftig daran und testen dann das nächste Bündel. Menschen, die bei AI-generierten PRs Änderungen über Hunderte von Zeilen prüfen, unterscheiden sich davon gar nicht so sehr.
Bei PRs ist das nicht so. Ein einziges schlechtes PR kann für das Geschäft verheerend sein, ein einzelnes schlechtes E-Zigaretten-Produkt normalerweise nicht.
Außerdem würde ich sagen: Wenn Software-Engineers die AI-Ausgaben stichprobenartig prüfen, dann erfüllt die aktuelle Qualität den gewünschten Standard für ein Produkt noch nicht konstant genug. Deshalb muss man jedes PR reviewen und einen erheblichen Teil davon korrigieren.
Wenn man den Wirkungsbereich von Änderungen begrenzen kann und die Ausgabe im Allgemeinen auch ohne Aufsicht akzeptabel genug wird, sodass man in der Fabrik nur noch doppelt prüft, dass es keine Regressionen gibt, dann könnte ein Stichprobenansatz funktionieren.
Ich bin eine der drei Ingenieurinnen bzw. einer der drei Ingenieure, die diesen Artikel geschrieben haben. Wenn es Fragen gibt, kann ich sie beantworten.
Ich bin kein AI-Skeptiker, aber ich zweifle an der Absicht dieses Artikels. Er trifft große Aussagen über Agent-First-Engineering auf Grundlage eines realen Produkts, realer Nutzer und eines real wachsenden Teams und lässt es wie ein echtes Fallbeispiel aussehen, sagt oder zeigt aber nicht einmal, was gebaut wurde. Genau wie all die anderen AI-Hype-Artikel.
Das kann nur mit unendlichen Rechenressourcen und unendlichen Tokens funktionieren.
Aus meiner Erfahrung mit dem 20-$-Plan ist so ein rein agentischer Ansatz unmöglich. Man stößt schnell an die Limits und bekommt dabei auch noch weniger Ergebnisse.
Was bei mir sehr gut funktioniert hat: von Menschen geschriebenen Code als Referenz bereitzustellen und das Modell anzuweisen, ihn zu erweitern. Man legt die grobe Struktur fest, entwirft die Architektur und schreibt ein paar Beispielstücke für Controller, Services, Modelle, Komponenten, Datenbankschema und Authentifizierung, damit das LLM ein Sprungbrett hat, an dem es seine Aufmerksamkeit ausrichten kann.
Normalerweise schreibe ich Stubs, die die Implementierung detailliert beschreiben. Das ist wie Pseudocode auf einer höheren Abstraktionsebene. Dann bitte ich das LLM um die Implementierung.
Wenn es scheitert, ist es oft besser, die gesamte Änderung rückgängig zu machen, den Stub so anzupassen, dass der vorherige Fehler erkannt wird, und es dann noch einmal zu versuchen.
Oder man committet die Änderung und lässt es im neuen Kontext nur die falschen Teile behandeln.
Wenn ich es von Anfang an agentisch versuche, bin ich sowohl von den Ergebnissen als auch von den Limits immer enttäuscht. Manchmal erreicht man die Limits schon vor Ablauf einer Stunde.
Mit dem Upgrade auf 200 $ im Monat kann man mehr nutzen, aber selbst für jemanden wie mich, der es intensiv verwendet, reicht das Nutzungsvolumen nie aus.
Ich beneide immer noch die Leute, die 200-faches Nutzungskontingent bekommen haben, nur weil sie auf eine OpenAI-Party mit RSVP geantwortet haben.
Wieder ein atemloser Vertriebsartikel. Wie beim Verkauf von Spitzhacken an Goldgräber: Aber wo ist das Gold? Wo sind die tatsächlich geschaffenen erstaunlichen Produkte, die aus Chatbots hervorgegangen sind, die auf Git miteinander sprechen und Berge von Codezeilen erzeugen? Ich sehe überhaupt keine.
Ich wünschte, diese aufgeregten Blogposts wären etwas lehrreicher.
Zum Beispiel sollten sie Schritt für Schritt zeigen und konkret demonstrieren, wie man den Workflow einrichtet, von dem behauptet wird, er sei so mächtig.
Ich bin kein AI-Skeptiker. Im Gegenteil: Wenn es hier echte Superkräfte gibt, möchte ich sie nicht verpassen.
Für neue Features schreibe ich Gherkin-Feature-Spezifikationen, für Verbesserungen aktualisiere ich sie, und für Refactorings fasse ich sie nicht an. PRs versehe ich mit Labels auf Basis dieser Begriffe.
In einem Pre-Push-Hook lasse ich Typprüfung, Linting, Unit-Tests und andere schnelle, skriptbare Prüfungen laufen.
Ich erstelle im Repository eine VitePress-Subsite und lasse sie vom Agenten pflegen. Dort dokumentiere ich wichtige Prinzipien, die Architektur und Ähnliches.
Ich baue einen CLI-Befehl, der alle Seiten und YAML-Frontmatter-Beschreibungen auflistet, damit der Agent auswählen kann, was er lesen soll, ohne das Kontextfenster zu sprengen.
Ich verwende Domain-Driven Design und ein Monorepo. Logik wird in einer Headless-Schicht geschrieben, und die Schichten werden zu Apps zusammengesetzt. Agenten navigieren sehr gut durch Schichten.
Ich nutze zod oder ein entsprechendes Werkzeug in der jeweiligen Sprache sowie vertragsorientierte API-Entwicklung. Persönlich gefällt mir dieser Teil am besten, und ich verwende orpc.
Ich erstelle nur einen einzigen Skill namens „code“ und beschreibe darin den Lebenszyklus. Einen Worktree öffnen,
.envso setzen, dass es nicht mit anderen Agenten kollidiert, ungenutzte Ports auswählen, wofür Docker gut ist. Die Feature-Datei schreiben oder aktualisieren, dort die Spezifikation abstimmen, dann implementieren, mit etwas wie playwright mcp verifizieren, die Prüfungen vor dem Push ausführen, nach dem Push auf Review warten, aufräumen und dannmainper Fast-Forward mergen.testcontainers eignet sich gut, um sicherzustellen, dass mehrere Agenten Tests ohne Konflikte ausführen können.
Im Ernst, es gibt nur einen Skill. Alles andere steht in den Dokumenten. Es fühlt sich sehr produktiv an, nicht im Sinn von Zeilen Code, sondern im Sinn von „gute Software bauen“.
Dafür habe ich den Agenten jedes Mal, wenn er auf ein Problem stieß, gefragt, wie man es mithilfe von Validierungswerkzeugen oder Skripten lösen könnte. Während des Audit-Prozesses ließ ich ihn solche Werkzeuge auch selbst programmieren. Das Ergebnis ist, dass es inzwischen mehr als 30 Regeln für die Commit-Validierung gibt[2], und sie funktionieren ziemlich gut.
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (Um den „Demo“-Modus zu sehen, lässt man einfach den Timer ablaufen.)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Das haben wir anfangs ausprobiert. Bevor wir Code geschrieben haben, haben wir ChatGPT als „Projektmanager“ eingesetzt und das komplette Harness aufsetzen lassen. Eine Woche später gab es mehr als 140 Dokumente zu Regeln, Architektur und Frameworks – und 0 Zeilen Code
Als wir es später von einem anderen Tool prüfen ließen, lautete das Urteil: „ein perfekt sicherer leerer Tresor“. Das Harness war makellos, aber darin war nichts
Das Harness ist wichtig, aber wenn es nicht parallel zum Release von Code entsteht, schreibt man im Grunde nur Fiktion