Todd Saunders hat letzte Woche etwas geschrieben, das mich nicht mehr loslässt: Das Meeting, in dem sein Team über ein Feature diskutiert hat, war teurer als das Feature selbst. Sechs Leute, eine Stunde, Tagessätze zusammengerechnet. Der Agent hat das Feature danach in zwanzig Minuten gebaut.
Das ist kein Einzelfall. Dass Code billig geworden ist, habe ich hier schon beschrieben. Aber Saunders’ Beobachtung trifft einen wunden Punkt. Die Frage ist nicht mehr: Was kostet uns die Implementierung? Die Frage ist: Was kostet uns der ganze Prozess drumherum?
Prozesse aus einer anderen Welt
Sprint Planning, Estimation Sessions, Approval Chains, mehrstufige Reviews. Alles Werkzeuge, die für ein bestimmtes Problem erfunden wurden: Entwicklungszeit war teuer und fehleranfällig. Also hat man geplant, priorisiert, abgesichert. Jede Stunde Coding musste sich lohnen.
Das war sinnvoll. In einer Welt, in der ein Fehlversuch Wochen Arbeit und tausende Euro gekostet hat, war Planung die billigste Versicherung.
Nur: Diese Welt gibt es nicht mehr. Ein Agent baut ein Feature in zwanzig Minuten. Wenn es nicht passt, baust du es nochmal. Und nochmal. Bevor das alte Team seinen ersten Sprint Review hätte, hast du drei Varianten getestet und die beste ausgerollt.
Der Preis für einen Fehlversuch ist fast null geworden. Aber die Prozesse, die diesen Preis absichern sollten, kosten genauso viel wie früher.
Von der Pipeline zum lebenden System
Der klassische Software Development Lifecycle (SDLC) ist eine Pipeline: Planen, Coden, Testen, Deployen. Schritt für Schritt, Phase für Phase. Jede Stufe wartet auf die vorherige. Ändern sich die Anforderungen mittendrin, bricht der Zeitplan.
Was gerade entsteht, funktioniert grundlegend anders. Agenten planen, schreiben Code, testen und deployen nicht nacheinander, sondern gleichzeitig. Mehrere Teilaufgaben laufen parallel. Feedback kommt in Echtzeit zurück, nicht erst am Ende eines Sprints. Anforderungen können sich ändern, ohne dass alles neu geplant werden muss.
Die Ergebnisse sind messbar. Rakutens Engineering-Team hat die Zeit von der Idee bis zum fertigen Feature von 24 Tagen auf 5 reduziert. Nicht durch schnelleres Tippen, sondern weil ihre Engineers vier Agenten parallel arbeiten lassen, während sie selbst die fünfte Aufgabe übernehmen. Bei Google wird inzwischen rund die Hälfte des neuen Codes von AI-Agenten generiert. Die Wartezeiten zwischen den Phasen fallen weg. Komplexe Implementierungen, die früher Tage gebraucht haben, entstehen in Stunden.
Die Verschiebung passiert auf mehreren Ebenen gleichzeitig: Fixe Pläne werden zu laufend aktualisierten Zielen. Sequenzielle Übergaben werden zu parallelen Arbeitssträngen. Tests nach der Entwicklung werden zu kontinuierlichen Tests während der Entwicklung. Und statt einer Retrospektive am Ende des Projekts gibt es live Feedback, das sofort zurückfließt.
Zwei Ansätze, ein Prinzip
Wie arbeiten Teams, die das begriffen haben? Ich sehe zwei Muster, die auf den ersten Blick gegensätzlich wirken.
Umgebungen bauen statt Code schreiben. OpenAI hat kürzlich beschrieben, wie sie ihren Entwicklungsprozess umgebaut haben. Sie nennen es “Harness Engineering”. Die Idee: Engineers schreiben keinen Code mehr. Sie bauen die Umgebung, in der Agenten arbeiten. Konkret heißt das: klare Ziele definieren, automatische Qualitätschecks einrichten, Leitplanken setzen, innerhalb derer Agenten sich frei bewegen dürfen. Statt dem Agenten alles auf einmal zu erklären, bekommt er ein Inhaltsverzeichnis und schlägt selbst nach, was er braucht.
Ein Detail fand ich besonders aufschlussreich: Je mehr Agenten produzieren, desto schneller verfällt eine Codebase, wenn niemand aufräumt. OpenAIs Lösung: unverrückbare Grundprinzipien als Leitplanken, dazu automatisierte Aufräum-Agenten, die den Code ständig gegen diese Prinzipien prüfen. Der Aufwand ist real. Aber er fließt in die richtige Stelle: in die Umgebung, nicht in die Implementierung einzelner Features.
Radikal weglassen. Der Entwickler sysls hat das Gegenteil probiert. Je mehr Tools, Regeln und Kontext er seinen Agenten gegeben hat, desto schlechter wurden die Ergebnisse. Der Agent hat sich in den Informationen verloren und schlechtere Entscheidungen getroffen. sysls’ Lösung: alles rauswerfen, was nicht unmittelbar nötig ist. Weniger Abhängigkeiten, kürzere Anweisungen, fokussierte Aufgaben.
Auf den ersten Blick widersprechen sich die beiden Ansätze. Auf den zweiten lösen sie dasselbe Problem: Der Agent braucht die richtigen Informationen zur richtigen Zeit. Nicht alles auf einmal, nicht zu wenig. OpenAI erreicht das durch Struktur, sysls durch radikales Kürzen. Der gemeinsame Nenner: Präzision beim Kontext.
Wer den Artikel über Agent-Orchestrierung gelesen hat, kennt das Grundprinzip. Hier geht es einen Schritt weiter. Nicht nur Agenten Aufgaben zuweisen, sondern den gesamten Arbeitsprozess so umbauen, dass Agenten sich darin zurechtfinden.
Wie sieht das in der Praxis aus?
Elvis Sun, Solo-Founder und bekannt für seine Arbeit mit AI-Agenten, beschreibt seinen Alltag so: Kein Sprint Planning. Kein tägliches Standup mit fünfzehn Leuten. Stattdessen definiert er Ziele und Einschränkungen. Mehrere Agenten arbeiten parallel an Teilproblemen. Er prüft die Ergebnisse, korrigiert die Richtung, lässt weiterarbeiten.
Das klingt nach einem Sonderfall. Ein Solo-Entwickler, kein Konzern. Aber das Muster taucht auch auf Unternehmensebene auf.
Ramp, das am schnellsten wachsende Fintech der USA, hat seine gesamte Organisation um AI herum neu gebaut. Über die Hälfte ihres Codes wird bereits von Agenten geschrieben, Tendenz 80 bis 90 Prozent. Aber der eigentliche Wandel liegt woanders: Ramp hat interne Agenten gebaut, die ganze Arbeitsprozesse übernehmen. Ein “Voice-of-Customer”-Agent analysiert Kundenfeedback und leitet Patterns direkt an die Produktteams weiter. Ein Analyst-Agent erstellt Reports, für die früher ein ganzes Team Tage gebraucht hat. Und ihre Produktmanager? Die bauen inzwischen selbst Features. Nicht weil sie plötzlich programmieren gelernt haben, sondern weil die Grenze zwischen “definieren” und “bauen” verschwimmt, wenn Code fast nichts mehr kostet.
Ramps CTO bringt es auf den Punkt: Software, wie wir sie kennen, wird zu “Co-Workern”. Nicht Tools, die man bedient, sondern Agenten, die mitarbeiten. Das verändert nicht nur, wie Code entsteht. Es verändert, wer was tut und welche Rollen überhaupt noch Sinn ergeben.
Elvis Sun als Einzelperson, Ramp als Unternehmen. Zwei völlig unterschiedliche Größenordnungen, aber dasselbe Muster: Wer seine Organisation um Agenten herum baut, verändert nicht nur die Geschwindigkeit. Es verschieben sich die Rollen, die Teamstrukturen, die ganze Frage, was “Produktentwicklung” eigentlich bedeutet. Produktmanager, die selbst Features bauen. Agenten, die Kundenresearch übernehmen, die früher Wochen gedauert hat. Strategische Entscheidungen, die auf Live-Daten basieren statt auf Quartalsreviews.
Das ist kein inkrementeller Fortschritt. Das ist ein anderes Organisationsmodell.
Was jetzt zählt
Wir wissen noch nicht, wie der ideale Prozess für diese neue Welt aussieht. Harness Engineering ist ein Ansatz, radikaler Minimalismus ein anderer. Vermutlich wird es eine Mischung, die je nach Team anders aussieht.
Was wir wissen: Der Vorteil liegt nicht darin, alles vorher perfekt durchzudenken. Er liegt darin, schneller zu lernen, was funktioniert. Bauen, ausprobieren, verwerfen, nochmal bauen. Die Kosten dafür sind fast null. Die Kosten für ein zweistündiges Meeting mit acht Leuten sind es nicht.
Schau dir deinen Kalender an. Welche Meetings sind teurer als das, was sie produzieren? Welche Approval-Prozesse sichern Risiken ab, die es nicht mehr gibt? Welche Planungsrunden planen Dinge, die ein Agent in einer Stunde gebaut hätte?
Die Teams, die das am schnellsten begreifen, werden nicht die mit den besten Agents sein. Sondern die, die ihre Prozesse am konsequentesten um die neue Realität herum gebaut haben.