Accelerare il codice serve quando il sistema riesce a trasformarlo in software verificato. Dal talk al Codemotion Milano 2026, un criterio per decidere dove investire in AI e Developer Experience.
Una modifica pronta in pochi minuti può aspettare giorni prima di arrivare in produzione. Nel frattempo qualcuno deve ricostruirne l’intento, avviare l’ambiente, interpretare un test fallito, trovare il reviewer e capire se il comportamento ottenuto corrisponde a quello richiesto. Il tempo risparmiato nella scrittura esiste. La consegna continua a dipendere anche da tutto questo lavoro.
È il problema che abbiamo portato al Codemotion Milano 2026 con Riccardo Galimberti, VP of Engineering di Docebo, nel talk AI Won’t Fix Your Developer Experience. Da quel confronto nasce la tesi di questo Briefing: la capacità di verificare deve crescere insieme alla capacità di produrre. Per un Tech Leader significa collegare l’investimento in AI alle condizioni che consentono di accettarne e distribuirne il lavoro.
Il guadagno locale va seguito fino alla consegna
La velocità di scrittura è visibile: una funzione compare, un refactoring prende forma, una pull request viene aperta. Le attese successive sono meno spettacolari. Spesso attraversano strumenti, team e responsabilità diversi. È facile attribuire il risultato al tool che vediamo lavorare e lasciare fuori dal conto chi deve trasformare quel risultato in una modifica affidabile.
Nel commento ufficiale al report State of Developer Experience 2026, Atlassian riporta che l’87% degli sviluppatori dichiara di consegnare il lavoro più velocemente grazie all’AI, mentre il 72% incontra attriti invariati o maggiori. Sono risposte auto-riferite, le percentuali non sono esclusive e non dimostrano un rapporto causale. Rendono però legittima una domanda: dove finisce il tempo guadagnato?
Immaginiamo, come esempio ipotetico, che un team inizi ad aprire più PR mantenendo invariati disponibilità dei reviewer, affidabilità dei test e frequenza di rilascio. Se il lavoro in arrivo supera stabilmente quello che il sistema riesce a completare, il lavoro aperto si accumula. Ogni nuova modifica compete per attenzione; chi torna sulla precedente deve recuperarne il contesto. Una parte del vantaggio iniziale può essere assorbita da queste attività.
Questo rischio va verificato nel proprio contesto. Un agente che prepara test utili o chiarisce una dipendenza può anche alleggerire il lavoro successivo. Per scegliere serve seguire una modifica lungo il percorso completo e capire chi sostiene il costo della sua verifica. Il numero di PR aperte, preso da solo, lascia questa domanda senza risposta.
La DevEx è l’infrastruttura della delega
Nel talk abbiamo descritto la Developer Experience attraverso quattro dimensioni: strumenti e infrastruttura; processi e autonomia; cultura e leadership; architettura e codice. Insieme determinano quanto sia possibile capire un problema, intervenire e riconoscere un risultato corretto. Un ambiente ripetibile conta quanto una responsabilità chiara; un test affidabile conta quanto la possibilità di chiedere aiuto senza trasformare ogni dubbio in un’escalation.
L’arrivo degli agenti rende questi aspetti ancora più concreti. Se per eseguire un servizio occorre conoscere una sequenza di passaggi tramandata a voce, la delega incontra un limite. Se i criteri di accettazione sono ambigui, un agente può implementare con precisione un’interpretazione sbagliata. Se un test intermittente non distingue regressioni ed errori dell’ambiente, il feedback diventa difficile da usare.
È qui che DevEx e Agentic Experience si incontrano: contesto accessibile, ambienti eseguibili e feedback interpretabili permettono sia alle persone sia agli agenti di contribuire. Un miglioramento della documentazione può ridurre il lavoro necessario a orientarsi; una procedura verificabile può rendere più ripetibile l’esecuzione. Abbiamo già affrontato il primo punto nel Briefing sulla documentazione come interfaccia della Developer Experience.
Questo non impone di sistemare l’intera piattaforma prima di usare l’AI. Suggerisce di partire da una delega circoscritta e rendere disponibili le condizioni necessarie a completarla. Il confine utile può essere un servizio, una tipologia di difetto o una procedura di aggiornamento. L’adozione diventa così anche un modo per scoprire quali capacità mancano.
Dal disagio a un’ipotesi verificabile
«La CI è lenta» è un segnale sufficiente per iniziare a indagare. Per decidere l’intervento bisogna scomporlo. Il job aspetta un runner? I test richiedono troppo tempo? Una suite viene rieseguita perché fallisce in modo intermittente? Sono problemi diversi: aggiungere runner può ridurre la coda, ma non corregge un test instabile.
La Developer Journey Map serve a ricostruire questo percorso con chi lo attraversa: attività, informazioni cercate, attese, ritorni e passaggi di responsabilità. Nel lavoro raccontato al Codemotion abbiamo usato questa lente per il setup locale e per pull request e code review. La mappa aiuta a formulare domande; per riconoscere un collo di bottiglia occorrono osservazioni sul flusso reale.
Anche distinguere il percorso che determina la durata da un vincolo di capacità evita decisioni affrettate. Nel nostro esempio sintetico, due test obbligatori partono insieme e durano dodici e otto minuti, senza coda. Portare il primo a sei riduce l’attesa complessiva a otto minuti. Per scendere ancora bisogna intervenire sul secondo. Il calcolo descrive quella singola esecuzione; per diagnosticare una capacità insufficiente dell’organizzazione servono dati su code e lavoro completato nel tempo.
Per un Tech Leader la conseguenza è pratica: dopo ogni miglioramento va osservato di nuovo il sistema. Un intervento riuscito può cambiare la priorità successiva. Il Briefing sui limiti dei marginal gains affronta proprio la necessità di mantenere visibile il sistema nel quale ottimizziamo.
Che cosa possiamo imparare dal rollout
Al Codemotion ho raccontato il pilota di Claude Tag e la sua estensione ai canali dei team in Docebo. Al momento del talk il rollout era in corso. Le richieste facevano emergere esigenze di ambienti eseguibili e pipeline rapide: osservazioni qualitative iniziali, senza conclusioni quantitative consolidate sull’incremento di produttività.
Abbiamo presentato anche il lavoro sul Plugin Hub, che raccoglie plugin e skill prima dispersi in azienda. La centralizzazione è il cambiamento realizzato; facilitare la ricerca e il riuso delle capacità è l’obiettivo. Il beneficio sulla delivery resta da misurare. Tenere distinti questi livelli permette di raccontare il lavoro senza trasformare una scelta ragionevole in un risultato già dimostrato.
Questa distinzione serve anche nel dialogo con CEO e board. Rendere disponibile una capacità, vederla usare e osservare un miglioramento della consegna sono tre passaggi diversi. Un rollout può riuscire sul primo e sul secondo e lasciare aperto il terzo. Un aggiornamento utile deve dire quale passaggio è stato raggiunto, quali segnali abbiamo e quale decisione prenderemo dopo.
Un contratto esplicito per il lavoro delegato
La delega agli agenti richiede di rendere osservabile che cosa significa aver finito. Come proposta di workflow, partirei da obiettivo, criteri di accettazione e limiti: cosa può cambiare l’agente, quali comportamenti deve preservare, quando deve fermarsi e chiedere una decisione. La PR dovrebbe poi riportare test eseguiti, risultati, verifiche mancanti e incertezze.
Il reviewer può così valutare il lavoro rispetto a un intento esplicito. Un secondo agente può aiutare a cercare errori o casi trascurati, ma il suo consenso, da solo, non è una verifica indipendente: potrebbe condividere le stesse assunzioni sbagliate. L’indipendenza va cercata nelle evidenze e nel confronto con requisiti e comportamenti attesi.
La profondità della verifica deve seguire il rischio. Una modifica editoriale e un cambiamento alle autorizzazioni richiedono controlli diversi. Imporre la stessa procedura a ogni intervento può consumare attenzione senza migliorare la sicurezza; alleggerirla indiscriminatamente può lasciare scoperti i casi più delicati. Definire questi confini è una responsabilità di engineering leadership.
Un esperimento per decidere il prossimo investimento
Per tradurre la tesi in una decisione, sceglierei una tipologia ricorrente di modifica su un servizio. Prima osserverei come viene completata oggi, includendo le modifiche ancora in attesa: guardare solo quelle chiuse rischia di nascondere proprio il lavoro bloccato. Raccoglierei dati dei sistemi e racconto delle persone, separando almeno quattro aspetti.
- Flusso: modifiche completate e tempo fino al deploy, con confini temporali coerenti.
- Attese: tempo alla prima review, coda CI e anzianità del lavoro aperto.
- Qualità: rilavorazioni, regressioni e problemi emersi dopo il rilascio.
- Esperienza: sforzo necessario a capire, verificare e correggere la proposta AI.
Un’ipotesi possibile è: «Se ogni PR include intento, evidenze dei test e limiti della verifica, diminuisce il tempo che il reviewer impiega a ricostruire il contesto». La proverei con un responsabile e una data di rivalutazione, per esempio dopo due settimane se il volume è sufficiente. Con pochi casi estenderei l’osservazione e manterrei prudente la conclusione.
Prima di partire concorderei che cosa rende il risultato utile: una minore attesa accompagnata da meno ricostruzione manuale del contesto e senza segnali di peggioramento della qualità. Leggerei mediana e casi più lenti, mantenendo visibili dimensione e rischio delle modifiche. Un confronto prima/dopo può orientare una scelta locale; cambiamenti simultanei di carico, persone o tipo di lavoro limitano l’attribuzione causale.
Se la verifica diventa più semplice e le modifiche arrivano prima in produzione, abbiamo una ragione per estendere l’intervento. Se cresce il lavoro aperto, possiamo ridurre le attività avviate e liberare capacità per completarle. Se l’esperimento non cambia il risultato, occorre rivedere l’ipotesi. Il numero di agenti disponibili non deve diventare automaticamente il numero di lavori da iniziare.
La decisione che rimane al Tech Leader
L’AI può rendere economiche attività che prima richiedevano molto tempo. Il valore di quella capacità dipende anche dalla possibilità di capire il risultato, assumersene la responsabilità e distribuirlo. Un’organizzazione che accelera soltanto l’avvio del lavoro rischia di spostare il costo su chi deve completarlo.
La domanda da portare alla prossima conversazione sull’AI è quindi: quale condizione del nostro sistema impedisce al tempo guadagnato di diventare valore consegnato? Rispondere richiede ascolto, dati e una scelta di priorità. Una buona Developer Experience rende questa scelta più informata e offre all’AI un contesto nel quale il lavoro può essere verificato e portato a termine.
Nel vostro team, quale passaggio separa oggi una modifica pronta da una modifica rilasciata? Portate nel confronto con gli altri Tech Leader un caso concreto: dove ha aspettato, quale evidenza vi manca e quale piccolo esperimento potrebbe chiarire la causa. È da lì che può partire il prossimo investimento DevEx.
Questo Briefing sviluppa i temi del talk di Alex Pagnoni e Riccardo Galimberti al Codemotion Milano 2026. Le slide complete sono consultabili e scaricabili. Le osservazioni sul rollout si riferiscono al momento del talk.
