Harness Engineering: Was passiert bei 1 Milliarde Tokens pro Tag
Ryan Lopopolo arbeitet bei OpenAI im Bereich Frontier Product Exploration. Zuvor war er bei Snowflake, Brex, Stripe und Citadel. In einem Talk fuer Latent Space beschreibt er ein fuenf Monate altes Projekt mit bemerkenswerten Kennzahlen:
- 1 Million Lines of Code in einem neuen Repository
- 1 Milliarde Tokens pro Tag Verbrauch (~2.000-3.000 USD taeglich)
- 0% menschlich geschriebener Code
- 0% menschliches Code-Review vor dem Merge
- 1.500+ Pull Requests, verwaltet von drei Ingenieuren
Die zentrale These: Die Rolle des Entwicklers verschiebt sich vom Code-Schreiben zum Systemdesign fuer autonome Agenten.
Was ist Harness Engineering?
Harness Engineering bedeutet, die gesamte Infrastruktur -- Build-Systeme, Dokumentation, Tests, Observability -- so zu gestalten, dass Coding-Agenten autonom arbeiten koennen. Der Fokus liegt nicht auf besseren Prompts, sondern auf der Frage: Welche Faehigkeit, welcher Kontext oder welche Struktur fehlt dem Agenten?
Der Unterschied zu normalem AI-gestuetztem Coding:
| Normales AI-Coding | Harness Engineering |
|---|---|
| Mensch schreibt Code, AI assistiert | Agent schreibt Code, Mensch baut Infrastruktur |
| Prompt-Optimierung bei Fehlern | Systemische Analyse: Was fehlt dem Agenten? |
| Code-Review durch Menschen | Autonomes Multi-Agent-Review |
| Menschliche Lesbarkeit priorisiert | Agent-Lesbarkeit priorisiert |
| Einzelne Aufgaben delegiert | Gesamter PR-Lifecycle delegiert |
Lopopolo beschreibt eine bewusste Entscheidung: Er weigerte sich, selbst Code zu schreiben. Wenn der Agent scheiterte, wurde nicht der Prompt verbessert, sondern das System drum herum.
Die Architektur
Spezifikationen statt Implementierungen
Das Team arbeitet mit sogenannten "Ghost Libraries" -- Software wird als hochpraezise Spezifikation verteilt, nicht als fertige Implementierung. Agenten rekonstruieren den Code lokal aus Specs. Zentrale Dokumente:
- SPEC.md: Fachliche Anforderungen
- AGENT.md: Agentenspezifische Instruktionen (~100 Zeilen)
- TECH_TRACKER.md: Markdown-Tabelle mit Business-Logik und Leitplanken
- QUALITY_SCORE: Selbstbewertungsmechanismus fuer den Agenten
Ein-Minuten-Build-Constraint
Harte Regel: Kein Build darf laenger als eine Minute dauern. Wird die Grenze ueberschritten, wird die Codebasis zerlegt -- bis sie wieder darunter liegt. Das erzwingt modulare Architektur (500+ NPM-Pakete bei sieben Ingenieuren) und haelt Agenten produktiv.
Der End-to-End-Workflow
- Mensch erstellt Ticket in Linear
- Symphony (Elixir-basierter Orchestrator) startet einen Agenten mit Ticket-Kontext, Repo-Spec und Skills
- Agent schreibt Code, fuehrt Tests aus, committet in einen Git-Worktree
- Agent erstellt Pull Request
- Separater Review-Agent prueft den PR autonom
- Author-Agent und Review-Agent verhandeln ueber Feedback
- Agent loest Merge-Konflikte, fixt Flaky Tests, merged autonom
- Menschen samplen Post-Merge-Code und aktualisieren Specs/Skills
- Mensch gibt Release-Branch frei nach Smoke Tests
Multi-Agent-Review
Schreiben und Review werden von unterschiedlichen Agenten uebernommen. Beide koennen verhandeln: Reviewer tendieren zu P2-Issues (nicht-kritisch), Autoren koennen Feedback zurueckweisen oder aufschieben. Ueber 90% der PRs werden ohne menschliches Eingreifen gemerged.
Kernerkenntnisse fuer Entwickler
1. Code ist Wegwerfware
Gescheiterte Versuche werden komplett verworfen und neu gestartet. Kein Attachment an Implementierungen -- der Agent beginnt bei Null, wenn ein PR scheitert. Das funktioniert, weil die Spezifikation das bestaendige Artefakt ist, nicht der Code.
2. Menschen sind der Engpass
Tokens sind billig, synchrone menschliche Aufmerksamkeit ist knapp. Die Produktivitaetssteigerung kommt nicht aus schnellerem Code-Schreiben, sondern aus dem Wegfall menschlicher Bottlenecks wie Code-Review und Merge-Genehmigungen.
3. Schreib fuer das Modell, nicht fuer Menschen
Codestruktur, Benennung und Modularitaet muessen Agent-Verstaendlichkeit priorisieren. Lopopolo formuliert es so: "Code is context, code is prompts. Give agents instructions."
4. Observability ist nicht optional
Agenten brauchen vollstaendige Sichtbarkeit in das Systemverhalten, um Fehler selbst zu diagnostizieren und zu reparieren. Das Team betreibt einen lokalen Stack mit Victoria Metrics, Prometheus und Jaeger.
5. Eine Zeile Dokumentation skaliert
Ein einzelner Satz in der Reliability-Dokumentation -- "require timeouts on all network calls" -- kodiert Wissen dauerhaft ueber alle zukuenftigen Agentenlaeufe hinweg. Spezifikationen sind der Hebel, nicht individuelles Code-Review.
6. Investition zahlt sich spaet aus
Der erste Monat war zehnmal langsamer als menschliche Solo-Entwicklung. Die Produktivitaet kam erst, nachdem Build-Systeme, Modularisierung und Dokumentation standen. Danach: fuenffache Geschwindigkeit gegenueber reiner Menschenarbeit.
Grenzen des Ansatzes
- Nur Greenfield: Der Ansatz funktioniert fuer neue Repositories. Die Anwendbarkeit auf Legacy-Codebasen ist unklar.
- Keine kreativen Spruenge: Agenten kaempfen mit neuartiger Produktideation. Zero-to-One-Arbeit braucht weiterhin Menschen.
- Komplexe Refactorings: Architekturelle Umbauten erfordern menschliche Steuerung und Zerlegung.
- Skalierung: Drei Personen, taegliche 45-Minuten-Standups. Ab groesseren Teams braucht es rigide architekturelle Grenzen.
Einordnung
Lopopolo beschreibt seine neue Rolle als "Group Tech Lead einer 500-Personen-Organisation" -- strategische Steuerung statt Zeile-fuer-Zeile-Review. Das ist ein Extremfall: OpenAI-interne Token-Budgets, Greenfield-Projekt, drei erfahrene Ingenieure.
Die uebertragbaren Prinzipien -- Build-Zeiten minimieren, Spezifikationen als Source of Truth, Observability fuer Agenten, modulare Architektur -- gelten aber auch bei weniger extremem Token-Einsatz.