Kazuaki Okumura (Dropbox) riprende, in questo post del 28 maggio 2026 che ricapitola un intervento alla DX Annual 2026, una tesi controintuitiva: « AI doesn't eliminate bottlenecks in software development, but it does move them ». Per anni la produttività ingegneristica ha puntato a ridurre l'attrito dell'SDLC, e gli strumenti IA ad accelerare l'implementazione. Ma scalando in Dropbox, hanno rivelato che « accelerating code generation simply shifted some bottlenecks downstream »: più il codice si muove velocemente, più cresce la pressione su review, CI, validazione, coordinamento dei rilasci e operazioni in produzione.

Il passaggio copilot → agente cambia il modello di interazione: l'agente prende in carico un compito circoscritto, ispeziona il codice, modifica, esegue i test, itera sui fallimenti e restituisce un artefatto per la revisione umana — con l'ingegnere che resta responsabile di intento, architettura, qualità e decisioni di rilascio. Illustrazione: Nova, la piattaforma di agenti interna di Dropbox, che rappresenta già ~1 PR su 12 e si estende a migrazioni, flaky test, investigazioni di bug e aggiornamenti di dipendenze. Insight chiave: « Nova's value comes less from the model itself than the systems surrounding it » (contesto del codebase, pratiche interne, esecuzione sicura, integrazione nei workflow, revisione umana).

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

Da qui un ripensamento della misurazione: il PR throughput non basta più. Dropbox adotta un modello a 4 fasi — Fuel → Adoption → Output → Impact — che va dall'uso degli strumenti al valore per il cliente (idea → customer value), con segnali di qualità (tempo di turnaround della code review, tasso di successo dei test al primo run, defect ratio, rework rate). « Quality and trust matter as much as speed »; il cambiamento consiste nel « moving from local activity metrics toward broader system outcomes ».

Sul fronte dei workflow, non si tratta « just a tooling shift »: cambia il modello operativo, il ruolo dell'ingegnere si sposta verso intento, mappatura dei problemi, revisione e decisioni architetturali — da qui l'importanza dell'enablement (hackathon, bootcamp, esempi guidati dai pari) e di un'adozione modulata sul rischio (« the goal is not to force every workflow through an agent »). La pressione si sposta anche a monte, verso prodotto e design (specifiche, definizione dei problemi).

Lezione finale: il vantaggio « will not come from access to the same foundation models » ma « from the systems built around those models ». « The future of engineering productivity… will be defined by who builds the best systems around them. » Una prova operativa di primo piano dello spostamento output → outcome.