Settimana del 12–18 ottobre 2026 · Pubblicazione: 19 ottobre 2026. Una release candidate, un cambio di rappresentazione nel runtime, una nuova frontiera per il retrieval geografico e un problema ancora irrisolto nei sistemi agentici: l'affidabilità delle operazioni esterne. Il punto comune non è il numero di nuove API, ma il luogo nel quale viene trasferita la complessità: dal compilatore al runtime, dalle coordinate agli embedding, dal programmatore alle convenzioni che guidano gli agenti, dall'esecuzione volatile alla persistenza dei workflow.
.NET 11 RC2: ottimizzare le astrazioni, non soltanto i cicli
Il 13 ottobre 2026 Microsoft ha rilasciato .NET 11 Release Candidate 2, con licenza go-live. Non è la versione finale; la compatibilità di applicazioni e dipendenze va verificata sui workload reali. Tra i cambiamenti specifici di RC2 figurano CborReader incrementale, API sperimentali di crittografia post-quantum, una nuova impostazione per la concorrenza iniziale HTTP/2 e modifiche comportamentali al file locking su iOS/tvOS. Fonti: annuncio .NET 11 RC2 (13 ottobre) · release notes delle librerie RC2.
Runtime async: il confine Task<T> non deve necessariamente diventare un oggetto
Il lavoro descritto da Stephen Toub in Performance Improvements in .NET 11 (15 settembre) è il contesto tecnico più importante per leggere la release. Il lowering classico di C# produce per ogni metodo async una state machine con MoveNext e un builder; un metodo A che attende B che attende C porta con sé confini logici spesso materializzati in task intermedi. In runtime async, invece, il compilatore emette IL più compatto e il runtime/JIT può usare una variante AsyncCall della chiamata per passare direttamente il risultato o collegare le continuation, evitando la materializzazione dei task intermedi quando non sono osservabili. Un'API che espone un Task continua a rispettare il suo contratto. Fonte: analisi originale del runtime e benchmark di Toub.
// Applicazione .NET 11: feature opt-in (non default)
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net11.0</TargetFramework>
<Features>$(Features);runtime-async=on</Features>
</PropertyGroup>
</Project>La feature è opt-in per l'applicazione, mentre gran parte del framework incluso in .NET 11 è già compilato con questo meccanismo. Sono supportati Task, Task<T>, ValueTask e ValueTask<T>; async void, iteratori asincroni e alcuni task-like personalizzati mantengono il lowering tradizionale. Il guadagno dipende dalla forma della call chain e dalla quota di confini realmente eliminabili. Non equivale a una garanzia di zero allocazioni, né rende ValueTask obsoleto. Fonte: limiti e compatibilità di runtime async.
Analisi architetturale. Si riduce la penalità storica del codice fortemente composto in metodi asincroni brevi. Le astrazioni di dominio, i decorator, la telemetria e i livelli di servizio possono rimanere leggibili senza assumere che ogni await comporti necessariamente una nuova allocazione. Ma non è lecito estrapolare il vantaggio dalle catene sintetiche a un servizio dominato da database, rete o lock.
JIT, GC e JSON: tre ottimizzazioni con meccanismi distinti
Il JIT continua il lavoro di deabstraction: quando riesce a determinare il target effettivo di una chiamata virtuale, può devirtualizzare e rendere possibile l'inlining, aprendo la strada a constant propagation ed eliminazione di controlli superflui. Il beneficio non è “un'interfaccia più veloce” in astratto, ma una porzione più ampia di codice disponibile per l'ottimizzatore. Fonte: sezione JIT e devirtualization.
Sul fronte GC, il post documenta interventi alla gestione di metadata e handle durante le collection generazionali e ottimizzazioni Arm64: nei casi che sfruttano molti ConditionalWeakTable e dependent handles, l'età generazionale associata ai metadata condiziona quanta struttura il GC deve riesaminare. I microbenchmark pubblicati mostrano differenze importanti in configurazioni artificiali con centinaia di migliaia di handle; non sono un moltiplicatore di throughput applicativo. Fonte: sezione GC e dependent handles.
System.Text.Json sfrutta nuove scansioni basate su SearchValues per individuare byte da escapare o whitespace da saltare; una modifica al writer consente inoltre al JIT di dimostrare in anticipo che una sequenza escapata entra nel buffer, evitando bounds check ripetuti. Nel benchmark di Microsoft su una stringa volutamente satura di caratteri da escapare, la serializzazione passa da 30,83 μs (.NET 10) a 7,875 μs (.NET 11). È un caso di test mirato, non una previsione generale per i JSON REST. Fonte e codice riproducibile: JSON writer e reader in .NET 11.
HTTP/2: proteggere il burst prima del primo SETTINGS
Una novità di RC2 riguarda SocketsHttpHandler.InitialHttp2MaxConcurrentStreams. Prima che arrivi il frame SETTINGS del server, un client HTTP/2 non conosce ancora il limite effettivo di stream concorrenti della nuova connessione. La proprietà permette di impostare una soglia iniziale più bassa del default documentato di 100; dopo il frame SETTINGS prevale il valore annunciato dal peer. Un limite inferiore precedentemente osservato dallo stesso host può ridurre ulteriormente l'avvio. Fonte: API e semantica nelle release notes RC2.
using System.Net;
using System.Net.Http;
var handler = new SocketsHttpHandler
{
InitialHttp2MaxConcurrentStreams = 32
};
using var client = new HttpClient(handler);
using var request = new HttpRequestMessage(HttpMethod.Get, "https://example.org/")
{
Version = HttpVersion.Version20,
VersionPolicy = HttpVersionPolicy.RequestVersionExact
};
using var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();Valutazione. È un controllo di admission per il burst di avvio, non una sostituzione di rate limiting, backpressure e limiti di connessione. Per servizi con centinaia di richieste simultanee su connessioni appena aperte, questa impostazione merita un test che includa handshake, RTT, frame SETTINGS e numero di connessioni effettive; misurare soltanto il p50 su connessioni calde non basta.
Cryptography: “post-quantum” non significa interoperabilità automatica
Le nuove API sperimentali CompositeMLKem e Hpke richiedono controlli di supporto sulla piattaforma e opt-in agli avvisi sperimentali (SYSLIB5006 e SYSLIB5009). CompositeMLKem combina contributi classici e post-quantum; Hpke in RC2 implementa suite classiche DHKEM, non ancora suite HPKE ML-KEM o hybrid ML-KEM. Il supporto ML-KEM per destinatari CMS è documentato in RC2 per piattaforme non Windows. Fonte: precisazioni crittografiche della RC2.
Analisi. Nella progettazione di protocolli federati e applicazioni che scambiano chiavi, l'adozione dipende da profili standardizzati, suite negoziate, librerie delle controparti e policy di certificazione. Un'API sperimentale nel BCL non autorizza a modificare unilateralmente i wire format di OIDC, TLS o CMS.
Toolchain watch. Il 15 ottobre Microsoft ha presentato in preview dotnetup per macOS/Linux: installazione user-local di SDK/runtime side-by-side e rispetto dei vincoli global.json. È un miglioramento dell'ergonomia degli ambienti, non una sostituzione del pinning degli SDK nelle pipeline CI. Fonte: Introducing dotnetup (15 ottobre).
GeoAI: somiglianza semantica e vicinanza geografica non sono la stessa metrica
La documentazione ArcGIS Pro sugli embedding chiarisce un dettaglio infrastrutturale cruciale: la feature class risultante contiene un campo Embedding di tipo BLOB, con valori IEEE-754 Float32 little-endian contigui. Un vettore di dimensione D occupa esattamente 4 × D byte; quando transita in un Feature Service JSON viene veicolato in Base64. Non è un array di double e non contiene header o informazioni di modello: dimensione, versione e semantica del modello vanno gestite esternamente. Fonti: funzionamento del tool Generate Embeddings · formato BLOB e convenzioni di trasporto.
Il motore del retrieval: query polygon, aggregazione e coseno
Il tool Find Similar Features Using Embeddings prende una feature class di embedding e feature di query poligonali. Identifica gli embedding che intersecano i poligoni, ne calcola il vettore medio e confronta tale query aggregata con i candidati utilizzando la cosine similarity; la soglia filtra i risultati e l'output è una feature class. La ricerca opera sui vettori associati alle celle/feature, non sui pixel dell'immagine visualizzata nella mappa. Per la ricerca estesa Esri propone il tool di geoprocessing invece dell'esplorazione interattiva. Fonte: How Find Similar Features Using Embeddings works.
Query polygon
| spatial overlap
v
{e1, e2, ..., ek} -> q = mean(e1, ..., ek)
|
v
cosine(q, candidate_i)
|
threshold + feature output
|
v
GIS result layerQuesto meccanismo stabilisce una relazione di similarità nel latent space del modello, non una relazione di prossimità euclidea o topologica. Due aree lontane possono essere semanticamente simili; due aree contigue possono essere molto diverse per uso del suolo, tipologia edilizia o contesto ambientale. Aumentare la soglia del coseno non equivale a restringere un buffer geografico.
Analisi: spatial-semantic retrieval a due stadi. Per casi d’uso con vincoli spaziali obbligatori, conviene eseguire prima un filtro geografico esatto (intersezione, buffer, confine amministrativo, area di competenza) e poi il ranking vettoriale all’interno dei candidati ammissibili. Una combinazione pesata tra distanza geografica e coseno è possibile, ma è una politica applicativa da calibrare: non è la semantica predefinita del tool Esri.
Filtro di ammissibilità: A = {i : intersects(geometry_i, AOI)}
Ranking all'interno di A: s_i = cosine(q, embedding_i)
Risultati: topK({i in A : s_i >= soglia})
Alternativa analitica (non API Esri):
score_i = alpha * cosine_i + (1 - alpha) * exp(-distance_km_i / tau)
con alpha in [0, 1], tau > 0 e distanze in kmIl ranking misto necessita di normalizzazione, scelta del parametro di decadimento spaziale e validazione su query reali. In particolare, la media di embedding all'interno di un poligono attenua configurazioni multimodali: un'area contenente sia infrastrutture industriali sia vegetazione può generare una query che non rappresenta bene nessuna delle due classi. Un test con più query poligonali o cluster distinti può essere preferibile alla media cieca.
GeoAI interpretabile: 256 dimensioni non sono 256 variabili leggibili
Nel workflow Esri pubblicato il 6 ottobre, gli USA Geodemographic Embeddings prodotti dal GDFM sono organizzati in quattro blocchi da 64 dimensioni: housing/household, environment, American Community Survey e age/race census. AutoML con SHAP misura l'importanza media assoluta delle singole dimensioni rispetto a uno specifico task predittivo; sommare le importanze di un blocco produce una attribuzione aggregata descrittiva, non una stima causale e nemmeno un vero SHAP di gruppo. Fonte: Interpret embeddings using AutoML and SHAP (6 ottobre).
Ad esempio, un valore elevato di embedding_137 non permette di concludere che la dimensione codifichi direttamente il reddito: è un fattore latente all'interno della vista ACS. Analogamente, la somma di mean(abs(SHAP)) non coincide necessariamente con il valore di mean(abs(sum(SHAP))). Per attribuire valore predittivo incrementale a un segmento occorrono studi di ablation, retraining o permutazioni congiunte e split spaziali adeguati. Fonte: avvertenze interpretative Esri.
Interoperabilità C# e costo dei dati
Un decoder indipendente da architettura può ricostruire il formato descritto da Esri senza assumere l'endianness della macchina. Il codice seguente è un esempio .NET senza dipendenze Esri; expectedDimensions deve venire dai metadata del modello effettivamente usato.
using System;
using System.Buffers.Binary;
static float[] ReadEmbedding(ReadOnlySpan<byte> blob, int expectedDimensions)
{
if (expectedDimensions <= 0 || blob.Length != checked(expectedDimensions * 4))
throw new ArgumentException("Unexpected embedding payload size");
var result = new float[expectedDimensions];
for (int i = 0; i < result.Length; i++)
{
int bits = BinaryPrimitives.ReadInt32LittleEndian(blob.Slice(i * 4, 4));
result[i] = BitConverter.Int32BitsToSingle(bits);
}
return result;
}Valutazione. Con 256 dimensioni, il payload grezzo per feature è 1.024 byte; un milione di feature corrisponde a circa 1,024 GB decimal di soli valori vettoriali, prima di geometrie, indici, overhead geodatabase, Base64 e copie in memoria. Questa è una semplice stima D×4×N, non un benchmark del motore Esri. È necessario conservare il model identity insieme ai dati ed evitare ranking incrociati fra versioni dello stesso encoder senza valutazione di compatibilità. Documentazione: storage degli embedding · tool e requisiti CPU/GPU/licenze.
Experience Builder: un Agent Skill è una specifica operativa, non una garanzia di correttezza
Esri ha pubblicato a settembre un Agent Skill open source per lo sviluppo di custom widget ArcGIS Experience Builder. Contiene regole di struttura, riferimenti alle API, separazione fra settings e runtime, indicazioni su data source, map view, tema, traduzioni e skeleton. La guida Esri descrive l'inserimento del pacchetto skills/arcgis-exb-widget-dev nelle cartelle riconosciute da agenti compatibili; l'estensione non sostituisce il progetto Developer Edition né compila automaticamente ogni widget. Fonti: articolo tecnico Esri (14 settembre) · repository SDK Resources e skill ufficiale.
Natural-language requirement
|
v
Coding agent
/ \
Skill references Repository constraints
\ /
Generated widget
/ | \
manifest config runtime/setting
| | |
+---- build + tests ----+
|
runtime verificationNel codice reale un widget deve rispettare le convenzioni del repository di estensioni, collocarsi sotto client/your-extensions/widgets/ (o repository equivalente), pubblicare un manifest.json corretto e distinguere configurazione persistita da codice di esecuzione. Un agente che genera un componente React visivamente plausibile ma aggira DataSourceComponent, JimuMapViewComponent o le API di configurazione non ha risolto il problema di integrazione. Fonti: getting started with widget development · contratto del manifest.
Esiste anche un vincolo di ciclo di vita verificabile: Esri ha annunciato il pensionamento dei Maps SDK for JavaScript widgets utilizzati dai custom widget nelle versioni interessate a partire da Q1 2027, raccomandando la migrazione a web components. Non significa che ogni custom widget Experience Builder smetterà di funzionare: la criticità riguarda quelli che dipendono dalle vecchie API widget del Maps SDK. Esri indica inoltre il passaggio a React 19 in Experience Builder 1.19 e successivi. Fonte: avviso ufficiale di retirement e perimetro di impatto.
Analisi architetturale. Uno skill di sviluppo diventa parte della supply chain: va versionato e verificato rispetto alla versione di Experience Builder effettivamente distribuita. Il controllo automatico deve verificare dipendenze Maps SDK deprecate, API Jimu usate, manifest, compatibilità del builder, bundle e smoke test in browser. Un agent skill riduce l’incertezza sulle convenzioni, ma non sposta la responsabilità della qualità dal maintainer all’agente.
Durable AI Agents: replay deterministico, side effect non deterministici
Il 12 ottobre Microsoft ha pubblicato una lettura concreta di Durable Task con scenari di provisioning Azure, approvazione umana, pagamenti, webhook e incident management. Il riferimento usato negli esempi è il Durable Task .NET SDK v1.26.0 con Durable Task Scheduler. La lezione architetturale è precisa: una cronologia persistente consente la ricostruzione deterministica del flusso, ma non garantisce exactly-once per le operazioni sui sistemi esterni. Fonte: Durable Task in the Real World (12 ottobre).
Incident -> Collect evidence -> Generate proposal -> Save proposal identity
|
Human approval
|
proposal hash + authorized decision
|
Execute remediation (idempotency key)
|
Read-back / reconciliation
|
VerificationIn un workflow agentico la generazione del modello è un side effect: un retry può produrre un piano differente. L'output autorizzato deve avere identità immutabile e fingerprint dei parametri. Se un worker termina dopo che un provider ha eseguito l'operazione ma prima che la sua risposta sia registrata nell'orchestrazione, la ripartenza non può presumere che l'operazione sia fallita. Occorre interrogare il sistema esterno con una chiave stabile, riconciliare lo stato ed eventualmente marcare NeedsIntervention. Fonte: failure windows e riconciliazione documentati da Microsoft.
Analisi. Qui si separano tre livelli spesso confusi: deterministic replay dell'orchestrazione, idempotency dell'operazione applicativa e authorization dell'effetto richiesto. Un orchestratore può riprodurre la stessa decisione di workflow; non può rendere idempotente un pagamento, una DELETE, un deployment ARM o un tool MCP privo di meccanismi di deduplicazione e read-back. Nei sistemi agentici questa separazione è un confine di sicurezza, non soltanto una tecnica di recovery.
LLM/API lifecycle: il breaking change più costoso può arrivare dal modello, non dal codice
Nella settimana appena conclusa sono documentati due cambiamenti operativi rilevanti nell'API OpenAI. Il 14 ottobre è stata comunicata la deprecazione di snapshot GPT-4o, GPT-4o mini e GPT-4.1, con rimozione indicata al 14 gennaio 2027 e migrazione raccomandata verso gpt-6-luna. Il 15 ottobre GPT-Live ha aggiunto l'integrazione nativa con Decisions: decisioni attivabili tramite delega o dai delta di trascrizione in input/output. Fonti: tabella ufficiale delle deprecazioni · changelog API del 15 ottobre.
La Decisions API, introdotta in beta il 6 ottobre, espone classificazioni/valutazioni tipizzate (predicate, choice, score) e al momento documenta gpt-6-luna come modello supportato. Questo pattern è diverso dal tool calling generale della Responses API: è un percorso per decisioni strutturate su input testuali o visivi, non un runtime universale per tool e workflow. Fonte: riferimento POST /decisions.
Voice conversation (GPT-Live)
|
input/output transcript deltas
|
Decision evaluation
|
typed predicate / choice / score
|
policy checks + application authority
|
allowed actionAnalisi. L'integrazione voice/decisions può ridurre il lavoro applicativo di instradamento dei segnali in scenari vocali a bassa latenza, ma crea un tema di consistenza: i transcript delta sono aggiornamenti intermedi e una decisione statistica non conferisce autorizzazione. Le azioni con effetti permanenti devono restare sotto controllo di un backend con identità, policy, conferma e journal. Anche con delega a Responses, le credenziali e il modello di autorizzazione devono restare nell'applicazione. Fonti: delegation, tools e responsabilità applicative · schema delle sessioni e trigger Decisions.
Per la migrazione dei modelli, il piano corretto non è sostituire una stringa in configurazione: occorre misurare regressioni su schemi JSON, tool use, politiche di rifiuto, latenza p95/p99, costo per task riuscito e probabilità di escalation. Un modello sostitutivo nominalmente consigliato dal provider non prova l'equivalenza sul dominio applicativo. È necessaria una suite di eval ripetibile con rollback e osservabilità per versione.
Technical Takeaways
- Runtime async. Misurare le call chain reali: meno state machine materializzate non equivale a meno attese di I/O, né garantisce compatibilità perfetta di tooling non aggiornato.
- .NET 11 RC2. HTTP/2, CBOR e crittografia sperimentale riguardano confini di protocollo: le prove di interoperabilità contano più dell'elenco di API.
- GeoAI. Separare filtro spaziale e ranking semantico; conservare metadata del modello, definizione di soglia e unità geografiche insieme ai risultati.
- SHAP. Spiegare un modello basato su embedding non significa recuperare causalità né il significato univoco delle coordinate latenti.
- Experience Builder. Skills, repository conventions, version pinning e CI compongono un unico contratto tecnico; la migrazione ai web components è una verifica concreta di questo contratto.
- Agenti durevoli. Replay deterministico, idempotenza e permessi sono tre problemi distinti. Il fallimento da testare è quello tra l'effetto esterno e il suo acknowledgement.
- Model lifecycle. La scadenza di uno snapshot è un evento di release engineering: migrare con eval, canary, metriche e piano di ripristino.
Lab della settimana
Lab 1 — .NET 11: verificare la riduzione del lowering async
Prerequisiti: SDK .NET 11 RC2, shell e un progetto console. Copiare Program.cs qui sotto e aggiungere la proprietà Features in forma condizionale nel .csproj. Compilare due volte in Release, confrontando la dimensione della DLL; successivamente eseguire lo stesso carico con e senza opt-in per isolare throughput e allocazioni. La differenza di dimensione è osservabile direttamente, quella prestazionale va misurata per il workload. Protocollo e benchmark estesi: sorgenti originali dei benchmark · SDK RC2.
<PropertyGroup>
<TargetFramework>net11.0</TargetFramework>
<Features Condition="'$(RuntimeAsync)' == 'true'">$(Features);runtime-async=on</Features>
</PropertyGroup>Console.WriteLine(await Steps.A());
static class Steps
{
public static async Task<int> A() => await B();
private static async Task<int> B() => await C();
private static async Task<int> C()
{
await Task.Yield();
return 42;
}
}dotnet build -c Release -p:RuntimeAsync=false -o classic --no-incremental
dotnet build -c Release -p:RuntimeAsync=true -o runtime --no-incremental
# Confrontare la dimensione delle DLL nei due output.Criterio di successo: la build si conclude in entrambe le configurazioni, l'output del programma è identico e la DLL viene confrontata separatamente dai file di runtime e dalle dipendenze. Con soli tre metodi il delta può essere modesto; il post Microsoft mostra anche un campione a dieci layer.
Lab 2 — ArcGIS Pro: retrieval vettoriale su query poligonale
Prerequisiti: ArcGIS Pro con licenza Advanced, una feature class di embedding compatibili e un layer poligonale che rappresenti la query. La generazione preventiva degli embedding richiede un model definition .emd/.dlpk e framework deep learning, con Image Analyst per embedding da immagini. I parametri qui sotto corrispondono all'API documentata. Fonti: Generate Embeddings Using AI Models · Find Similar Features Using Embeddings.
import arcpy
embedding_features = r"C:\lab\gis.gdb\embeddings"
query_features = r"C:\lab\gis.gdb\query_polygon"
output_features = r"C:\lab\gis.gdb\similar_results"
arcpy.geoai.FindSimilarFeaturesUsingEmbeddings(
embedding_features, query_features, output_features, 0.75
)Controlli: ripetere la query cambiando soltanto poligono e soglia; confrontare risultati ad alta similarità con un buffer geografico. Se una feature risulta semanticamente simile ma lontana, non è necessariamente un errore: è il comportamento che l'esperimento deve distinguere. Documentare modello, dimensione D, extent, dataset e percentuale di candidati che superano la soglia.
Lab 3 — Agent Skill per Experience Builder: A/B test sulle convenzioni
Usare lo stesso requisito e lo stesso coding agent in due directory pulite della stessa versione di Experience Builder Developer Edition: una senza skill e una con la cartella skills/arcgis-exb-widget-dev di Esri installata secondo le istruzioni dell'agente. Implementare un widget che scelga una feature layer nelle impostazioni e mostri al runtime il conteggio delle feature filtrate nella mappa attiva. Non cambiare prompt, agent model, dipendenze o versione del builder tra le prove. Fonti: tutorial dell’Agent Skill · repository ufficiale · guida ai custom widget.
Metriche: build pass/fail; errori di manifest; uso corretto delle API data source e Jimu map view; accessibilità e traduzioni; numero di correzioni manuali; numero di iterazioni dell'agente; test del widget nell'app pubblicata. Ripetere su più run, registrando anche i fallimenti: un singolo risultato riuscito non è una misura dell'affidabilità.
Riferimenti tecnici primari: Microsoft .NET 11 RC2 · Stephen Toub — Performance Improvements in .NET 11 · Esri — Generate Embeddings internals · Esri — Similar Features internals · Esri — AutoML/SHAP · Esri — Experience Builder Agent Skill · Microsoft — Durable Task · OpenAI API changelog.
