Il tema della settimana: spostare complessità nel posto giusto
Questa settimana il filo conduttore non è una singola release, ma uno spostamento architetturale che si vede in ecosistemi apparentemente lontani. In .NET 11 una parte del lavoro di async/await può spostarsi dal compilatore C# al runtime e al JIT. In ArcGIS gli embedding stanno diventando dati GIS operativi, non semplicemente output intermedi di un modello. In Experience Builder le convenzioni di sviluppo vengono impacchettate in un Agent Skill consumabile da coding agent diversi. E nella Responses API di OpenAI il modello può delegare lavoro a subagent con contesti separati e coordinamento interno.
Il pattern comune è interessante: invece di aggiungere altra logica applicativa esplicita, una parte crescente della complessità viene trasferita verso runtime, rappresentazioni apprese e layer di orchestrazione.
Source code / GIS data / user intent
|
v
richer runtime representation
|
+--------+--------+
| | |
JIT embeddings agents
| | |
+--------+--------+
|
v
optimized executionAnalisi. La domanda da software architect non è più soltanto “quale API uso?”, ma dove deve vivere la complessità? Se può essere assorbita da un runtime che conosce meglio l'esecuzione, da una rappresentazione che conserva semantica o da un layer dichiarativo che codifica le regole del framework, il codice applicativo può diventare più semplice senza necessariamente diventare meno efficiente.
.NET 11: la performance interessante è quella che sparisce sotto il codice
Microsoft ha pubblicato il 15 settembre il consueto approfondimento di Stephen Toub sulle performance di .NET 11. Il contesto è importante: .NET 11 RC1 è disponibile dall'8 settembre con licenza go-live, quindi non stiamo parlando soltanto di esperimenti su una branch futura del runtime. Le fonti principali sono Performance Improvements in .NET 11 e Announcing .NET 11 Release Candidate 1.
Il post contiene centinaia di ottimizzazioni. Più che inseguire ogni microbenchmark, conviene cercare quelle che modificano il modello mentale con cui progettiamo applicazioni.
Runtime async: async diventa anche un problema del JIT
Tradizionalmente il compilatore C# effettua il lowering di un metodo async: genera state machine, campi per lo stato catturato, MoveNext, builder e tutto ciò che serve a trasformare il codice sorgente in IL eseguibile. Con runtime async, .NET 11 introduce un percorso diverso: per i metodi eleggibili il compilatore produce un contratto IL più compatto e il runtime/JIT assume una parte del lavoro di trasformazione.
L'opt-in applicativo documentato da Microsoft è:
<PropertyGroup>
<TargetFramework>net11.0</TargetFramework>
<Features>$(Features);runtime-async=on</Features>
</PropertyGroup>Non serve una nuova sintassi C#. L'obiettivo dichiarato è la compatibilità comportamentale: la strategia di lowering deve restare un dettaglio implementativo. Microsoft precisa anche che l'implementazione non è ancora ottimale in tutti i casi e invita a misurare prima di abilitarla in produzione. L'obiettivo per .NET 11 è almeno la parità con il lowering tradizionale, mentre l'abilitazione predefinita è indicata come possibile direzione per .NET 12.
Il passaggio architetturalmente più interessante è la possibilità di evitare di materializzare alcuni Task<T> intermedi quando una catena di metodi runtime-async si limita a chiamare e attendere direttamente il livello successivo. Il runtime mantiene due modalità correlate dello stesso metodo: il contratto pubblico che restituisce Task<T> e una variante interna utilizzabile nelle catene runtime-async. Se una chiamata completa sincronicamente, il valore può fluire verso il chiamante senza creare un Task<T> intermedio; se sospende, il runtime collega lo stato delle continuation.
A() awaits B()
|
v
B() awaits C()
|
v
C()
Classic lowering:
Task C -> state machine B -> Task B -> state machine A -> Task A
Runtime async, when the pattern is eligible:
C result / continuation
-> B
-> A
-> materialize Task only where observableIl punto non è che “Task sparisce”. Se il task viene osservato come oggetto, memorizzato o usato da API che ne richiedono l'identità, deve esistere. L'ottimizzazione elimina soprattutto i confini che sono un dettaglio di composizione e non un requisito semantico.
Nel piccolo esempio pubblicato da Microsoft con dieci livelli di metodi async, l'assembly passa da 10.752 a 5.632 byte. È un micro-esempio, non un benchmark applicativo, ma rende visibile un effetto reale: meno state machine generate significa anche meno metadata e meno IL da trasportare. La stessa documentazione indica supporto per Task, Task<T>, ValueTask e ValueTask<T>; async void, async iterator e task-like custom con builder personalizzati restano invece sul percorso tradizionale.
Analisi. Runtime async rende meno costosa una buona decomposizione del codice. In passato, in hot path estremi, si poteva essere tentati di fondere helper async per ridurre state machine e allocazioni. Se il runtime può riconoscere e ottimizzare la catena, la leggibilità del sorgente e la qualità del codice generato smettono di essere necessariamente in conflitto.
Escape analysis: meno oggetti sul GC heap senza cambiare il sorgente
Un'altra linea di lavoro riguarda l'escape analysis. Se il JIT riesce a dimostrare che un oggetto non può sopravvivere al metodo corrente, può evitare l'allocazione sul GC heap e trattarlo in modo più efficiente. .NET 11 estende i casi riconosciuti, per esempio rendendo visibili al JIT temporanei che prima erano nascosti dietro helper runtime.
Un esempio del post riguarda il boxing temporaneo di un Nullable<T>: in uno scenario di formattazione, una precedente allocazione heap da 24 byte viene completamente eliminata. Anche qui il numero non va generalizzato al proprio workload; ciò che conta è il pattern: più informazione il JIT riesce a recuperare, più ottimizzazioni diventano possibili senza introdurre API specialistiche nel codice applicativo.
PGO, devirtualizzazione e loop: il runtime osserva il programma reale
Il JIT continua inoltre a sfruttare tiered compilation e Profile-Guided Optimization. Il Tier 0 può raccogliere informazioni sui rami realmente percorsi e sui tipi concreti che arrivano ai call site virtuali; una successiva compilazione Tier 1 usa quei dati per specializzare il codice. La guarded devirtualization può trasformare un dispatch virtuale o di interfaccia nel percorso veloce verso un tipo probabile, lasciando un fallback corretto per gli altri casi.
.NET 11 estende anche loop cloning e range analysis. In un loop su array o Span<T>, se il JIT riesce a provare una relazione fra indice e lunghezza, può pagare un controllo una sola volta e utilizzare un percorso clonato senza bounds check a ogni iterazione.
guard once
|
+--> fast loop: no per-iteration bounds check
|
+--> safe fallback: normal checked loopÈ un esempio classico di ottimizzazione che difficilmente conviene replicare manualmente: il runtime può mantenerla insieme alle garanzie di sicurezza del linguaggio.
GC e write barrier: la performance non è solo “quante allocazioni faccio”
.NET 11 migliora anche il confine tra codice generato e garbage collector. Microsoft descrive ottimizzazioni alle GC write barrier e ai controlli di covarianza degli array: quando il JIT conosce con precisione il tipo della destinazione, può esporre e semplificare operazioni che in precedenza rimanevano nascoste dietro helper runtime.
Un altro cambiamento riguarda i ConditionalWeakTable e i dependent handle. I metadata dei handle ora possono “invecchiare” insieme agli oggetti a cui sono associati, permettendo alle collection giovani di evitare scansioni inutili di stato ormai long-lived. I microbenchmark pubblicati mostrano differenze molto grandi in scenari costruiti con centinaia di migliaia o milioni di handle, ma il dato realmente importante è l'effetto sistemico: ridurre il lavoro ripetuto durante le collection ephemeral riduce il costo pagato dall'intero processo.
Startup, Native AOT e una convergenza importante per MAUI
Sul fronte startup, .NET 11 riduce allocazioni e lavoro durante la costruzione della Trusted Platform Assembly list, sposta parte dei metadata di EventSource a build time e migliora alcuni percorsi ReadyToRun. Per Native AOT su Windows viene ridotto anche uno spreco di virtual memory nei piccoli blocchi di metadata runtime.
Un cambiamento particolarmente significativo è la convergenza mobile: a partire da .NET 11, Android, iOS e Mac Catalyst in .NET MAUI passano a CoreCLR, completando il superamento del runtime Mono per queste piattaforme. Questo porta la stessa base runtime usata da server e desktop, con JIT, GC, diagnostics, ReadyToRun e PGO dove applicabili, e una base comune per Native AOT.
Valutazione. Il tema di .NET 11 non è “un'altra release con qualche percentuale in più”. È la progressiva trasformazione del runtime in un ottimizzatore più informato: osserva i tipi reali, le hot path, la lifetime degli oggetti, le relazioni fra indici, le catene async e sempre più spesso elimina costi che il sorgente non dovrebbe essere costretto a conoscere.
ArcGIS embeddings: dalla distanza geografica alla distanza semantica
ArcGIS Pro tratta ormai gli embedding come una struttura dati utilizzabile direttamente nei workflow GIS. La documentazione ufficiale descrive un embedding come un vettore numerico ad alta dimensionalità in cui elementi semanticamente simili sono vicini nello spazio vettoriale. Gli embedding possono supportare similarity search, clustering, change detection e analisi su larga scala. Fonti: Embeddings in ArcGIS Pro e Including Embeddings in Your Spatial Analysis Workflows.
Un dettaglio implementativo è importante: ArcGIS riconosce come embedding dataset una feature class con un campo Embedding di tipo Blob. La documentazione indica supporto per file geodatabase, enterprise geodatabase con feature class registrate e mobile geodatabase; shapefile e GeoPackage non sono formati supportati per memorizzare questi embedding dataset.
Una volta calcolato il vettore, molte operazioni non richiedono più di rieseguire il foundation model. Il confronto può diventare un'operazione relativamente leggera sui vettori precomputati, per esempio attraverso cosine similarity. È questa separazione tra costo di representation learning e costo di retrieval che rende gli embedding interessanti anche come building block architetturale.
Non confondiamo due tipi di prossimità
Nel GIS tradizionale, “vicino” significa quasi sempre una relazione nello spazio geografico: distanza euclidea o geodetica, rete stradale, topologia, contiguità. Con gli embedding compare un secondo spazio:
Geographic space Embedding space
--------------- ---------------
meters / degrees cosine / vector distance
near on the map similar in meaning/context
far on the map semantically similar
near on the map semantically differentDue quartieri a centinaia di chilometri di distanza possono risultare molto vicini nello spazio degli embedding perché condividono struttura demografica, economica o ambientale. Al contrario, due poligoni adiacenti possono avere firme semantiche molto differenti.
Esri sottolinea anche un aspetto che nei progetti reali diventa subito critico: la scala dell'embedding deve essere coerente con la scala dell'analisi. Aggregare embedding H3 più fini verso poligoni più grandi tramite media, mediana o altre statistiche è possibile, ma Esri lo descrive come un'area ancora aperta di ricerca perché l'aggregazione può diluire informazione significativa. Usare embedding a scala più grossolana su osservazioni molto fini può invece introdurre valori ripetuti e problemi assimilabili all'ecological fallacy.
Spatial-semantic retrieval: un pattern che vale la pena formalizzare
Analisi. Da qui emerge un pattern che chiamerei spatial-semantic retrieval. Non è necessario trasformare ogni problema GIS in una ricerca puramente vettoriale. In molti casi conviene separare i due segnali.
Query location / feature
|
v
Spatial filter
(buffer / intersects / network / extent)
|
v
Candidate set
|
v
Embedding similarity
(cosine / nearest neighbors)
|
v
Semantic ranking
|
v
GIS resultOppure si può invertire l'ordine: partire dai nearest neighbor semantici e successivamente applicare vincoli geografici.
Questa separazione evita un errore concettuale importante. Nel post sulle best practice Esri sconsiglia di mescolare direttamente embedding e variabili tradizionali dentro la stessa metrica di similarità. Se vogliamo combinare distanza geografica e similarità semantica, è più pulito calcolare i due segnali separatamente e fonderli a valle, con una strategia di late fusion validata sul caso d'uso.
Per esempio, una funzione di ranking custom potrebbe essere:
score = alpha * semanticScore
+ (1 - alpha) * spatialScoreAttenzione: questa formula è una proposta architetturale, non una funzione ArcGIS documentata. semanticScore e spatialScore devono essere normalizzati e calibrati; alpha non va scelto “a sensazione” ma su un dataset di validazione coerente con il problema.
Dal pixel al LiDAR: cross-modal geospatial inference
Il 2 ottobre Esri ha pubblicato un caso ancora più interessante: Classify Point Clouds Using Embedding Based Image Analysis. Il workflow parte da imagery e point cloud sovrapposte. Se un oggetto è visivamente riconoscibile nell'immagine ma difficile da separare usando soltanto geometria, quota o return information della point cloud, la semantica può essere estratta dall'immagine e poi trasferita al LiDAR.
Nel caso dimostrato da Esri il target sono i binari ferroviari del Dangermond Preserve. Il flusso è:
True orthophoto
|
v
Generate imagery embeddings
|
v
Select a few clean rail examples
|
v
Find Similar in embedding space
|
v
Semantic mask / feature
|
v
Review + optional dissolve
|
v
Set LAS Class Codes Using Features
|
v
Rail class in point cloudEsri suggerisce questo approccio soprattutto per elementi con pattern visivo netto come rail line, strade, pannelli solari o specifici tipi di copertura. Nel workflow pubblicato, il risultato vettoriale ottenuto dall'analisi degli embedding viene usato da Set LAS Class Codes Using Features per assegnare alla point cloud la classe ASPRS 10 per il rail.
Analisi. Questo è più interessante di una semplice “classificazione AI”. Il modello non deve necessariamente essere ottimizzato per la modalità finale. Possiamo estrarre semantica dalla modalità dove il segnale è più leggibile — l'immagine — e trasferire il risultato verso la rappresentazione 3D.
semantics from imagery
+
spatial registration
=
knowledge transferred to 3D geometryÈ un esempio concreto di cross-modal geospatial inference.
Il lato delicato è l'incertezza. Una pipeline del genere non eredita soltanto l'errore del modello: accumula errore di classificazione, soglia di similarità, georeferenziazione, differenze di risoluzione e soprattutto eventuale disallineamento temporale tra imagery e LiDAR. Esri raccomanda infatti particolare attenzione quando i due dataset non sono acquisiti nello stesso periodo e insiste sulla verifica visuale del risultato.
Experience Builder Agent Skill: quando la documentazione diventa comportamento dell'agente
Il 14 settembre Esri ha pubblicato un Agent Skill per lo sviluppo di custom widget ArcGIS Experience Builder. Il contenuto è open source nel repository arcgis-experience-builder-sdk-resources, cartella skills/arcgis-exb-widget-dev.
Il punto tecnico non è “ora l'AI scrive i widget”. Quello era già possibile. Il punto è che Esri sta trasformando parte della propria conoscenza procedurale in un artefatto direttamente consumabile dagli agenti.
Lo skill copre, tra le altre cose, struttura dei file, manifest.json, config.json, separazione runtime/settings, data source, map e layer view, message/data actions, theming, state, ArcGIS web components, accessibilità e convenzioni del framework. La documentazione ufficiale di Experience Builder conferma che i custom widget sono componenti React/TypeScript integrati tramite il framework Jimu e che lavorano con data source, Map widget, JimuMapViewComponent, message e data actions. Riferimento: Getting started with widget development.
Skill non significa fine-tuning
Analisi. Uno skill di questo tipo è più vicino a una procedural knowledge package che a un modello specializzato. Non cambia i pesi del modello. Cambia il contesto operativo con cui l'agente decide come procedere.
General coding model
|
+--> generic TypeScript / React knowledge
|
+--> Esri Agent Skill
|
+--> ExB conventions
+--> file anatomy
+--> framework APIs
+--> references
+--> skeletons
Il vantaggio è importante: invece di sperare che il modello ricostruisca la convenzione corretta da memoria, search o esempi casuali, gli forniamo un pacchetto progettato per quel dominio.
La parte che manca a un vendor skill: il contratto del repository
Un vendor skill può sapere come funziona Experience Builder. Non può conoscere automaticamente le decisioni architetturali di una specifica codebase: versioni supportate, convenzioni di naming, pattern di comunicazione fra widget, servizi autorizzati, policy di logging, regole di packaging, test obbligatori, compatibilità con release Enterprise precedenti.
Per un progetto reale vedo quindi tre livelli distinti:
1. Vendor Skill
"How Experience Builder works"
2. Repository Skill
"How THIS project is engineered"
3. CI / tests / linters
"What is actually allowed to ship"
Valutazione. Questa stratificazione è molto più robusta del semplice prompt engineering. Il prompt descrive il task; lo skill descrive il dominio; il repository skill descrive le decisioni locali; la CI rende alcune regole eseguibili. È un percorso verso una forma di architecture-as-context.
Il limite resta fondamentale: un agente può produrre codice sintatticamente valido ma architetturalmente sbagliato. Per esempio, un widget che usa l'API corretta può comunque gestire male ownership dello stato, lifecycle della map view, concorrenza fra strumenti interattivi o compatibilità con un'altra estensione. Lo skill riduce il problema del “non conosco il framework”; non elimina il problema del “non conosco il sistema”.
GPT-6.1 Sol e Multi-Agent: l'orchestrazione entra nella request
Il 29 settembre OpenAI ha aggiunto GPT-6.1 Sol e la modalità Multi-agent in beta alla Responses API. Nello stesso giorno è arrivato anche computer use nell'Agents API con browser ospitato da OpenAI. Le fonti primarie sono il changelog ufficiale, la documentazione Multi-agent, la pagina del modello GPT-6.1 Sol e la guida Computer use.
Per GPT-6.1 Sol la documentazione corrente indica una context window da 1.050.000 token, output massimo di 128.000 token e, nel tier Standard per prompt fino a 272K token di input, prezzi per milione di token di 2 dollari input, 0,10 dollari cached input, 2,50 dollari cache write e 10 dollari output. I prezzi e i limiti sono dati operativi e vanno sempre verificati di nuovo prima di prendere decisioni di capacità o budget.
Il vero cambiamento non è il modello: è il grafo di esecuzione
Con Multi-agent un root agent può creare subagent con contesti separati, inviare loro task, attendere risultati e sintetizzare la risposta finale. La documentazione indica come casi adatti codebase exploration, confronto di documenti o ipotesi, ricerca parallela e implementazione di componenti indipendenti.
/root
|
+----------+----------+
| | |
v v v
/researcher /reviewer /tester
| | |
+----------+----------+
|
v
synthesisOpenAI documenta sei primitive di collaborazione ospitate: creazione di subagent, messaging, follow-up, attesa, interrupt e listing dell'albero. Non c'è un limite fisso documentato al numero totale di subagent o alla profondità dell'albero; il controllo operativo è la concorrenza, con valore predefinito di tre subagent attivi contemporaneamente nella modalità Responses Multi-agent.
La documentazione è anche esplicita su quando non usare Multi-agent: catene strettamente sequenziali, task piccoli, workload dominati da una singola operazione esterna lenta, necessità di un execution graph deterministico o agenti che competono sulla stessa risorsa mutabile.
Una Amdahl's Law per gli agenti
Analisi. Aggiungere agenti non moltiplica automaticamente l'intelligenza né divide linearmente il tempo. Una stima concettuale può essere:
Ttotal ~= Torchestration
+ max(Tsubagents)
+ Ttools
+ Tmerge
+ TreconciliationLa parte parallelizzabile beneficia dei subagent. Tutto ciò che resta seriale — pianificazione, condivisione di contesto, merge, validazione, side effect — continua a porre un limite superiore al guadagno.
Il costo segue una logica ancora più evidente:
Ctotal ~= Croot
+ SUM(Csubagent)
+ Ctools
+ Cretries
+ CescalationsOpenAI stessa avverte che i subagent possono aumentare l'uso di token. Per questo la metrica utile non è il prezzo per milione di token ma il cost-per-successful-task, idealmente insieme a latency percentile, tool failure rate, numero di retry e percentuale di escalation verso un modello più costoso.
Security boundary: tutti i subagent vedono gli stessi tool
Un dettaglio della documentazione Multi-agent merita attenzione: tutti gli agenti dell'albero hanno accesso ai tool configurati nella request. Questo semplifica l'orchestrazione ma ha una conseguenza di sicurezza.
Analisi. Se la policy richiede least privilege diverso per ruolo — per esempio un subagent può leggere dati ma non modificarli — un unico albero Multi-agent con lo stesso tool set non costituisce da solo quella separazione. Il controllo va spostato nel tool proxy, nel layer di authorization oppure in orchestrazioni separate con capability differenti.
Bad assumption:
subagent role == security boundary
Safer design:
agent intent
|
v
authorization / policy
|
v
tool capability
|
v
side effectLa stessa cautela vale per computer use. Nell'Agents API il browser OpenAI-hosted richiede approvazione per accedere a nuove origin e l'applicazione gestisce i passaggi di autenticazione. La documentazione specifica però che l'approvazione di un origin non equivale alla conferma di ogni singola azione. Se un'operazione consequenziale deve richiedere approvazione — acquisto, modifica o cancellazione — il sistema deve introdurre una barriera specifica oppure usare un ambiente dove tali azioni non siano possibili senza un ulteriore controllo.
Il trend: runtime, representation e orchestration stanno convergendo
È interessante mettere insieme i quattro temi.
.NET 11
source decomposition
-> runtime/JIT optimization
ArcGIS embeddings
raw spatial data
-> learned representation
Experience Builder Skills
framework documentation
-> agent procedural context
Multi-Agent
single model call
-> dynamic execution graphVISIONE. Il salto architetturale dei prossimi anni potrebbe non derivare solo da linguaggi o modelli più potenti. Potrebbe derivare dal fatto che sistemi di esecuzione, framework e toolchain iniziano a conservare intenzione e semantica più a lungo.
Il compilatore non distrugge subito tutta la semantica di async: una parte arriva al runtime. Il GIS non riduce il luogo a un insieme di colonne: conserva una rappresentazione appresa del contesto. La documentazione non resta soltanto testo per umani: diventa un artefatto operativo per il coding agent. Il modello non restituisce soltanto testo: costruisce un grafo di subtask e tool call.
Quando più informazione sopravvive fino al layer che prende decisioni, quel layer può ottimizzare meglio. Ma cresce anche la responsabilità di definire confini, authorization, observability e validazione.
Technical Takeaways
- .NET 11 Runtime Async: il passaggio del lowering verso runtime/JIT apre ottimizzazioni che il compilatore C# non poteva fare attraverso più confini async. È opt-in e va misurato, non attivato per fede.
- JIT e GC: escape analysis, guarded devirtualization, PGO, loop analysis e write-barrier optimization mostrano che molta performance futura dipenderà da quanto il runtime riesce a dedurre, non da micro-ottimizzazioni manuali nel sorgente.
- Embeddings GIS: distanza geografica e distanza semantica sono segnali diversi. I workflow più interessanti probabilmente li useranno insieme, ma senza confonderli nello stesso spazio matematico.
- Cross-modal GeoAI: imagery -> semantic mask -> point cloud classification dimostra che il modello può operare nella modalità con segnale migliore e trasferire il risultato verso un'altra rappresentazione geospaziale.
- Agent Skills: il valore non è generare boilerplate; è rendere esplicita la conoscenza procedurale del framework. Il passo successivo è affiancare al vendor skill un repository skill e controlli CI eseguibili.
- Multi-Agent: parallelizzare subtask indipendenti può ridurre il wall-clock time, ma aumenta token, coordinamento e failure mode. Misurare cost-per-successful-task, non soltanto cost-per-token.
- Security: un subagent non è automaticamente un security principal. La capacità reale è determinata dai tool e dalle authorization policy che proteggono i side effect.
Lab della settimana
Lab 1 — Runtime async: misurare prima di credere
Creare un piccolo servizio o benchmark con una catena di 5-10 helper async che alternano completion sincrona e reale sospensione I/O. Compilarlo in tre configurazioni: .NET 10, .NET 11 con lowering classico, .NET 11 con runtime-async=on.
Misurare almeno:
- mean e p95/p99 latency;
- allocated bytes/op con BenchmarkDotNet;
- dimensione assembly;
- GC collections;
- profilo async.
Riferimenti: Performance Improvements in .NET 11 e .NET 11 RC1.
Lab 2 — Spatial vs semantic proximity
Prendere un embedding dataset ArcGIS e scegliere una feature di riferimento. Costruire tre ranking:
- solo distanza geografica;
- solo similarity in embedding space;
- spatial candidate filter + semantic ranking.
Confrontare la top-10 e osservare quali feature sono geograficamente vicine ma semanticamente lontane e quali sono lontane sulla mappa ma vicine nello spazio degli embedding. Ripetere a due scale diverse per verificare l'effetto della risoluzione.
Riferimenti: Embeddings in ArcGIS Pro e best practice Esri sugli embedding.
Lab 3 — Agent Skill A/B test su Experience Builder
Dare lo stesso task a un coding agent in tre condizioni:
- senza skill;
- con
arcgis-exb-widget-devdi Esri; - con skill Esri + un piccolo repository skill locale che descriva convenzioni, versioni supportate e criteri di accettazione.
Non valutare il risultato a occhio. Registrare:
- build riuscita al primo tentativo;
- uso corretto delle API Experience Builder;
- numero di correzioni manuali;
- warning TypeScript/ESLint;
- compatibilità con widget e map interaction già presenti;
- token e tool call;
- tempo fino a un test end-to-end superato.
Riferimenti: Esri Agent Skill, SDK resources repository e Experience Builder widget development.
Fonti primarie
- Microsoft .NET Blog — Performance Improvements in .NET 11, 15 settembre 2026.
- Microsoft .NET Blog — Announcing .NET 11 Release Candidate 1, 8 settembre 2026.
- ArcGIS Pro Documentation — Embeddings in ArcGIS Pro.
- ArcGIS Blog — Including Embeddings in Your Spatial Analysis Workflows, 16 settembre 2026.
- ArcGIS Blog — Classify Point Clouds Using Embedding Based Image Analysis, 2 ottobre 2026.
- ArcGIS Blog — Building Custom Experience Builder Widgets with an Agent Skill, 14 settembre 2026.
- Esri GitHub — arcgis-experience-builder-sdk-resources.
- Esri Developer — Getting started with widget development.
- OpenAI API — Changelog, verificato il 5 ottobre 2026.
- OpenAI API — GPT-6.1 Sol, verificato il 5 ottobre 2026.
- OpenAI API — Multi-agent, verificato il 5 ottobre 2026.
- OpenAI API — Computer use, verificato il 5 ottobre 2026.
Nessun commento:
Posta un commento