Microsoft Build 2026 e il passaggio silenzioso allo sviluppo agent-native
· 3 min read · Filippo Spinella · AI, GitHub Copilot, Microsoft Build, Developer Tools
Microsoft Build 2026 aveva un sottotesto molto chiaro: la prossima fase degli agenti software non è una chat più bella. È dare agli agenti una scrivania, una checklist, una sandbox e un responsabile.
I segnali ufficiali arrivano dal live blog di Microsoft Build 2026, dal post Microsoft AI alone won't change your business. The system running it will e dall'annuncio GitHub della GitHub Copilot app. Letti insieme, dicono la stessa cosa: gli agenti stanno entrando nel sistema di sviluppo, non restando come accessorio accanto all'editor.
La parte utile è noiosa, nel senso buono
Un agente che scrive una patch è interessante. Un agente che lavora in un worktree isolato, lancia check, conserva un trace leggibile, apre una pull request e si ferma al gate di approvazione giusto è molto più utile.
Questo è il cambio che vedo in Build 2026. Meno magia. Più modello operativo.
La Copilot app di GitHub viene raccontata come una control room per il lavoro degli agenti: sessioni, repository, issue, pull request e task paralleli nello stesso posto. Il dettaglio che mi piace sono i worktree. Rendono il lavoro dell'agente meno disordinato, perché ogni tentativo può vivere in uno spazio separato. Lo confronti, lo butti via o lo promuovi senza pestare i tuoi file.
Le sandbox non sono un dettaglio
Se un agente può eseguire codice, gli serve un posto sicuro dove sbagliare. Qui entrano le sandbox. Locali o cloud, permettono all'agente di provare senza trasformare laptop o produzione nel campo esperimenti.
Non è glamour, ma è la differenza tra demo e workflow. Un buon agente dovrebbe poter lanciare test, leggere fallimenti, riprovare e mostrare cosa è cambiato. Dovrebbe anche essere abbastanza limitato da mantenere piccolo l'errore.
Foundry e Agent Framework parlano di produzione
Gli aggiornamenti a Foundry e Microsoft Agent Framework sono la versione enterprise della stessa storia. Hosted agents, toolboxes, tracing, evaluation, memory, middleware e agent controls suonano come parole infrastrutturali. Lo sono. Ed è proprio per questo che contano.
Quando un'azienda crea molti agenti, la domanda smette di essere possiamo costruirne uno. Diventa: chi lo possiede, cosa può leggere, come lo valutiamo, come capiamo se migliora, e come lo spegniamo?
La review diventa il collo di bottiglia
La trappola dello sviluppo agentico è pensare che più agenti significhino automaticamente più lavoro rilasciato. Potrebbe voler dire solo più pull request ferme davanti a reviewer stanchi.
Io misurerei l'adozione con tre numeri:
- quanto tempo fa risparmiare o perdere ai reviewer;
- quanto spesso le modifiche passano i check senza babysitting;
- quanto spesso il trace spiega il ragionamento abbastanza bene da fidarsi del diff.
Se il reviewer deve ricostruire tutto da zero, il workflow non è finito. Ha solo spostato la fatica.
Da dove partirei
Partirei da task noiosi e ben delimitati: aggiornamento dipendenze, fix di test, piccoli refactor, risposte ai commenti di review, release note, migrazioni con test forti. Non sono glamour, ed è proprio per questo che vanno bene.
Per ogni task chiederei isolamento, check, trace e decisione umana sul merge. L'agente fa il lavoro di gambe. Il team resta proprietario del risultato.
La mia lettura
Build 2026 fa sembrare agent-native development meno uno slogan e più un problema operativo. I team migliori non saranno quelli che lasciano fare tutto agli agenti. Saranno quelli che progettano un sistema in cui gli agenti avanzano senza nascondere la traccia.
Questa è la versione matura dell'onda: non AI che sostituisce la review, ma AI che fa abbastanza lavoro strutturato da rendere la review più affilata.