Kazuaki Okumura (Dropbox) greift in diesem Beitrag vom 28. Mai 2026, einem Rückblick auf einen Vortrag auf der DX Annual 2026, eine kontraintuitive These auf: « AI doesn't eliminate bottlenecks in software development, but it does move them ». Jahrelang zielte Engineering-Produktivität darauf ab, Reibung im SDLC zu reduzieren, und KI-Tools darauf, die Implementierung zu beschleunigen. Doch mit ihrer Skalierung bei Dropbox zeigte sich, dass « accelerating code generation simply shifted some bottlenecks downstream »: Je schneller Code sich bewegt, desto mehr Druck entsteht bei Review, CI, Validierung, Release-Koordination und Produktionsbetrieb.

Der Wandel Copilot → Agent verändert das Interaktionsmodell: Der Agent übernimmt eine eingegrenzte Aufgabe, prüft den Code, bearbeitet ihn, führt Tests aus, iteriert bei Fehlschlägen und liefert ein Artefakt zur menschlichen Prüfung zurück — wobei der Engineer weiterhin für Intent, Architektur, Qualität und Release-Entscheidungen verantwortlich bleibt. Illustration: Nova, Dropboxs interne Agentenplattform, die bereits rund 1 von 12 PRs ausmacht und sich auf Migrationen, flakige Tests, Bug-Untersuchungen und Dependency-Updates erstreckt. Zentrale Erkenntnis: « Nova's value comes less from the model itself than the systems surrounding it » (Codebase-Kontext, interne Praktiken, sichere Ausführung, Workflow-Integration, menschliche Prüfung).

The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together.

— **Kazuaki Okumura** — Dropbox , dropbox.tech

Daraus folgt ein Überdenken der Messung: PR-Durchsatz reicht nicht mehr aus. Dropbox übernimmt ein vierstufiges Modell — Fuel → Adoption → Output → Impact —, das von der Tool-Nutzung bis zum Kundennutzen reicht (idea → customer value), mit Qualitätssignalen (Durchlaufzeit des Code-Reviews, Erfolgsquote von Tests im ersten Durchlauf, Fehlerquote, Nacharbeitsquote). « Quality and trust matter as much as speed »; der Wandel besteht darin, « moving from local activity metrics toward broader system outcomes ».

Auf Workflow-Seite ist dies « not just a tooling shift »: Das Betriebsmodell verändert sich, die Rolle des Engineers verschiebt sich hin zu Intent, Problemkartierung, Review und Architekturentscheidungen — daher die Bedeutung von Enablement (Hackathons, Bootcamps, von Peers geleitete Beispiele) und einer risikoabhängig abgestuften Adoption (« the goal is not to force every workflow through an agent »). Der Druck verlagert sich auch stromaufwärts zu Produkt und Design (Specs, Problemformulierung).

Letzte Erkenntnis: Der Vorteil « will not come from access to the same foundation models », sondern « from the systems built around those models ». « The future of engineering productivity… will be defined by who builds the best systems around them. » Ein bedeutender Beleg eines großen Operators für den Wandel von Output zu Outcome.