Kazuaki Okumura (Dropbox) reprend, dans ce billet du 28 mai 2026 issu d'un talk DX Annual 2026, une thèse contre-intuitive : « AI doesn't eliminate bottlenecks in software development, but it does move them ». Des années durant, la productivité d'ingénierie a visé à réduire la friction du SDLC, et les outils d'IA à accélérer l'implémentation. Mais en se généralisant chez Dropbox, ils ont révélé que « accelerating code generation simply shifted some bottlenecks downstream » : plus le code va vite, plus la pression monte sur la revue, la CI, la validation, la coordination de release et les opérations de production.

Le passage copilote → agent change le modèle d'interaction : l'agent prend une tâche scopée, inspecte le code, édite, lance les tests, itère sur les échecs et rend un artefact pour revue humaine — l'ingénieur restant responsable de l'intent, de l'architecture, de la qualité et des décisions de release. Illustration : Nova, la plateforme d'agents interne de Dropbox, qui représente déjà ~1 PR sur 12 et s'étend aux migrations, tests flaky, investigations de bugs et mises à jour de dépendances. Insight clé : « Nova's value comes less from the model itself than the systems surrounding it » (contexte codebase, pratiques internes, exécution sûre, intégration aux workflows, revue humaine).

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

D'où une refonte de la mesure : le PR throughput ne suffit plus. Dropbox adopte un modèle en 4 étages — Fuel → Adoption → Output → Impact — qui va de l'usage de l'outil jusqu'à la valeur client (idea → customer value), avec des signaux qualité (code review turnaround time, first-run test pass rate, defect ratio, rework rate). « Quality and trust matter as much as speed » ; la bascule consiste à « move from local activity metrics toward broader system outcomes ».

Côté workflows, ce n'est « not just a tooling shift » : l'operating model change, le rôle de l'ingénieur glisse vers l'intention, le problem mapping, la revue et les décisions architecturales — d'où l'importance de l'enablement (hackathons, bootcamps, exemples par les pairs) et d'une adoption modulée selon le risque (« the goal is not to force every workflow through an agent »). La pression remonte aussi vers le produit et le design (specs, problem framing).

Leçon finale : l'avantage « will not come from access to the same foundation models » mais « from the systems built around those models ». « The future of engineering productivity… will be defined by who builds the best systems around them. » Un proof-point opérateur majeur de la bascule output → outcome.