Sviluppo di Microsoft Copilot Cowork: nove ingegneri, 1.211 pull request e il collo di bottiglia della verifica

Microsoft afferma che nove ingegneri hanno unito 1.211 pull request durante lo sviluppo di Copilot Cowork il 21 ottobre, con gli agenti che hanno scritto la maggior parte del codice. Una pull request propone modifiche da revisionare prima dell'integrazione. La distinzione è importante: il titolo misura le modifiche unite, mentre la produttività dipende anche dalla loro utilità, affidabilità e dal carico di manutenzione.

Pubblicato il 2 novembre, il resoconto ingegneristico descrive un team che sta cambiando il modo in cui specifica, revisiona e gestisce il software. La sua tensione centrale contrappone l'espansione della capacità di implementazione a una capacità di verifica limitata. Generare più modifiche crea valore solo quando l'organizzazione può stabilire quali modifiche meritino di arrivare agli utenti.

La ricerca sugli agenti di Anthropic e quella di Google sulla distribuzione del software offrono punti di riferimento utili, senza convalidare in modo indipendente i risultati di Microsoft. Entrambe richiamano l'attenzione sui sistemi che circondano gli strumenti AI. Per i responsabili dell'ingegneria, la pressione ricade sulle pratiche di revisione, sull'architettura e sulla responsabilità man mano che la produzione di codice diventa più facile da espandere.

Cosa misura realmente il traguardo nello sviluppo di Copilot Cowork

Secondo il resoconto di Microsoft su Copilot Cowork engineering, il team backend ha raggiunto quel totale giornaliero dopo aver iniziato a lavorare a gennaio. Gli ingegneri hanno mantenuto la responsabilità dei requisiti e delle decisioni a maggior rischio. Controlli automatizzati e revisori agenti hanno esaminato le modifiche. Microsoft descrive inoltre una modifica sensibile in cui i revisori umani hanno individuato quattro problemi bloccanti sfuggiti ai revisori agenti.

Una pull request unita registra attività accettata; il suo valore aziendale richiede comunque prove separate.

Un'organizzazione può suddividere una funzionalità in molte modifiche o combinare lavori correlati in una proposta più ampia. Entrambi gli approcci modificano il conteggio. Nessuno dei due stabilisce quanto valore per il cliente abbia prodotto il lavoro. Confrontare i team solo attraverso i totali rischia quindi di premiare differenze nel confezionamento anziché differenze nelle prestazioni ingegneristiche.

Modifiche più piccole possono semplificare la revisione perché ogni proposta pone una domanda più circoscritta. Tuttavia, una raccolta di modifiche comprensibili singolarmente può comunque produrre un effetto combinato inatteso. L'unità di valutazione rilevante diventa talvolta il rilascio, il flusso di lavoro del cliente o il servizio nel tempo.

Si consideri un ipotetico assistente per la pianificazione che legge una richiesta, verifica la disponibilità e prepara un invito a una riunione. Ogni componente può superare i propri test, mentre il flusso di lavoro completo gestisce erroneamente una cancellazione. Contare le modifiche riuscite dei componenti non coglierebbe il problema effettivo del cliente.

L'esempio illustra perché il traguardo meriti attenzione senza diventare un obiettivo universale. Il conteggio suggerisce un processo di integrazione insolitamente intenso. Non rivela una misura standardizzata della complessità delle funzionalità, del beneficio per il cliente o dell'impegno necessario a mantenere il sistema risultante.

Anche la tempistica conta. Questo resoconto descrive un modello operativo emerso attraverso uno sviluppo sostenuto, anziché una breve dimostrazione di codice generato. I lettori dovrebbero valutare le sue affermazioni come un caso di studio produttivo di un'azienda, con tutto il contesto e i limiti di selezione che tale formato comporta.

Copilot Cowork engineering pone quindi una questione gestionale che va oltre la velocità di programmazione: quali prove dovrebbero giustificare l'accettazione di una modifica? Risposte diverse implicano esigenze di personale diverse. Un team che enfatizza i risultati dei test locali si organizzerà diversamente da uno che richiede revisione della sicurezza, evidenze operative e controlli sugli esiti per il cliente.

Il totale giornaliero non può rispondere a questa domanda per un'altra organizzazione. Rende però più difficile rimandarla. Quando l'implementazione si espande, criteri di accettazione deboli diventano un vincolo operativo anziché un inconveniente occasionale.

Per gli acquirenti, la distinzione è altrettanto pratica. Il ritmo di sviluppo di un fornitore descrive la sua capacità di modificare il prodotto. Un acquirente ha comunque bisogno di prove che tali modifiche migliorino i flussi di lavoro da cui dipendono i dipendenti.

I responsabili dell'ingegneria affrontano un problema di capacità di verifica

Quando la capacità di implementazione si espande, la risorsa scarsa diventa la fiducia giustificata in ciò che viene rilasciato.

La fiducia ha diverse fonti: un requisito preciso, test significativi, una revisione competente ed evidenze provenienti dal servizio in esecuzione. Queste fonti rispondono a domande diverse. Un test può stabilire il comportamento atteso per input selezionati senza stabilire che il requisito stesso serva il cliente.

La ricerca di Google su AI-assisted software development offre un confronto più ampio. I risultati DORA del 2025 associano l'adozione dell'AI a un aumento del throughput di distribuzione, sottolineando al contempo l'organizzazione circostante. La ricerca descrive l'AI come un amplificatore di punti di forza e debolezza esistenti.

Questa prospettiva sostiene un'interpretazione prudente del traguardo di Microsoft. Un team con proprietà chiare e controlli di rilascio affidabili ha canali verso cui indirizzare capacità di implementazione aggiuntiva. Un team con responsabilità irrisolte può invece accumulare più proposte che nessuno riesce ad approvare con fiducia.

La pressione ricade quindi anzitutto sui responsabili dell'ingegneria e sui team di piattaforma. Essi stabiliscono chi possiede i criteri di accettazione, quali modifiche richiedono attenzione specialistica e come un rilascio può essere annullato. Queste decisioni diventano più rilevanti quando le proposte arrivano più rapidamente.

Gli specialisti della sicurezza affrontano un problema di allocazione correlato. Revisionare ogni modifica con la stessa intensità consuma attenzione indipendentemente dal rischio. Revisionare solo i file di sicurezza più evidenti non coglie il comportamento introdotto altrove. Il compito difficile consiste nel collegare le modifiche alle autorizzazioni, ai dati e alle azioni dei clienti che interessano.

Anche i product manager ereditano maggiori responsabilità. Richieste ambigue diventano costose quando il software può essere prodotto prima che emergano i disaccordi. Un'implementazione rifinita può creare slancio attorno a un requisito frainteso, rendendo la correzione politicamente più difficile anche quando modificare il codice resta tecnicamente semplice.

È qui che le organizzazioni dovrebbero distinguere l'attesa dalla deliberazione necessaria. Alcuni ritardi riflettono informazioni mancanti o un revisore sovraccarico. Altri ritardi proteggono una decisione irreversibile. Trattare entrambi come spreco incoraggia i team a rimuovere salvaguardie semplicemente perché rallentano una dashboard.

Una risposta gestionale utile consiste nell'esaminare dove l'incertezza entra nel processo. Se i revisori chiedono ripetutamente cosa dovrebbe fare una funzionalità, il requisito necessita di lavoro. Se mettono ripetutamente in dubbio gli effetti della distribuzione, il processo di rilascio necessita di maggiore visibilità.

Si tratta di diagnosi organizzative, non di argomenti a favore di processi illimitati. Ogni controllo aggiuntivo ha un costo. Il criterio dovrebbe essere se risponde a una domanda rilevante che un altro controllo lascia irrisolta.

La storia dello sviluppo di Copilot Cowork rende questo compromesso insolitamente visibile. I responsabili dell'ingegneria devono ora spiegare come espanderanno la capacità di verifica insieme alla capacità di implementazione. Acquistare l'accesso a un agente di coding non risolve quella decisione operativa.

Per gli acquirenti aziendali, la domanda corrispondente riguarda la qualità delle modifiche. Rilasci più rapidi diventano utili quando i dipendenti sperimentano meno interruzioni, autorizzazioni più chiare e un completamento delle attività più affidabile. La sola frequenza dei rilasci lascia questi risultati irrisolti.

La migrazione di Copilot Cowork a Rust separa il linguaggio dall'architettura

Microsoft riferisce che la migrazione di Copilot Cowork a Rust ha ridotto il tempo mediano di risposta del primo turno da 7,9 secondi a 2,7 secondi in una finestra di confronto. Attribuisce inoltre parte del miglioramento allo spostamento del ciclo dell'agente e non formula alcuna affermazione sul costo per turno.

Una migrazione può migliorare un servizio senza dimostrare che il linguaggio di programmazione abbia causato ogni miglioramento.

Un runtime è il meccanismo software che esegue il lavoro di un'applicazione. Spostare tale meccanismo tra linguaggi può cambiare la gestione della memoria, la pianificazione, la distribuzione e il comportamento di avvio. Se più elementi cambiano insieme, la misurazione risultante ne cattura l'effetto combinato.

La distinzione è importante perché i dibattiti sui linguaggi di programmazione spesso comprimono un progetto architetturale in una semplice competizione. Questa impostazione produce un titolo efficace, ma offre una base debole per la decisione di investimento di un altro team. La domanda rilevante riguarda quale meccanismo affronti il suo specifico collo di bottiglia.

Le garanzie di concorrenza di Rust forniscono un riferimento tecnico concreto. La concorrenza significa che parti separate di un programma possono compiere progressi indipendentemente. Rust usa regole di ownership e controlli dei tipi per individuare molti errori di memoria e concorrenza prima dell'esecuzione.

Queste garanzie hanno dei limiti. Non stabiliscono che una risposta contenga le informazioni aziendali corrette, che un'operazione disponga dell'autorizzazione o che gli utenti ricevano eventi nella sequenza attesa. La sicurezza del linguaggio e la correttezza dell'applicazione si sovrappongono solo parzialmente.

Un servizio di pianificazione illustra la differenza. Il suo codice può gestire la memoria in sicurezza selezionando però il calendario sbagliato. Le sue attività possono essere eseguite senza una race condition sui dati inviando tuttavia un invito prima dell'approvazione. Una garanzia a livello di linguaggio non può fornire una regola di prodotto mancante.

Le evidenze della migrazione necessitano quindi di più livelli. Un livello riguarda l'uso delle risorse e il tempo di risposta. Un altro riguarda il comportamento con traffico realistico. Un altro ancora riguarda se la sostituzione preservi obblighi che prima erano impliciti.

Un confronto controllato dovrebbe idealmente mantenere costanti le condizioni di carico di lavoro e infrastruttura, documentando al contempo le modifiche in valutazione. Le migrazioni in produzione raramente offrono una separazione sperimentale perfetta. Questo limite dovrebbe modellare l'attribuzione, non cancellare misurazioni operative utili.

Per gli sviluppatori che leggono il resoconto della migrazione di Copilot Cowork a Rust, l'implicazione pratica è analitica. Occorre determinare se il problema rilevante riguardi la pianificazione dell'esecuzione, il sovraccarico di avvio, il comportamento della memoria o la progettazione dell'applicazione prima di generalizzare il risultato.

Per gli acquirenti, il linguaggio in sé conta solitamente meno del risultato del servizio. Risposte iniziali più rapide sono preziose, ma non dimostrano il completamento più rapido di un'intera attività. Un sistema può iniziare a rispondere prima pur impiegando più tempo per produrre un risultato corretto.

La stessa distinzione si applica all'economia. Un miglioramento della latenza non dimostra automaticamente un costo operativo inferiore. L'uso dell'infrastruttura, le chiamate al modello, i tentativi ripetuti e il lavoro di supporto incidono tutti sul calcolo.

Questo rende la migrazione un utile caso di studio sull'attribuzione. Mostra perché un risultato ingegneristico dovrebbe mantenere il proprio contesto architetturale quando diventa un'affermazione pubblica sulle prestazioni.

La revisione degli agenti necessita di una base indipendente per la fiducia

Aggiungere revisori aumenta la fiducia solo quando i loro controlli forniscono evidenze utili e sufficientemente indipendenti.

Un agente AI è un sistema guidato da modelli che seleziona azioni e utilizza strumenti per perseguire un obiettivo. Un revisore agente può esaminare una modifica proposta, individuare criticità e richiedere correzioni. Il suo giudizio resta un output da valutare, soprattutto quando l’agente autore ha fornito gran parte della spiegazione circostante.

I modelli di workflow per agenti di Anthropic descrivono sistemi che separano la generazione dalla valutazione. L’azienda raccomanda progettazioni semplici, criteri di valutazione chiari e complessità aggiuntiva solo quando migliora i risultati. Ciò offre un confronto utile con il ruolo crescente della revisione automatizzata.

Un valutatore ha un compito più semplice quando il successo può essere osservato direttamente. Un calcolo numerico può essere verificato rispetto a un’elaborazione indipendente. Un workflow sensibile alle autorizzazioni richiede un tipo di evidenza diverso, perché l’azione corretta dipende da identità, policy e contesto.

Il pericolo centrale è l’incomprensione condivisa. Un autore e un revisore possono concordare perché hanno interpretato allo stesso modo un requisito ambiguo. Il loro accordo non risolve l’ambiguità. Un modello o un prompt separato aiuta solo se introduce una differenza rilevante nelle evidenze o nel ragionamento.

I test hanno una limitazione analoga. Un test scritto insieme a un’implementazione può riprodurne le assunzioni. Il suo superamento dimostra coerenza tra quegli artefatti. Non dimostra necessariamente coerenza con il comportamento previsto.

Le evidenze indipendenti possono provenire da un contratto esistente, dal comportamento osservato, da un requisito approvato o da un caso di errore accuratamente selezionato. La fonte appropriata dipende dalla modifica. La distinzione importante riguarda se l’evidenza possa contraddire l’implementazione.

Si consideri un controllo automatizzato che segnala successo pur non avendo ricevuto input rilevanti. Il suo risultato somiglia a un’ispezione riuscita, ma non contiene informazioni sulla modifica proposta. Un simbolo di superamento visibile diventa fuorviante quando gli utenti non possono capire che cosa il controllo abbia effettivamente esaminato.

Ecco perché la qualità della revisione non può essere ridotta al numero di agenti assegnati. Un insieme limitato di controlli con scopi distinti può offrire più fiducia rispetto a revisioni ampie e ripetute. L’obiettivo è coprire le modalità di errore rilevanti senza creare un flusso di commenti illeggibile.

Anche il coinvolgimento umano richiede un ruolo specifico. Chiedere a qualcuno di approvare una modifica senza tempo o contesto crea una supervisione nominale. Una revisione efficace richiede una decisione chiara, evidenze pertinenti e l’autorità di respingere la proposta.

Per lo sviluppo di Copilot Cowork, la lezione più ampia riguarda il rapporto tra automazione e responsabilità. Un feedback automatizzato più rapido può sostenere il giudizio umano, ma l’organizzazione necessita comunque di una base esplicita per accettare il rischio.

Questa base dovrebbe restare comprensibile anche dopo che gli autori originali hanno lasciato la conversazione. Un archivio ricercabile di requisiti e decisioni aiuta i futuri revisori a ricostruire l’intento. I team che gestiscono tale contesto possono esplorare una base di conoscenza ricercabile senza considerare i documenti archiviati come prova che il software si comporti correttamente.

La ricerca sulla produttività complica il titolo sulle pull request

Il case study di Microsoft e la ricerca indipendente sulla produttività misurano aspetti diversi, quindi i loro risultati non possono essere sostituiti l’uno con l’altro.

L’esperimento sulla produttività degli sviluppatori di METR offre un utile contrappeso. Nel suo studio condotto all’inizio del 2025, 16 sviluppatori open source esperti hanno completato 246 attività. Consentire l’uso dell’AI ha aumentato il tempo di completamento del 19% in quel contesto, nonostante i partecipanti ritenessero che gli strumenti fossero utili.

Quel risultato riguarda sviluppatori, repository, attività e strumenti specifici. Non dimostra che l’AI rallenti ogni team di ingegneria. Né può valutare direttamente un workflow successivo organizzato attorno a numerosi agenti concorrenti.

METR ha successivamente precisato ulteriormente il quadro. Il suo aggiornamento dell’esperimento sulla produttività del febbraio 2026 ha descritto problemi di selezione e difficoltà nel misurare il tempo quando gli sviluppatori utilizzavano agenti in parallelo. I ricercatori hanno considerato i risultati più recenti inaffidabili per stimare con precisione l’effetto attuale.

Insieme, queste fonti evidenziano un problema di misurazione, anziché fornire un verdetto universale. Il tempo di completamento delle attività, le modifiche integrate e l’utilità dichiarata dagli utenti possono variare in modo diverso. Una valutazione solida specifica quale risultato conta prima di interpretare un esito.

Per uno sviluppatore individuale, uno strumento potrebbe ridurre il lavoro sgradevole senza ridurre il tempo trascorso. Per un’organizzazione, uno strumento potrebbe ampliare la gamma di progetti realizzabili senza diminuire l’impegno di manutenzione. Questi benefici meritano considerazione, ma richiedono etichette accurate.

Un team può anche completare più lavoro perché sceglie attività più piccole. Ciò potrebbe migliorare la consegna riducendo attese e incertezza. Potrebbe anche gonfiare le misure di attività lasciando irrisolti i principali problemi dei clienti. Il solo conteggio non può distinguere queste spiegazioni.

Anche il controfattuale conta. Valutare la produttività richiede una qualche ricostruzione di ciò che sarebbe accaduto senza lo strumento o il processo. Una release riuscita dimostra che un team ha consegnato qualcosa. Non dimostra indipendentemente l’entità dell’accelerazione attribuibile all’AI.

Il resoconto pubblico di Microsoft fornisce un esempio operativo, anziché un confronto randomizzato. Questo formato può rivelare meccanismi utili e modalità di errore. Non può isolare ogni contributo derivante dall’esperienza degli sviluppatori, dall’infrastruttura, dal supporto organizzativo e dalla capacità del modello.

La stessa cautela vale per i concorrenti. La guida architetturale di Anthropic spiega un approccio progettuale, mentre la ricerca di Google descrive modelli più ampi. Nessuna delle due stabilisce quale fornitore offra il miglior risultato per uno specifico carico di lavoro aziendale.

Per i responsabili dell’ingegneria, l’implicazione è resistere alla tentazione di trasformare un numero memorabile in una formula per l’organico. Le decisioni sul personale richiedono evidenze su consegne sostenute, qualità, carico di supporto e lavoro che resta al di fuori del processo misurato.

La storia lascia aperta anche una questione economica. Il costo totale del lavoro accettato include generazione, valutazione, infrastruttura, attenzione umana e correzioni dopo il rilascio. Una maggiore attività di implementazione può coesistere con un’economia migliore o peggiore.

Lo sviluppo di Copilot Cowork dovrebbe quindi essere valutato come un esempio specifico di lavoro riorganizzato. Il suo contributo più forte consiste nel suggerire domande migliori sulle evidenze, anziché fornire un tasso di conversione universale tra ingegneri e agenti.

Tre segnali renderanno il modello di sviluppo più facile da valutare

Le prossime evidenze utili riguardano risultati sostenuti, verifiche ripetibili e il costo complessivo del lavoro accettato.

Il primo segnale è un follow-up che colleghi l’attività di sviluppo all’affidabilità in produzione. Nei prossimi mesi, la divulgazione di errori di rilascio, rollback o problemi ricorrenti dei clienti aiuterebbe i lettori a interpretare il volume di modifiche integrate.

Un miglioramento dell’affidabilità insieme a consegne sostenute rafforzerebbe il caso a favore del modello operativo. L’aumento del lavoro di riparazione lo complicherebbe. Entrambi i risultati offrirebbero più valore decisionale di un altro record isolato di attività.

Il confronto dovrebbe utilizzare definizioni coerenti. Un cambiamento nelle pratiche di rendicontazione può far apparire un servizio più sano senza modificarne il comportamento. I lettori dovrebbero cercare una finestra di misurazione stabile e una spiegazione chiara di ciò che conta come errore.

Il secondo segnale è l’evidenza che le pratiche di verifica si trasferiscano oltre il team originale. Una valutazione documentata, una configurazione di test riproducibile o un caso di produzione comparabile aiuterebbero a distinguere un approccio ampiamente utile da un risultato dipendente da condizioni insolite.

La replica non richiede che un altro team eguagli il totale giornaliero. Richiede di dimostrare che una capacità di implementazione aggiuntiva produca risultati accettati senza sovraccaricare revisione e operazioni. Carichi di lavoro diversi dovrebbero ragionevolmente produrre livelli di attività diversi.

Se altri team riproducono i benefici sotto vincoli diversi, il caso diventa più generale. Se il successo dipende fortemente da infrastrutture specializzate o da competenze concentrate, la sua applicabilità diventa più limitata. Sarebbe comunque un’informazione utile per acquirenti e responsabili dell’ingegneria.

Il terzo segnale è un resoconto economico credibile. Il costo per attività del cliente completata con successo collegherebbe le modifiche di ingegneria alla realtà operativa del prodotto. Rivelerebbe inoltre se nuovi tentativi e lavoro correttivo assorbano gli apparenti guadagni di efficienza.

Una divulgazione utile spiegherebbe quali costi entrano nel calcolo. Escludere revisione o infrastruttura risponderebbe a una domanda più ristretta. Includerle aiuterebbe le organizzazioni a confrontare l’approccio con il proprio processo esistente.

Queste sono priorità di osservazione, non impegni di rendicontazione annunciati. Microsoft non ha promesso ogni misurazione discussa qui. La loro assenza lascerebbe irrisolte parti del caso, anziché dimostrare automaticamente un fallimento.

Per gli acquirenti aziendali, l’azione immediata è chiedere ai fornitori evidenze collegate a un workflow reale. Scegliete un’attività svolta dai dipendenti, definite un risultato accettabile ed esaminate come il sistema gestisce le eccezioni. Tenete separata l’attività di sviluppo dal successo del cliente.

Per i responsabili dell’ingegneria che valutano lo sviluppo di Copilot Cowork, usate questa tappa per affinare le domande alla base delle vostre decisioni di adozione. Individuate ciò che il vostro team fatica a verificare, dove si perde l’intento e quali risultati giustificano ulteriore automazione. Confrontate il lavoro accettato su un periodo significativo, includendo lo sforzo necessario per correggerlo. Leggete il resoconto ingegneristico di base insieme alla ricerca sulla produttività, perché rispondono a domande diverse. Esaminate poi se la vostra organizzazione riesca a spiegare perché una modifica meriti di essere rilasciata. Quando diventa più facile ampliare l’implementazione, quella spiegazione diventa una responsabilità ingegneristica centrale. Quali evidenze convincerebbero il vostro team che una maggiore quantità di codice generato sia diventata software più affidabile?