Post dal **Dropbox Tech blog** (sezione *culture*), pubblicato il **28 maggio 2026** da **Kazuaki Okumura** (Dropbox, ruolo non specificato nell'articolo), che riprende un intervento alla conferenza **DX Annual 2026** (developer productivity). **Tesi centrale**: la produttività ingegneristica deve andare oltre la *code generation*. *« Accelerating code generation simply shifted some bottlenecks downstream »* — l'IA ha aumentato in modo massiccio il throughput di codice, ma *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. La vera sfida non è più scrivere codice più velocemente, ma consentire all'intero SDLC di **assorbire, validare e spedire in sicurezza** un volume molto maggiore. **Dal copilot all'agente**: la prima ondata (spiegazione del codice, snippet, Q&A) operava *« as copilots alongside the engineer »*; l'agente, invece, *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — con l'ingegnere che resta *« accountable for intent, architecture, quality, and release decisions »* (più lavoro in parallelo, più opzioni, delega dell'esecuzione ripetitiva). **Nova** = piattaforma **interna** di agenti di coding di Dropbox: descrivere un compito in linguaggio naturale, esecuzione in un ambiente controllato con contesto del codebase. Dato canonico: ***« 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); Nova rappresenta oggi **~1 PR su 12 in Dropbox** (adozione in crescita), e si estende oltre le feature a **migrazioni, risoluzione di flaky test, investigazione di bug, aggiornamento di dipendenze** (lavoro ad alto toil). **Misurare la velocità di prodotto, non l'output di codice**: il *PR throughput*, segnale utile quando il vincolo era la velocità di coding, *« was no longer sufficient »*. Un modello di misurazione a **4 fasi**: ***Fuel*** (gli strumenti IA vengono usati?) → ***Adoption*** (come cambiano i workflow nei team) → ***Output*** (l'IA contribuisce al lavoro in produzione?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Segnali di qualità monitorati: **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 cuore del cambiamento: *« moving from local activity metrics toward broader system outcomes »*. **Anche i workflow devono evolvere**: non si tratta *« just a tooling shift »* ma di un cambiamento di **modello operativo** — il ruolo dell'ingegnere si sposta verso *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. L'**enablement** è cruciale quanto lo strumento stesso (apprendimento pratico, hackathon, workflow spotlight, bootcamp, esempi guidati dai pari); l'adozione procede a velocità diverse nei team; *« The goal is not to force every workflow through an agent »* — l'obiettivo è renderlo *« useful, safe, measurable, and repeatable where it creates meaningful leverage »*. **Cosa abbiamo imparato**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (a valle: review, validazione, testing, release, prod ops) → ottimizzare il vecchio collo di bottiglia non genera più la stessa leva. *« 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. »* La pressione si accumula anche **a monte** (prodotto e design): specifiche strutturate, chiarezza di design, definizione più netta dei problemi. Chiusura: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Convergenza diretta con **Salesforce/Tallapragada** (Effective Output: misurare il valore, non il volume; nessun trade-off velocità/qualità), **Gupta** (attribuzione token-to-outcome, costo di un outcome completato), **DORA** (oltre il throughput), e lo spostamento del KPI verso l'**outcome di sistema** (idea→valore per il cliente).
**Kazuaki Okumura** — Dropbox (rôle non précisé dans l'article ; le billet reprend une intervention présentée à la conférence **DX Annual 2026** sur la productivité développeur, ce qui suggère un profil engineering leadership / platform, sans confirmation). Publié sur le **Dropbox Tech blog** (dropbox.tech) · rubrique *culture* · le **28 mai 2026**.
Post ufficiale sul blog **Salesforce News** (sezione *Agentic Enterprise*, serie *"Pioneering the Agentic Shift Within Salesforce Engineering"*), pubblicato il **27 maggio 2026** (lettura di 6 minuti) da **Srinivas "Srini" Tallapragada**, *President and Chief Engineering and Customer Success Officer* di Salesforce. Seguito diretto di un post precedente (*"How we got our engineers to use AI — without breaking everything"*) che raccontava il superamento del **90% di adozione**. **Tesi di svolta**: Salesforce Engineering è passata da un mondo in cui l'IA era un utile *copilot* a uno in cui **gli strumenti agentici guidano lo stesso ciclo di vita dello sviluppo software (SDLC)** — scrivendo codice, revisionando PR, generando test, aggiornando la documentazione, gestendo i deployment, coordinando lavoro un tempo affidato a passaggi di consegne umani. **Decisione segnale canonica**: standardizzazione a livello aziendale su **Claude Code** + ***"abbiamo rimosso tutti i limiti di token"*** — *"eliminare ogni ultimo attrito tra i nostri ingegneri e gli strumenti che li rendono più veloci ed efficaci"*. **Risultato empirico principale** (aprile 2026 vs aprile 2025): work item completati per sviluppatore **+50,8%**, PR mergiate per sviluppatore **+79%**, e soprattutto **Effective Output score** (una misura ML del **valore reale del codice consegnato**, non del volume) **+151,3% su base annua**. **Caso d'uso di punta**: migrazione di **33 endpoint API** verso un'architettura cloud-native, stimata in **~231 person-day** (7 per API) col metodo tradizionale, completata in **13 giorni — 18× più veloce** — tramite un **framework basato su regole costruito in Claude** (file markdown + implementazioni di riferimento), con il feedback delle PR continuamente reintegrato nel set di regole, **cicli LLM autonomi (build, fix, validate)** senza intervento manuale, parallelizzati su ambienti isolati → **5 PR**, la più grande delle quali con **21 endpoint e copertura test al 100%**. **Nessun compromesso velocità↔qualità**: attraverso la piattaforma **Engineering 360** (che centralizza i dati di ingegneria di centinaia di sistemi), **il totale degli incidenti scende del 5%** nonostante l'aumento delle PR (*"la qualità non soffre della velocità. Ne beneficia"*), grazie a **guardrail di sicurezza e standard di qualità incorporati strutturalmente** nel workflow agentico (Trust come valore numero 1). **Revisione dell'SDLC**: una volta adottata l'IA, gli ingegneri **smontano e ricostruiscono** i workflow (quali processi eliminare? quali passaggi di consegne sono ormai superflui? dove un umano svolge ancora un lavoro che un agente potrebbe assumere?). **Nuovo mestiere ingegneristico**: le **Claude Code skills** (capacità impacchettate e riutilizzabili che codificano il contesto del team, le convenzioni di naming, i pattern) diventano un **artefatto ingegneristico** condiviso e componibile; **AI Expert Suite** + **Salesforce Foundation Plugins** = una libreria di skill istituzionalizzata e curata (benchmark interno: **maggiore accuratezza e affidabilità, costo superfluo ridotto**); **subagent e team di agenti** parallelizzano i flussi di lavoro (*"Descrivono il risultato, e un insieme di agenti coordinati individua i passaggi"*). **Ciò che resta difficile**: (1) la **gestione del contesto** nelle sessioni lunghe — la **qualità dei file CLAUDE.md** varia ampiamente e pesa fortemente sulla qualità dell'output; (2) la **sicurezza agentica** = un modello radicalmente diverso (agenti che *agiscono*, non solo *suggeriscono* → raggio d'impatto aumentato); (3) **ruoli in evoluzione** (come diventano senior i junior se l'IA assorbe il lavoro entry-level? ruolo del designer/PM? l'unità di esecuzione = team scrum → sperimentazioni con unità da 1 o 3 persone). Conclusione: *"Ha cambiato ciò che era economicamente possibile"*; l'ambizione dichiarata è **"l'SDLC più automatizzato e agentico del settore"**. Si interseca direttamente con Gupta (*costo di un outcome completato*, utilità marginale del token), Greenwald/Sierra (pricing basato sui risultati), DORA (ROI / costo per feature) e il dibattito BFM/Girard (il token come carburante di valore, non un costo da tagliare).
#SDLC agentico#agentic SDLC#Claude Code
**Srinivas « Srini » Tallapragada** — *President and Chief Engineering and Customer Success Officer* de **Salesforce**. Plus d'une décennie chez Salesforce · dirige l'ingénierie mondiale de la plateforme unifiée. Auteur de la série *Agentic Enterprise* sur le blog Salesforce News ; ce billet (27 mai 2026) est la **suite** d'un premier opus consacré à l'adoption de l'IA par les milliers d'ingénieurs Salesforce (*« How we got our engineers to use AI — without breaking everything »*). Position d'autorité = **dirigeant exécutif** parlant en son nom et au nom d'une organisation d'ingénierie à grande échelle (donnée terrain à l'échelle d'un hyperscaler SaaS) · avec accès aux métriques internes (Engineering 360, Effective Output).
FinOps per agenti AI incentrato sul "costo per risultato": perché il FinOps tradizionale fallisce di fronte al comportamento a runtime, guardrail, osservabilità comportamentale e un ciclo di vita in 4 fasi - Orq.ai