15.700 Agent-Sessions später: David Ondrejs Workflow für Agenten

Agenten-Workflows kursieren massenhaft im Netz, meist aus Moodboards zusammengesetzt: zehn Sub-Agents, drei Dashboards, ein hübsches Diagramm. David Ondrej macht in seinem aktuellen Video das Gegenteil. 'My Agentic Engineering Workflow (after 15,700 sessions)' ist ein Update nach zwei Monaten, und der Unterschied zum Vorgänger ist gravierend: Wo die erste Fassung noch fast 200.000 Views einsammelte, dreht sich diesmal fast alles um Disziplin statt Tooling. Im Video nennt er über 2.500 Stunden AI-Coding in vier Jahren und drei gebaute AI-Startups als Basis. Das eigentliche Herzstück ist ein Review-Konzept: Er lässt die eigene Session-Historie von Opus analysieren, zählt die laufenden Agent-Threads als harte Zahl und baut daraus einen Prozess, der ohne Human in the Loop funktionieren soll. Ich betreibe selbst Agenten dauerhaft, und drei Punkte aus dem Video decken sich exakt mit dem, was ich im Agenten-Alltag sehe: Sessions als Ein-Task-Einheiten, Cross-Review durch ein zweites Frontier-Modell, und die Diagnose, dass neun von zehn Agent-geschriebenen Tests wertloser Slop sind.

Die Modell-Käufe behandelt er im Einstieg fast en passant. Für ihn ist Anthropic Opus 5.5 derzeit das beste Modell, schnell und zuverlässig, bei ihm sind gleich beide Abonnements verbraucht, er scherzt über einen dritten Account. Bei OpenAI wägt er zwischen Astra und Soul und gibt Astra den Vorzug, weil es den Frontier-Anspruch überzeugen kann. Google, Meta und Kimi-Modelle nennt er brauchbar, aber nicht Frontier: gut genug, um sie für konkrete Aufgaben einzuspannen, aber nicht die erste Wahl. Interessanter als diese Liste ist seine These zur Architektur: Der Harness verliert an Bedeutung. Ondrej arbeitet derzeit mit pi, Claude Code, Hermes und Open Code, und der Punkt, den er von zwei Anthropic-Ingenieuren bei einem Office-Event mitgebracht hat, ist simpel: Wenn ein starkes Modell Terminal-Zugriff und Internet bekommt, laufen die Unterschiede zwischen den Harnesses praktisch leer, ob Devvin, Droid oder Claude Code. Für den Dauerbetrieb heißt das: In Session-Standards investieren, nicht in Tool-Sammlungen.

Der Kern seines Prozesses ist eine Session-Discipline, die in Videos oft unterschätzt wird. Jeder Agent-Thread bekommt genau eine Aufgabe, eine Feature-Änderung, einen Bugfix, einen Recherche-Auftrag. Nichts wird gemischt, braucht es einen neuen Fokus, gibt es einen Fork in einen neuen Thread. Als Anhaltspunkt nennt er einen Moment, in dem sein OBS-Studio während der Aufzeichnung abgestürzt war und ein eigener Thread genau diese Reproduktion gefahren ist. Bugs durchläuft bei ihm erst eine Reproduktion wie bei einem echten User: Simulation, Test, Experiment, bis der Fehler sicher steht. Erst dann baut das Frontier-Modell den Fix, bei ihm Opus 5.5, hängt Checks und bei sichtbaren Änderungen Screenshots der echten App an. Screenshots als Beweis für UI-Änderungen sind für ihn ein eigener Kraft-Aktivposten, nicht Deko. Nach Bug-Fixes folgen Tests, Security-Checks und ein Review-Loop, dann geht der Pull Request in den Main. Wer die Session-Discipline ignoriert und Agent-Threads mischt, zahlt die Rechnung in unübersichtlichen Diff-Chaos, weil der Kontext des einen Tasks den Kontext des anderen versaut.

Der zweite Block seines Prozesses ist die Bewertung der Agent-Ausgaben. Ondrej nennt die Zahl, auf die es ihm ankommt: Er bringt es fertig, 100 bis 200 Beiträge am Tag in Produktion zu bringen, das sind laut eigener Zählung über 700 Commits pro Woche, sichtbar auf seinem GitHub-Profil. Wie hält man das ohne Qualitätsverlust? Sein Trick heißt Cross-Review: Bei kleinen Änderungen reicht ein Standard-Review, bei schweren Änderungen liest ein zweites Frontier-Modell mit hohem Denk-Budget den Patch gegen. Der Punkt ist nicht das konkrete Tool, sondern der Loop: Cross-Review findet die Fehler, die der erste Agent übersehen hat; wenn der Review-Loop etwas findet, folgt ein Re-Review, bis der Fix sauber ist, dann geht der Pull Request wieder in den Main und ein eigener Loop fängt Nebenwirkungen und Security-Probleme ab. Er betont zugleich ein Warnsignal: Wer Review-Texte ohne eigenen Blick akzeptiert, produziert Slop, und ein Reviewer, der dauerfeuert, wird bei ihm selbst wieder Gegenstand der Prüfung, statt blind befolgt zu werden.

Den am häufigsten missverstandenen Punkt des Themas behandelt er als Kontrafaktum. Er zitiert die Diagnose, dass Sub-Agent-Orchestrierung 'Astrologie für Vibe-Coder' geworden ist, und legt die Grenze hart: Sub-Agents sind genau dann sinnvoll, wenn der Job klar, parallelisierbar und in gleichförmige Chunks teilbar ist. Klassische Fälle: 2.000 Dokumente klassifizieren, die eigene Agent-Historie auswerten, ein Paket PDFs strukturieren. Dann ist das Muster ein starker Main-Agent und zehn bis zwanzig kleine Sub-Agents in Parallel-Sessions, zum Beispiel Haiku-Klassen-Modelle, der Main-Agent sammelt die Ergebnisse und entscheidet weiter. Genau das Gegenteil gilt bei Innovationsarbeit: Wer Neues baut, hat Dead-Ends, Umwege und unerwartete Kopplungen im Code, und dafür braucht es ein Frontier-Modell mit vollem Kontext. Der Sub-Agent-Fluch bei unbekanntem Terrain: Der kleine Agent fixt einen Bug, merkt mitten im Patch, dass der Bereich mit Billing gekoppelt ist, und arbeitet blind weiter, weil der Kontext fehlt, den der Main-Agent hätte. Das Deckmuster ist simpel: Je unvorhersehbarer der Job, desto weniger Sub-Agents, desto mehr Kontext beim Main-Agent.

Zwei weitere Punkte aus dem Video verdichten das Bild. Erstens der Slop-Befund bei Tests: Ondrej ist bekennender Testskeptiker, weil seiner Rechnung nach über 90 Prozent der Tests, die ein Agent schreibt, kompletter Slop sind, Code, der nur existiert, um grün zu leuchten, ohne etwas zu verifizieren. Sein Korrektiv ist Selektion statt Menge: strategische Tests an echten Regressionspunkten, kritische Nutzerpfade, Sicherheitsfragen, und der Rest Vertrauen in den Review-Loop. Wer zulässt, dass Agents tausende Zeilen Test-Code erzeugen, bekommt eine Suite, die dauer-Alarm schlägt und trotzdem nichts beweist, seine Formulierung im Video: Tests werden geschrieben, um den Test zu bestehen, nicht um etwas zu prüfen. Zweitens die Quantifizierung: Er rät, die eigene Produktivität messbar zu machen, statt auf Bauchgefühl zu vertrauen, GitHub-Chart als harten Proxy, weil viele Menschen sonst internes Tooling bauen und sich einbilden, produktiver zu sein, während der eigentliche Output stehen bleibt. Sein eigener Aufbau: erst wenig Muster im Chart, ab dem späten Frühjahr Aufnahme der Agent-Arbeit, seit September und Oktober der steile Anstieg durch Cloud-Agents, das wächst aus seiner Sicht exponentiell weiter.

Rahmen des Videos ist die Idee der selbstverbessernden Software-Fabrik: Software, die mit jedem User und jedem gemeldeten Fehler besser wird, weil Agenten die Reparatur übernehmen, prüfen und weiterrollen. Sein Methoden-Metamoment gehört dazu: Er hat Opus per Room-CLI seine eigenen Sessions auswerten lassen, über 550 laufende Threads im Moment der Analyse, am Vortag über 800, in den Wochen davor buchstäblich tausende, und aus dem Muster dieser Analyse ist die Workflow-Beschreibung entstanden, die er im Video zeigt. Interviewt hat er nach eigener Aussage unter anderem den CEO von Vercel, den CTO von Supabase und den CTO von Fireworks; die Fragen, die ihm dabei begegnet sind, laufen auf dieselben zwei Variablen hinaus: Session-Discipline und verifizierte Ausgaben. Alles andere, Modellnamen, Harness-Anklickbarkeit, Sub-Agent-Deko, ist in seinem Setup Nachrang. Ondrej erwähnt auch Windows-Support für sein Tool Cloud Room als Tagesneuigkeit, für ihn Nebensache, für den Betrieb von Agenten auf gemischten Setups praktisch relevant.

Was bleibt, ist ein Setup, das sich ohne Cloud Room nachbauen lässt, in jedem Harness mit Multi-Session und Terminal-Zugriff, auch in Hermes und pi. Sessions als Ein-Task-Einheiten, ein Frontier-Modell mit vollem Kontext als Arbeitspferd, Cross-Review durch ein zweites Frontier-Modell, Sub-Agents nur für parallele Chunks, Agenten, die von Usern gemeldete Fehler selbst beheben und die eigenen Outputs verifizieren. Ondrej betont, dass er diesen Zustand noch nicht erreicht hat, der Mensch hängt in seinem Loop noch drin, das ist der nächste Ausbauschritt Richtung 2027. Solche Videos leben von der Zahl im Titel, hier zählt die Zahl, weil sie etwas Konkretes markiert: die Sessions-Historie, aus der der Workflow abgeleitet wurde, nicht erfunden. Für mich als Bestätigung lesbar: Session-Discipline und Cross-Review funktionieren im Dauerbetrieb, die Harness-Entscheidung ist Nebensache, sofern Terminal und Internet da sind. Die Slop-Diagnose für Test-Suiten ist die Stelle, an der die meisten Agent-Setups gerade scheitern, und der Punkt, an dem Cross-Review mehr bringt als jede neue Orchestrierungs-Kaufberatung.