Da Mono a CoreCLR: la fine di un’era per UnitySe sviluppate in C# ma non toccate Unity, la notizia potrebbe sembrarvi di nicchia. Non lo è. Con la release di Unity 6.8, prevista entro la fine del 2026, il motore di gioco più diffuso al mondo abbandona definitivamente il proprio fork custom di Mono in favore di CoreCLR, il runtime “vero” del .NET moderno, con supporto a .NET 10 e C# 14. Per anni Unity è rimasto ostaggio di un’architettura di scripting congelata a metà del decennio scorso, mentre il resto dell’ecosistema .NET correva avanti tra top-level statements, pattern matching avanzato, source generator e miglioramenti di performance del JIT. Il cambio di runtime non è solo un aggiornamento di versione: è un caso di studio interessante per chiunque lavori con .NET, anche fuori dal game dev, perché racconta come si affronta la migrazione di un’applicazione legacy da AppDomain a un modello di isolamento moderno.Domain Reload: il problema che ogni sviluppatore Unity conosce a memoriaChi lavora su progetti Unity di dimensioni consistenti conosce fin troppo bene il Domain Reload: si salva uno script, si torna nell’editor, e parte una barra di progresso che su progetti grandi può durare decine di secondi. Il motivo è architetturale: ogni ricompilazione degli script comporta lo scaricamento completo dell’AppDomain e il suo ricaricamento da zero in memoria, un’operazione “a tappeto” pensata per un modello di isolamento vecchio di vent’anni.Con CoreCLR, Unity abbandona il concetto di AppDomain in favore degli AssemblyLoadContext (ALC), il meccanismo di isolamento e caricamento assembly introdotto nel .NET moderno fin dai tempi di .NET Core. Invece di ricaricare tutto lo stato applicativo, il runtime può scaricare e ricaricare selettivamente solo gli assembly effettivamente modificati.AssemblyLoadContext: un concetto utile ben oltre UnityPer chi non l’avesse mai usato fuori da un contesto plugin-system, un AssemblyLoadContext è essenzialmente un contenitore isolato in cui caricare assembly .NET, che può essere scaricato indipendentemente dal resto dell’applicazione. È lo stesso meccanismo che sta dietro a scenari come plugin dinamici, hot reload di parti di un’applicazione server, o sandboxing di codice di terze parti. Un esempio minimale, applicabile a qualunque applicazione .NET moderna:using System.Reflection; using System.Runtime.Loader; var alc = new AssemblyLoadContext("PluginContext", isCollectible: true); Assembly plugin = alc.LoadFromAssemblyPath(@"C:\plugins\MyPlugin.dll"); // ... usa il plugin tramite reflection o interfacce condivise ... alc.Unload(); // richiede la garbage collection per liberare davvero la memoria GC.Collect(); GC.WaitForPendingFinalizers(); Il dettaglio da tenere presente, sia in Unity sia in un’applicazione .NET qualsiasi, è che uno scaricamento “leaked” è possibile: se un riferimento a un tipo caricato nell’ALC sopravvive fuori dal suo scope (una closure, un evento sottoscritto, un campo statico), l’assembly non può essere effettivamente liberato dal garbage collector. Non a caso, nel forum ufficiale Unity gli sviluppatori hanno confermato che il motore segnalerà esplicitamente all’utente quando un AssemblyLoadContext non riesce a essere scaricato correttamente, un problema di leak molto simile a quello che chi scrive plugin system in .NET conosce già.Cosa cambia in pratica, oltre al Domain ReloadLa migrazione a CoreCLR porta con sé una serie di conseguenze pratiche per chi sviluppa con Unity:ECS più integrato: gli Instance ID passano da 32 a 64 bit, permettendo a GameObject “classici” ed entità ECS (Data-Oriented Technology Stack) di condividere lo stesso spazio di identificatori. Un nuovo metodo GetEntityId() collega direttamente gli oggetti di scena al mondo ECS, riducendo la frizione tra i due paradigmi.Serializzazione nativa dei dizionari: Dictionary<TKey, TValue> sarà finalmente serializzabile nativamente dall’Inspector, eliminando i workaround basati su liste parallele di chiavi e valori o su ISerializationCallbackReceiver. In parallelo, Unity rimuove il datato e insicuro BinaryFormatter.IL2CPP resta, ma diventa opzionale: per le piattaforme non coperte da NativeAOT (che CoreCLR usa per la compilazione ahead-of-time), IL2CPP continuerà a essere il backend di scripting necessario. Su piattaforme compatibili, però, sarà possibile scegliere CoreCLR come backend alternativo già a partire da una preview tecnica prevista intorno a Unity 6.7.MiMalloc come allocatore di memoria: l’integrazione dell’allocatore ad alte prestazioni di Microsoft riduce i problemi di lock contention nei carichi multithread, con benefici diretti per chi usa il C# Job System in scenari data-oriented.Perché la cosa interessa anche chi non fa game devIl percorso di Unity da Mono a CoreCLR è, in piccolo, lo stesso tipo di migrazione che molte software house con applicazioni .NET Framework legacy dovranno affrontare prima o poi: passare da un modello di isolamento basato su AppDomain (o peggio, da un fork custom del runtime) a un’architettura moderna basata su ALC, con tutti i vantaggi in termini di performance, ma anche le insidie legate alla gestione del ciclo di vita degli assembly caricati dinamicamente. Se lavorate su plugin system, hosting di codice di terze parti o architetture a moduli scaricabili a runtime, vale la pena studiare da vicino come Unity gestisce concretamente i leak di ALC: è un problema che, presto o tardi, si incontra in qualunque applicazione .NET che provi a fare hot-reload o isolamento dinamico.ConclusioneCon Unity 6.8, il motore smette di essere un’isola separata dall’ecosistema .NET e si allinea finalmente al runtime moderno, portando in dote C# 14, prestazioni migliori e un developer loop molto più rapido. Per chi sviluppa giochi è una notizia enorme; per chi sviluppa in .NET in generale è un promemoria utile su come affrontare, con gli strumenti giusti, la migrazione da architetture di isolamento legacy a AssemblyLoadContext.Fonte: DZone, con dettagli tecnici dal thread ufficiale Path to CoreCLR, 2026: Upgrade Guide su Unity Discussions.

Il 28 luglio 2026 entra in vigore la nuova revisione della specifica Model Context Protocol (MCP), lo standard aperto introdotto da Anthropic che permette ai modelli AI di collegarsi in modo sicuro a strumenti e sorgenti dati esterne. Non si tratta di un aggiornamento cosmetico: la revisione 2026-07-28 ridisegna il nucleo del protocollo, passando da un modello con stato a uno completamente stateless, e introduce cambiamenti che toccano direttamente chi progetta, ospita o consuma server MCP in produzione.Per chi lavora con agenti AI e integrazioni enterprise, questa è una di quelle revisioni che vale la pena capire in dettaglio prima che arrivi la versione finale, perché tocca scalabilità, autenticazione e compatibilità con le versioni precedenti.Dal protocollo con stato al core statelessNelle versioni precedenti di MCP, un client doveva eseguire un handshake initialize prima di poter fare qualsiasi cosa: il server rispondeva con un identificatore di sessione da includere in ogni richiesta successiva. Chi ha provato a mettere in produzione un server MCP dietro un load balancer conosce il problema: il client restava “incollato” a una specifica istanza, e scalare orizzontalmente richiedeva sticky session o uno store di sessione condiviso.La revisione 2026-07-28 elimina sia l’handshake initialize sia il concetto stesso di sessione a livello di protocollo. Ogni richiesta è ora autosufficiente: versione del protocollo, informazioni sul client e capability dichiarate viaggiano in ogni singola chiamata invece di essere negoziate una volta sola all’apertura della connessione. Un nuovo metodo, server/discover, permette al client di recuperare le capability del server solo quando gli servono davvero.La conseguenza pratica è che, non esistendo più un identificatore di sessione, qualsiasi richiesta può essere instradata verso qualunque istanza del server. Diventa possibile piazzare un server MCP dietro un banale load balancer round-robin, senza sticky session né store condiviso. Se un’applicazione ha comunque bisogno di mantenere uno stato tra una chiamata e l’altra, la soluzione prevista è restituire un handle esplicito (ad esempio un ID di un “carrello” o di una sessione applicativa) da uno strumento, e far sì che il client lo passi indietro come un normale argomento nelle chiamate successive. È lo stesso pattern usato da anni nelle API REST stateless: lo stato non sparisce, si sposta semplicemente dal trasporto al payload applicativo.Multi Round-Trip Requests: confermare senza tenere aperta una connessioneUn protocollo stateless ha comunque bisogno di un modo per gestire i casi in cui un server deve chiedere qualcosa al client a metà di una chiamata, per esempio una conferma dell’utente prima di eseguire un’operazione sensibile. Nelle versioni precedenti questo richiedeva tenere aperto uno stream Server-Sent Events per tutta la durata dell’interazione. La nuova revisione sostituisce questo meccanismo con le Multi Round-Trip Requests (MRTR).Quando un server ha bisogno di input dall’utente durante l’esecuzione di uno strumento, restituisce un oggetto InputRequiredResult contenente le domande da porre e un blob requestState. Il client raccoglie le risposte e riemette la chiamata originale includendo sia le risposte sia lo stato “echoed” ricevuto in precedenza. Poiché tutto ciò che serve al server è contenuto nel payload, qualunque istanza del server può gestire il retry, anche se è diversa da quella che ha generato la richiesta iniziale. È un dettaglio che semplifica enormemente il deployment di server MCP dietro infrastrutture di bilanciamento del carico stateless.Header instradabili e caching esplicitoDue modifiche più contenute a livello di trasporto rendono il traffico MCP molto più facile da osservare e instradare in produzione. Il trasporto Streamable HTTP richiede ora un header Mcp-Method su ogni richiesta, mentre l’header Mcp-Name è obbligatorio solo per tipi di richiesta specifici, come tools/call, resources/read e prompts/get. Un gateway o un load balancer può leggere questi header per instradare il traffico senza dover analizzare il corpo della richiesta, un vantaggio non trascurabile per chi gestisce infrastrutture MCP a scala aziendale. I server rifiutano le richieste in cui header e corpo non sono coerenti tra loro.In secondo luogo, i risultati di liste e letture di risorse ora includono i campi ttlMs e cacheScope, modellati sul comportamento dell’header HTTP Cache-Control. I client sanno esattamente per quanto tempo una risposta a tools/list resta valida e se può essere condivisa tra utenti diversi. Non è più necessario mantenere uno stream a lungo termine solo per scoprire che una lista è cambiata: un pattern di polling con cache esplicita è sufficiente.Autenticazione più rigorosa, allineata a OAuth 2.0La revisione stringe le regole di autorizzazione per allinearle più da vicino a OAuth 2.0 e OpenID Connect. I client devono ora validare il parametro iss nelle risposte di autorizzazione secondo la RFC 9207, una mitigazione contro i “mix-up attack”, una classe di attacchi più rilevante nel pattern tipico di MCP in cui un singolo client dialoga con molti server diversi.I client devono inoltre dichiarare il proprio application_type durante la Dynamic Client Registration, così gli authorization server non assumono più di default che i client desktop o CLI siano applicazioni “web”, evitando il rifiuto ingiustificato dei redirect URI su localhost. Le credenziali vengono vincolate all’authorization server che le ha emesse, e la specifica chiarisce come richiedere i refresh token durante l’autenticazione step-up.Funzionalità deprecate: cosa cambia per chi ha già integrato MCPTre funzionalità core vengono formalmente deprecate: Roots, Sampling e Logging. Roots permetteva a un client di dichiarare i confini del filesystem a un server; Sampling permetteva a un server di chiedere al modello del client di generare testo per suo conto; Logging forniva notifiche a livello di protocollo dal server al client.La deprecazione non significa rimozione immediata: questi metodi, tipi e capability flag continuano a funzionare in questa release e in ogni versione della specifica pubblicata entro un anno da essa. Da qui in poi, però, sono su un orologio di rimozione. Le alternative consigliate sono parametri degli strumenti o URI di risorse al posto di Roots, integrazione diretta con le API dei provider LLM al posto di Sampling, e OpenTelemetry per l’osservabilità strutturata al posto del Logging di protocollo. Chi mantiene librerie o server MCP dovrebbe iniziare a pianificare la migrazione già da ora.Schema degli strumenti, codici di errore ed estensioniGli schema di input e output degli strumenti utilizzano ora JSON Schema 2020-12 completo. Gli schema di input mantengono il vincolo della radice type: "object" ma ora permettono composizione con oneOf, anyOf e allOf, oltre a condizionali e riferimenti. Gli schema di output non hanno più restrizioni, e structuredContent può essere qualsiasi valore JSON, non solo un oggetto.Il codice di errore per una risorsa mancante cambia dal valore custom MCP -32002 allo standard JSON-RPC -32602 (Invalid Params). Chi ha client che fanno pattern matching sul valore letterale -32002 deve aggiornare quel codice prima del 28 luglio.Le estensioni, già presenti nella release precedente ma senza un processo formale, ricevono ora una struttura definita: sono identificate da ID reverse-DNS, negoziate tramite una mappa extensions, e vivono in repository indipendenti con maintainer dedicati, versionando separatamente dalla specifica principale. Due estensioni ufficiali arrivano con questa release: MCP Apps, che permette ai server di fornire interfacce HTML interattive renderizzate dagli host in un iframe sandboxed, e Tasks, promossa da funzionalità sperimentale a estensione ufficiale, che fornisce un modello stateless per lavori a lunga esecuzione: un server può rispondere a tools/call con un task handle, e il client lo gestisce con tasks/get, tasks/update e tasks/cancel.SDK beta disponibili da subitoSono già disponibili release beta degli SDK Python, TypeScript, Go e C#. Python v2 rinomina FastMCP in MCPServer ma mantiene l’API a decoratori. TypeScript v2 divide l’SDK monolitico in pacchetti focalizzati come @modelcontextprotocol/server e @modelcontextprotocol/client, ed è ora ESM-only. Go integra il supporto alla revisione 2026-07-28 in v1.7.0-pre.1 sullo stesso module path. C# rilascia la versione 2.0.0-preview.1 dei pacchetti ModelContextProtocol.Per chi ha già server e client in produzione, la buona notizia è che nulla si rompe automaticamente il giorno del rilascio: i nuovi client che parlano la revisione 2026-07-28 tornano automaticamente all’handshake initialize quando raggiungono un server che implementa una versione precedente o uguale al 2025-11-25. Chi però pubblica librerie che dipendono dal pacchetto Python mcp dovrebbe aggiungere un limite superiore esplicito, per esempio mcp>=1.27,<2, in modo che il passaggio alla v2 stabile non colga di sorpresa gli utenti del proprio pacchetto.ConclusioneLa revisione 2026-07-28 di MCP è un cambiamento strutturale, non un semplice aggiornamento incrementale. Il core stateless elimina la necessità di session affinity e semplifica scaling orizzontale e load balancing di server MCP in produzione. I nuovi pattern come le MRTR e gli header instradabili rendono il protocollo più facile da operare su larga scala. L’irrigidimento delle regole di autorizzazione allinea MCP alle pratiche standard di OAuth e OpenID Connect, riducendo la superficie di attacco tipica delle integrazioni multi-server. Le funzionalità deprecate restano funzionanti per ora, ma vanno sostituite secondo un piano preciso prima che scada la finestra di un anno.Chi sviluppa o ospita server MCP dovrebbe testare gli SDK beta contro i propri carichi di lavoro prima della data finale del 28 luglio, verificando in particolare la gestione dei codici di errore, la compatibilità dei client con l’handshake legacy e l’impatto delle nuove regole di autorizzazione sulle integrazioni desktop e CLI esistenti.Fonte: 4sysops.com

Chi sta integrando agenti AI in pipeline CI/CD si scontra presto con un problema pratico: come si testano in modo affidabile le “skill” di un agente (le istruzioni locali che gli insegnano quando e come usare una capacità) senza colpire API reali, senza costi imprevedibili e senza risultati non deterministici? La risposta che sta emergendo nella comunità DevOps combina due strumenti complementari: Dev Proxy di Microsoft per simulare le API a livello di rete, e Promptfoo per valutare in modo strutturato se una skill funziona meglio di un’altra.Vale la pena approfondire entrambi gli approcci, perché il problema che risolvono — testare comportamento non deterministico in modo ripetibile — è ormai centrale per chiunque gestisca agenti AI in produzione, non solo per chi scrive skill per Claude o Codex.Perché i mock server tradizionali falliscono con gli agenti AIL’approccio classico al test di un’integrazione API è il mock server: si sostituisce l’endpoint reale con uno fittizio, spesso puntando l’applicazione a localhost. Con gli agenti AI questo approccio introduce un problema sottile ma serio: cambiare l’URL di una skill per puntare a un server di test altera il contesto di token visto dal modello. Il modello che si sta testando non è più identico, a livello di token, a quello che verrà effettivamente distribuito in produzione. Questa discrepanza introduce una variabile nascosta che può invalidare i risultati della valutazione e produrre comportamenti inattesi una volta in produzione, quando la skill torna a puntare agli URL reali.Un approccio più efficace consiste nell’usare un proxy leggero che intercetta il traffico HTTP e restituisce dati predefiniti letti da file JSON locali, senza mai modificare gli URL che l’agente chiama. È esattamente il compito per cui è nato Dev Proxy: l’agente continua a chiamare gli URL di produzione, ma riceve risposte deterministiche senza che avvenga alcuna chiamata di rete reale né alcuna gestione di server. I dati si azzerano a ogni esecuzione, il contesto di token resta identico a quello di produzione, e diventa possibile eseguire test di regressione rigorosi all’interno di pipeline CI/CD.Dev Proxy: simulare le API senza toccare il codiceDev Proxy è uno strumento a riga di comando, open source e gratuito, che funziona su qualsiasi piattaforma e con qualsiasi stack tecnologico, perché intercetta le richieste di rete invece di agganciarsi al codice dell’applicazione. Le funzionalità principali coprono scenari che vanno ben oltre il semplice mocking:Simulare errori delle API senza modificare una riga di codice, per verificare che l’app non perda dati dei clienti quando una dipendenza esterna fallisceSimulare rate limiting per verificare che l’applicazione gestisca correttamente il throttlingSimulare latenza e risposte lente per validare le protezioni lato UXGenerare rapidamente mock API CRUD senza scrivere codice destinato a non essere mai distribuitoFornire guida contestuale su permessi e best practice, in particolare per chi integra Microsoft GraphPer il caso specifico degli agenti AI, Dev Proxy include funzionalità dedicate ai language model che permettono di simulare scenari realistici e tracciare l’uso delle risorse, oltre a un tool integrato nel proprio server MCP che fornisce agli agenti di coding raccomandazioni su come costruire le configurazioni. In pratica, un team che sviluppa una skill che chiama un’API esterna può configurare Dev Proxy per intercettare quelle chiamate specifiche e restituire fixture JSON versionate insieme al codice, garantendo che ogni esecuzione della pipeline CI/CD parta da uno stato pulito e riproducibile.Promptfoo: valutare quale versione di una skill funziona meglioSimulare le API risolve solo metà del problema. L’altra metà è capire, in modo misurabile, se una skill fa il proprio lavoro correttamente e se una nuova versione è effettivamente migliore della precedente. È qui che entra in gioco Promptfoo, un framework di valutazione che permette di confrontare due versioni della stessa skill eseguendo gli stessi task fianco a fianco.Il pattern di base è semplice: si mantengono identici il modello, i file di task e i permessi, cambiando solo il file SKILL.md tra una versione e l’altra. Una struttura tipica per confrontare due versioni di una skill review-standards è organizzata così:skill-eval/ ├── promptfooconfig.yaml └── fixtures/ ├── v1/ │ ├── .claude/skills/review-standards/SKILL.md │ └── src/auth.ts └── v2/ ├── .claude/skills/review-standards/SKILL.md └── src/auth.tsNel file di configurazione si definiscono due provider basati sul Claude Agent SDK, identici tranne che per la working_dir, che punta alla fixture v1 o v2:providers: - id: anthropic:claude-agent-sdk label: review-standards-v1 config: model: claude-sonnet-4-6 working_dir: ./fixtures/v1 setting_sources: ['project'] skills: ['review-standards'] append_allowed_tools: ['Read', 'Grep', 'Glob'] - id: anthropic:claude-agent-sdk label: review-standards-v2 config: model: claude-sonnet-4-6 working_dir: ./fixtures/v2 setting_sources: ['project'] skills: ['review-standards'] append_allowed_tools: ['Read', 'Grep', 'Glob']Il parametro setting_sources: ['project'] fa scoprire a Promptfoo i file SKILL.md sotto .claude/skills/, mentre il filtro skills: restringe la sessione a una singola skill e ne abilita automaticamente il tool associato. Per Codex o OpenCode la struttura equivalente usa .agents/skills/ al posto di .claude/skills/, ma la logica di confronto resta identica.Tre livelli di asserzioni per un confronto solidoUna valutazione utile si costruisce a strati. Il primo verifica semplicemente che la skill sia stata invocata:defaultTest: assert: - type: skill-used value: review-standardsClaude espone le chiamate al tool Skill direttamente, e Promptfoo le normalizza nell’asserzione skill-used: questo distingue una risposta corretta ottenuta senza passare dalla skill da una prodotta effettivamente attraverso il workflow che si vuole testare, una distinzione che spesso sfugge a chi valuta solo la qualità della risposta finale.Il secondo livello valuta la qualità del lavoro svolto, per esempio calcolando quanti problemi attesi sono stati effettivamente individuati in una revisione di codice, con una soglia di recall minima. Il terzo livello aggiunge segnali secondari come costo e latenza, utili quando due versioni sono entrambe corrette ma una è molto più lenta o costosa dell’altra:defaultTest: assert: - type: cost threshold: 0.50 - type: latency threshold: 120000Per chi gestisce bundle di skill correlate, un errore comune è testare solo il percorso “felice” di ciascuna skill. Vale la pena aggiungere anche prompt limite che dovrebbero instradare verso una skill vicina, asserendo sia la skill desiderata sia quella che non deve attivarsi, con il costrutto not-skill-used. Questo cattura i casi in cui una skill risolve correttamente il task ma si attiva anche quando non dovrebbe, un problema di “routing” difficile da individuare guardando solo l’output finale.Mettere insieme i due strumenti in CI/CDLa combinazione pratica è: Dev Proxy intercetta le chiamate API reali fatte durante l’esecuzione della skill e restituisce fixture deterministiche, mentre Promptfoo esegue lo stesso set di task contro versioni diverse della skill e assegna un punteggio ai risultati. L’eval si lancia con un semplice comando:npx promptfoo@latest eval -c promptfooconfig.yamlAggiungendo --repeat 3 si ottiene un campione più robusto del comportamento non deterministico dell’agente, mentre --no-cache è utile durante l’iterazione sul testo della skill per garantire risultati sempre freschi. Il comando npx promptfoo@latest view apre una vista web che affianca i risultati delle due versioni, rendendo immediato individuare dove una skill supera l’altra.ConclusioneIl punto centrale di entrambi gli strumenti è lo stesso: eliminare le variabili nascoste che rendono inaffidabile il test di un comportamento non deterministico. Dev Proxy garantisce che il contesto visto dal modello in test sia identico a quello di produzione, eliminando la variabile del cambio di URL. Promptfoo garantisce che il confronto tra due versioni di una skill sia equo, isolando l’unica variabile che conta — il testo della skill stessa — e fornendo asserzioni misurabili su invocazione, qualità, costo e latenza.Per un team che già gestisce pipeline CI/CD tradizionali, l’investimento per aggiungere questo livello di test alle proprie skill AI è relativamente contenuto: entrambi gli strumenti sono open source, si integrano con gli SDK di Claude, Codex e OpenCode, e restituiscono risultati confrontabili senza richiedere infrastruttura dedicata oltre a quella già in uso per il testing tradizionale.Fonti: 4sysops.com, Microsoft Learn – Dev Proxy, Promptfoo – Test Agent Skills

Cosa cambia con la GA dei browser toolsDal 1° luglio 2026 i browser tools per GitHub Copilot in Visual Studio Code sono generalmente disponibili (GA) e attivi di default. Non si tratta di una semplice estensione per il debugging: gli agenti di Copilot ottengono ora le stesse azioni che un developer compirebbe normalmente in un browser reale — aprire pagine, navigare, cliccare, digitare, gestire dialog, leggere il contenuto del DOM, catturare errori di console e screenshot, fino all’esecuzione di flussi scriptati quando conviene eseguire una sequenza di passi invece di tante singole chiamate a tool.Per chi lavora quotidianamente su applicazioni web — sviluppo frontend, test end-to-end, troubleshooting di regressioni UI — questa funzionalità cambia sensibilmente il flusso di lavoro con l’AI: l’agente può verificare da solo se una modifica ha funzionato, invece di chiedere all’utente di incollare uno screenshot o l’output della console.Cosa può fare davvero l’agente nel browserSotto il cofano, VS Code espone all’agente un set di azioni equivalenti a quelle di uno strumento di automazione come Playwright, ma integrate direttamente nell’editor:Apertura e navigazione di pagine, click, digitazione testo, hover, drag and drop, gestione di dialog nativi del browser.Lettura del contenuto della pagina, cattura degli errori di console e degli screenshot per il debugging visivo.Esecuzione di flussi scriptati quando una sequenza di passi predefinita è più efficiente di singole chiamate a tool separate.Le DevTools restano comunque disponibili direttamente nella toolbar del browser integrato, così lo sviluppatore può ispezionare elementi, leggere la console e fare debug manuale in parallelo a quanto fa l’agente.Il modello di permessi: cosa resta sotto il tuo controlloDare a un agente AI la capacità di pilotare un browser reale solleva ovvie domande di sicurezza. Il team di VS Code ha progettato il modello di permessi attorno a tre principi:Le tue schede restano private di defaultL’agente non può leggere né interagire con una scheda che hai aperto tu finché non selezioni esplicitamente Share with Agent. L’accesso concesso può essere revocato in qualsiasi momento.Le schede dell’agente sono isolateLe pagine che l’agente apre autonomamente girano in sessioni pulite, senza accesso a cookie o storage della tua normale sessione di navigazione. Se esegui più agenti in parallelo nella finestra Agents, ciascuno mantiene le proprie schede private rispetto agli altri.I permessi sensibili restano manualiFotocamera, microfono, geolocalizzazione, notifiche e lettura della clipboard non vengono mai concessi automaticamente: ogni sito richiede un’approvazione esplicita da parte tua, e l’agente non può approvarli al posto tuo. Solo azioni a basso rischio, come la scrittura sanificata sulla clipboard, sono consentite di default.Controlli enterprise e configurazione della retePer chi gestisce flotte di postazioni sviluppatore, VS Code espone controlli centralizzati pensati proprio per governare questa superficie:// settings.json — disabilitare completamente i browser tools
{
 "workbench.browser.enableChatTools": false
}

// Limitare i domini raggiungibili dagli agenti e dal browser integrato
{
 "chat.agent.networkFilter": true,
 "chat.agent.allowedNetworkDomains": [
 "*.miaazienda.it",
 "github.com"
 ],
 "chat.agent.deniedNetworkDomains": [
 "*.pagamenti-esterni.com"
 ]
}La regola pratica da tenere a mente in produzione: gli elenchi di domini negati hanno sempre precedenza su quelli consentiti, ed entrambi supportano wildcard (ad esempio *.example.com). Restano inoltre attivi i normali prompt di Workspace Trust e le approvazioni già previste per gli altri tool dell’agente, quindi l’attivazione dei browser tools non aggira le policy di sicurezza esistenti a livello di workspace.Un caso d’uso pratico: test end-to-end guidato dall’agenteUn flusso tipico che questa funzionalità sblocca è la verifica autonoma di una modifica UI. Dopo aver chiesto a Copilot di correggere un bug nel form di login, si può semplicemente chiedere all’agente di “aprire l’app in locale, compilare il form con credenziali di test e verificare che il redirect alla dashboard funzioni”. L’agente aprirà una scheda browser isolata, eseguirà i passaggi, catturerà eventuali errori di console e screenshot, e riporterà l’esito direttamente in chat, senza che lo sviluppatore debba fare context switch verso il browser.Per team con suite di test end-to-end già basate su Playwright o Cypress, i browser tools non sostituiscono la pipeline CI, ma accorciano il ciclo di iterazione locale: si individua un problema, si corregge, si verifica visivamente, il tutto restando nell’editor.Come iniziareLa funzionalità è disponibile sia nella finestra dell’editor sia nella finestra Agents. È sufficiente aggiornare VS Code all’ultima versione e chiedere all’agente di aprire o testare una pagina: i browser tools sono attivi per impostazione predefinita da GA in poi. Per la documentazione completa, si vedano le pagine ufficiali sui browser tools per gli agenti e la relativa guida al testing con agenti nel browser.ConclusioneIl passaggio a GA dei browser tools segna un salto di maturità per gli agenti AI integrati in VS Code: da assistenti che scrivono codice sulla fiducia, a strumenti capaci di verificare autonomamente il proprio lavoro in un ambiente reale. Per i team enterprise, la combinazione di isolamento delle sessioni, permessi granulari e filtri di rete configurabili rende la funzionalità adottabile anche in contesti con requisiti di sicurezza stringenti, a patto di configurare fin da subito le allowlist di dominio e di rivedere periodicamente chi ha accesso a quali capacità.Fonte: GitHub Changelog — Browser tools for GitHub Copilot in VS Code are generally available

PostgreSQL 19 Beta 1: due novità che meritano attenzioneIl 4 giugno 2026 il PostgreSQL Global Development Group ha rilasciato la prima beta di PostgreSQL 19, con disponibilità generale attesa tra settembre e ottobre 2026. Tra le decine di miglioramenti elencati nelle release notes, due si distinguono per l’impatto pratico su chi gestisce database in produzione: il supporto nativo alle SQL Property Graph Queries (SQL/PGQ) e il nuovo comando REPACK, che introduce finalmente una modalità CONCURRENTLY per riorganizzare le tabelle senza bloccare le scritture. Vale la pena approfondire entrambe, perché rispondono a due esigenze molto concrete: interrogare relazioni complesse senza migrare verso un database a grafo dedicato, e liberare spazio su disco senza fermare l’applicazione.SQL/PGQ: query a grafo sulle tue tabelle relazionali esistentiSQL/PGQ è la Parte 16 dello standard ISO/IEC 9075 (SQL:2023) e definisce un modo standard per esprimere query di pattern matching su grafi usando sintassi SQL. La scelta implementativa di PostgreSQL è particolarmente interessante: un property graph non è una nuova struttura di storage, ma una vista in sola lettura sopra tabelle relazionali già esistenti. I dati restano dove sono sempre stati — in tabelle normali, con vincoli di chiave primaria ed esterna — e vengono semplicemente “esposti” come grafo per le query che lo richiedono. Query relazionali e query a grafo condividono lo stesso planner e lo stesso motore di esecuzione, e possono anche essere combinate nella stessa istruzione.Per capire la sintassi conviene partire da uno schema minimo di e-commerce:CREATE TABLE products ( product_no integer PRIMARY KEY, name varchar, price numeric ); CREATE TABLE customers ( customer_id integer PRIMARY KEY, name varchar, address varchar ); CREATE TABLE orders ( order_id integer PRIMARY KEY, ordered_when date ); CREATE TABLE order_items ( order_items_id integer PRIMARY KEY, order_id integer REFERENCES orders (order_id), product_no integer REFERENCES products (product_no), quantity integer ); CREATE TABLE customer_orders ( customer_orders_id integer PRIMARY KEY, customer_id integer REFERENCES customers (customer_id), order_id integer REFERENCES orders (order_id) );Le prime tre tabelle diventano i vertici del grafo, le ultime due — grazie alle chiavi esterne che collegano coppie di vertici — diventano gli archi. La definizione del grafo è dichiarativa:CREATE PROPERTY GRAPH myshop VERTEX TABLES ( products LABEL product, customers LABEL customer, orders LABEL "order" ) EDGE TABLES ( order_items SOURCE orders DESTINATION products LABEL contains, customer_orders SOURCE customers DESTINATION orders LABEL has_placed );Da qui in poi si può interrogare il grafo con la clausola GRAPH_TABLE e la sintassi di pattern matching, invece delle classiche JOIN:SELECT customer_name FROM GRAPH_TABLE ( myshop MATCH (c IS customer)-[IS has_placed]->(o IS "order" WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name) );che corrisponde, dal punto di vista relazionale, a:SELECT customers.name FROM customers JOIN customer_orders USING (customer_id) JOIN orders USING (order_id) WHERE orders.ordered_when = current_date;La differenza diventa evidente man mano che i pattern si complicano: catene di relazioni a più salti, percorsi variabili, ricerche “chi è collegato a chi entro N passaggi” sono espressioni naturali in sintassi a grafo, ma diventano rapidamente catene di self-join illeggibili in SQL relazionale puro. Per chi lavora su organigrammi, grafi di dipendenze tra servizi, reti di frodi o raccomandazioni, SQL/PGQ evita di dover affiancare un database a grafo dedicato (Neo4j, Amazon Neptune) solo per questo tipo di interrogazioni, con tutto il costo operativo che una piattaforma aggiuntiva comporta.È bene ricordare che, essendo una vista sopra le tabelle esistenti, un grafo così definito eredita automaticamente permessi, vincoli e integrità referenziale già presenti: non introduce una nuova copia dei dati da tenere sincronizzata.REPACK CONCURRENTLY: addio alle finestre di manutenzione per VACUUM FULLChi amministra PostgreSQL conosce bene il dilemma tra VACUUM normale, che non recupera sempre tutto lo spazio occupato da tuple morte, e VACUUM FULL (o CLUSTER), che lo recupera per intero ma richiede un ACCESS EXCLUSIVE lock per l’intera durata dell’operazione — inaccettabile su una tabella calda in produzione. PostgreSQL 19 risolve il problema unificando le due funzionalità in un unico comando, REPACK, e aggiungendo un’opzione CONCURRENTLY che cambia le regole del gioco.-- Riorganizza una tabella riscrivendola su nuovo file, senza clustering REPACK employees; -- Riorganizza mantenendo l'app pienamente operativa in lettura/scrittura REPACK (CONCURRENTLY) employees; -- Repack con clustering fisico secondo un indice, più ANALYZE finale REPACK (ANALYZE, VERBOSE) cases (district, case_nr);Il meccanismo interno spiega perché questa opzione è sicura da usare su tabelle attive: REPACK copia il contenuto della tabella (ignorando le tuple morte) in un nuovo file, ordinato secondo l’indice specificato se presente, e crea nuovi file anche per gli indici collegati. Con CONCURRENTLY, l’ACCESS EXCLUSIVE lock viene acquisito solo per lo scambio finale dei file: le modifiche avvenute durante la copia vengono catturate tramite logical decoding e riapplicate prima dello swap, che quindi risulta tipicamente molto breve. La tabella resta leggibile e scrivibile per la quasi totalità dell’operazione.Ci sono comunque limiti operativi da conoscere prima di affidarsi a questa modalità in produzione: CONCURRENTLY non è disponibile su tabelle UNLOGGED, su tabelle partizionate, su tabelle prive di chiave primaria e di un’identità di replica basata su indice, su cataloghi di sistema o tabelle TOAST, né dentro un blocco di transazione. Serve inoltre che max_repack_replication_slots consenta la creazione di uno slot di replica aggiuntivo, dato che il meccanismo si appoggia alla logical decoding. Va anche segnalato che REPACK CONCURRENTLY non è MVCC-safe nello stesso senso di altre operazioni online, quindi vale la pena leggere con attenzione la sezione sulle caveat di MVCC nella documentazione prima di pianificarne l’adozione su carichi critici.Il progresso dell’operazione è osservabile in tempo reale tramite la vista pg_stat_progress_repack, utile per stimare i tempi su tabelle di grandi dimensioni prima di schedulare l’operazione su ambienti con SLA stringenti.Altre novità rilevanti per chi amministra database in produzioneOltre alle due funzionalità principali, la beta introduce una serie di miglioramenti che meritano di essere tenuti d’occhio in fase di test: l’autovacuum può ora usare worker paralleli (autovacuum_max_parallel_workers), le inserzioni con controlli di chiave esterna sono fino a due volte più veloci, e il nuovo comando WAIT FOR LSN permette di implementare pattern “read-your-writes” verso le repliche senza più bisogno di sleep applicativi o di forzare le letture sul primario. Da segnalare anche un cambiamento di default che avrà impatto diretto sui workload analitici: la compilazione JIT (jit) è ora disattivata di default, il che può alterare sensibilmente i piani e i tempi di query che finora beneficiavano (o soffrivano) silenziosamente della compilazione just-in-time.ConclusionePostgreSQL 19 conferma la strategia degli ultimi anni: estendere le capacità del database relazionale invece di costringere i team a moltiplicare le piattaforme specializzate. SQL/PGQ evita un database a grafo dedicato per molti casi d’uso comuni, mentre REPACK CONCURRENTLY chiude una lacuna operativa che gli amministratori PostgreSQL si portavano dietro da anni. Trattandosi ancora di una beta, entrambe le funzionalità vanno testate su ambienti non di produzione prima della GA prevista per l’autunno 2026, ma la direzione presa merita già di essere seguita da vicino da chi pianifica le prossime migrazioni.Fonte: PostgreSQL Global Development Group — PostgreSQL 19 Beta 1 Released!