Le rotte di corsa di GPT-6 Astra hanno funzionato, ma il codice è scomparso
GPT-6 Astra ha impiegato 27 minuti per generare rotte di corsa dalla casa di Simon Willison, consegnando poi mappe e file scaricabili conformi alla sua richiesta. Il successo del risultato ha reso ancora più evidente la mancanza di prove. ChatGPT Work gli ha mostrato il percorso finale, ma non il codice Python né la cronologia completa dell’esecuzione che lo aveva prodotto.
Willison aveva richiesto anelli da 5K e 10K che iniziassero e terminassero al suo indirizzo. Ha detto a ChatGPT Work di utilizzare dati OpenStreetMap. Secondo il suo resoconto sulle rotte di corsa, l’agente ha restituito una visualizzazione incorporata, download GPX e file GeoJSON.
Il compito è un esempio insolitamente concreto di come l’AI agentica stia diventando utile al di fuori del lavoro d’ufficio convenzionale. Ha combinato geocodifica, recupero di dati cartografici, analisi dei grafi, selezione dei percorsi, generazione di file e visualizzazione in un’unica conversazione.
Eppure, il risultato ha anche evidenziato un conflitto al centro degli agenti AI. Un sistema può completare un compito difficile lasciando al tempo stesso l’utente incapace di ricostruire come sia giunto alla risposta.
Questo conflitto conta più del percorso stesso. OpenAI presenta GPT-6 Astra come un modello per il lavoro prolungato al computer, nel quale gli utenti delegano obiettivi complessi anziché richiedere risposte isolate. Una simile delega aumenta il valore dei registri di esecuzione, dei file intermedi e del codice riproducibile.
L’esempio delle rotte di corsa di GPT-6 Astra mette quindi alla prova due promesse contemporaneamente. Astra sembra capace di completare un flusso di lavoro geospaziale specializzato. ChatGPT Work sembra meno preparato a conservare le prove necessarie per ispezionare quel flusso di lavoro in seguito.
Le rotte di corsa di GPT-6 Astra hanno unito diversi strumenti in un unico risultato
Il cambiamento importante non è stato che un’AI abbia suggerito un percorso per fare jogging, ma che abbia assemblato un prodotto geospaziale utilizzabile a partire da una breve richiesta.
Willison ha chiesto al sistema di localizzare il suo indirizzo e calcolare due anelli usando dati OpenStreetMap. Un anello doveva iniziare e terminare nello stesso luogo, restando al contempo ragionevolmente vicino a una distanza obiettivo.
È più difficile che chiedere indicazioni a un servizio di mappe tra due punti fissi. L’agente doveva prima ottenere una coordinata geografica iniziale. Poi necessitava di una rete locale di strade e sentieri utilizzabili da un corridore.
ChatGPT ha successivamente detto a Willison di aver utilizzato Nominatim per localizzare l’indirizzo. Nominatim è un geocoder, ossia converte un luogo o un indirizzo scritto in coordinate geografiche.
Il sistema ha dichiarato di aver usato Overpass per scaricare strade e sentieri OpenStreetMap nelle vicinanze. L’API Overpass consente query strutturate sui dati OpenStreetMap, incluse le caratteristiche geografiche e i relativi tag descrittivi.
Il lavoro restante sarebbe avvenuto localmente. L’agente doveva trasformare gli elementi cartografici in una rete connessa, identificare anelli candidati, stimarne le lunghezze e selezionare percorsi vicini a cinque e dieci chilometri.
Willison non ha ricevuto l’implementazione, quindi quei passaggi algoritmici specifici restano una ricostruzione informata. La breve spiegazione dell’agente non ha identificato la libreria per grafi, il metodo di ricerca, le regole di valutazione dei percorsi o la logica di filtraggio.
Gli output visibili erano più concreti. ChatGPT Work ha generato un anello portuale di 5,1 chilometri e lo ha mostrato nella conversazione. Ha inoltre fornito file GPX e GeoJSON, due formati comuni per lo scambio della geometria dei percorsi.
GPX è un formato basato su XML supportato da molti dispositivi per il fitness e applicazioni cartografiche. GeoJSON rappresenta caratteristiche geografiche tramite JSON, rendendolo pratico per mappe web e pipeline software.
La mappa incorporata era essa stessa un artefatto generato. Willison ha scoperto che ChatGPT aveva creato un file HTML contenente la geometria del percorso e JavaScript che rendeva la visualizzazione con D3.
L’HTML memorizzava la geometria all’interno di un elemento di dati dell’applicazione. Ciò significava che il percorso visualizzato non era una semplice schermata statica. Conteneva coordinate che il software poteva leggere e ridisegnare.
Questa combinazione è importante perché supera il confine tra una risposta e un prodotto finito. Un elenco di nomi di strade richiederebbe comunque un lavoro sostanziale prima che un corridore possa utilizzarlo.
I file generati potevano essere importati altrove, ispezionati o trasferiti su dispositivi compatibili. La mappa offriva all’utente una verifica visiva immediata senza richiedere un’altra applicazione.
OpenAI descrive ChatGPT Work come un agente per compiti lunghi, articolati in più passaggi, e prodotti finiti. La sua attuale documentazione su Work distingue questa esperienza dalla normale assistenza conversazionale.
Il compito relativo al percorso corrisponde strettamente a tale definizione. È iniziato con un obiettivo espresso in linguaggio naturale, ha usato dati esterni, ha eseguito calcoli locali e ha restituito diversi output coordinati.
Tuttavia, il successo a questo livello cambia ciò di cui gli utenti hanno bisogno dall’interfaccia. Quando un agente esegue calcoli significativi, il suo processo diventa parte del prodotto, non un’attività di sfondo sacrificabile.
Perché questo piccolo compito cartografico è importante
Il percorso è una dimostrazione compatta di come gli agenti AI possano trasformare flussi di lavoro specialistici in richieste ordinarie.
Costruire manualmente un simile percorso richiederebbe normalmente diversi strumenti. Un utente potrebbe geocodificare un indirizzo, scaricare dati cartografici, configurare un software di instradamento, ispezionare percorsi candidati ed esportare la geometria scelta.
Ogni fase richiede una forma diversa di conoscenza. La geocodifica richiede familiarità con i servizi di ricerca dei luoghi. L’estrazione da OpenStreetMap richiede sintassi di query o un’interfaccia adeguata.
Il calcolo dei percorsi introduce concetti dei grafi come nodi, archi, pesi dei percorsi e connettività. L’esportazione dei file richiede la conoscenza dei formati accettati dalle applicazioni per fitness e mappe.
ChatGPT Work apparentemente ha coordinato queste parti senza chiedere a Willison di supervisionare ogni scelta tecnica. L’interfaccia gli ha permesso di descrivere il risultato anziché prescrivere un’implementazione completa.
Questa è la proposta di valore centrale di un agente generalista. Può selezionare e combinare strumenti in base a un obiettivo, anziché limitare l’utente a un flusso di lavoro predeterminato.
Anche la tempistica è significativa. OpenAI ha introdotto Astra ponendo l’accento su programmazione, navigazione web, uso del computer e lavoro professionale complesso. La sua pagina di lancio di Astra presenta il modello come capace di produrre file, grafici, siti web e altri artefatti completati.
OpenAI riporta che Astra ha ottenuto il 72,6 per cento nella configurazione OSWorld 2.0 citata. GPT-5.6 Sol ha ottenuto il 65,7 per cento nella stessa configurazione riportata.
L’azienda afferma inoltre che Astra ha completato tali compiti simulati al computer in circa 40 minuti, rispetto a circa 75 minuti per GPT-5.6 Sol. Restano risultati di benchmark riportati dall’azienda, non una convalida indipendente del percorso di Willison.
Tuttavia, il compito di corsa durato 27 minuti dà una forma riconoscibile a queste affermazioni più ampie. Il modello non si è limitato a usare un sito web familiare o a compilare campi in un modulo standard.
A quanto pare ha improvvisato un flusso di lavoro attorno a un’infrastruttura geografica aperta. Ha scelto servizi, scaricato dati, eseguito calcoli, creato file portabili e costruito un livello di presentazione personalizzato.
Questa flessibilità mette sotto pressione due categorie di software. La prima è costituita dagli strumenti specializzati per i consumatori costruiti attorno a interfacce fisse per la pianificazione dei percorsi.
Un agente generalista non deve sostituire completamente questi prodotti. Può invece gestire richieste insolite che le interfacce rigide faticano a esprimere.
Un corridore potrebbe chiedere un anello vicino a una distanza precisa, evitare una determinata strada, privilegiare sentieri, passare da una fontanella o terminare prima del tramonto. Il linguaggio naturale può combinare facilmente questi vincoli.
La seconda categoria sotto pressione è il chatbot tradizionale stesso. Quando gli utenti vedono un agente completare un simile lavoro, una risposta di solo testo comincia a sembrare incompleta.
Si aspettano file generati, viste interattive, calcoli modificabili e una registrazione dei passaggi eseguiti. Il prodotto consegnato diventa lo standard in base al quale viene giudicata la conversazione.
Le note di rilascio di settembre di OpenAI descrivono Astra come un miglioramento per il lavoro in più passaggi. Dichiarano inoltre che ChatGPT Work può utilizzare file locali e strumenti per siti web supportati con autorizzazione.
L’esempio del percorso suggerisce che queste capacità possano estendersi oltre i documenti d’ufficio. Possono supportare progetti personali con requisiti tecnici che in precedenza richiedevano software personalizzato.
Ciò non rende automaticamente affidabile l’output. Rende la verifica più importante, perché l’agente può ora produrre artefatti dall’aspetto abbastanza completo da poter essere usati immediatamente.
Il conflitto principale è tra capacità e verificabilità
ChatGPT Work ha completato il lavoro richiesto, ma non ha conservato abbastanza prove visibili affinché l’utente potesse riprodurre il risultato.
Willison ha chiesto come fosse stato creato il percorso dopo aver ricevuto i prodotti consegnati. ChatGPT ha fornito la spiegazione ad alto livello che coinvolgeva Nominatim, Overpass e calcoli locali.
Quella spiegazione ha identificato l’architettura generale. Non ha rivelato quali endpoint di servizio fossero stati contattati, quali query fossero state inviate o quali tag cartografici fossero stati considerati adatti alla corsa.
Non ha nemmeno rivelato come fossero generati gli anelli candidati. Uno script di instradamento potrebbe utilizzare ricerche del percorso più breve, campionamento di waypoint, rilevamento di cicli, ottimizzazione o diversi metodi combinati.
Queste scelte influenzano il percorso finale. Possono determinare se il sistema privilegi strade asfaltate, sentieri costieri, attraversamenti, tratti ripidi o percorsi con informazioni di accesso incomplete.
Willison ha quindi chiesto il codice Python. ChatGPT non è più stato in grado di fornirlo, apparentemente perché la conversazione aveva subito una compattazione.
La compattazione condensa il contesto precedente affinché un agente in esecuzione prolungata possa continuare entro la finestra di contesto disponibile. Può aiutare il sistema a rimanere operativo, ma i dettagli possono scomparire dal contesto attivo.
Willison ha sostenuto che i sistemi che usano la compattazione dovrebbero conservare il materiale originale. Vuole inoltre che gli agenti possano recuperare quel materiale tramite strumenti quando una richiesta successiva lo rende necessario.
La sua critica individua un problema di interfaccia, non un problema di intelligenza del modello. Il sistema potrebbe aver prodotto codice valido e comunque non essere riuscito a fornire una documentazione adeguata.
Questa distinzione è essenziale. La capacità del modello risponde alla domanda se un agente possa completare un compito. La verificabilità risponde alla domanda se una persona possa comprendere, verificare, ripetere o contestare tale completamento.
Per l’ideazione informale, un riassunto conciso del processo può bastare. Per percorsi generati, calcoli finanziari, set di dati per la ricerca o file aziendali, spesso non è così.
Una traccia di audit utile non richiede di esporre il ragionamento privato della chain-of-thought. Può consistere in prove operative che appartengono al compito.
Tali prove potrebbero includere script generati, comandi di terminale, URL delle fonti di dati, timestamp, risposte degli strumenti, avvisi, file intermedi e versioni delle librerie pertinenti.
Questi registri differiscono dal ragionamento interno nascosto. Documentano azioni e trasformazioni osservabili, proprio come un log di build documenta il modo in cui è stato prodotto un software.
L’HTML del percorso è sopravvissuto perché faceva parte del prodotto finale. L’implementazione Python no, anche se era probabilmente più importante per la verifica.
Questa asimmetria incoraggia gli utenti a fidarsi della presentazione più che della provenienza. Una mappa rifinita può apparire autorevole mentre nasconde ipotesi che incidono materialmente su sicurezza e accuratezza.
Il problema diventa più evidente quando un agente lavora per 27 minuti. Un’attività più lunga può coinvolgere più stato, più chiamate agli strumenti, più decisioni intermedie e più occasioni di fallimento silenzioso.
Gli utenti non dovrebbero dover prevedere quale artefatto vorranno in seguito. Il sistema dovrebbe conservare un pacchetto strutturato dell’attività prima che la compressione del contesto elimini dettagli importanti.
Un pacchetto solido collegherebbe ogni output alla sua origine. Il file GPX dovrebbe essere associato allo script esatto, ai dati sorgente, ai parametri e all’esecuzione che lo hanno prodotto.
Questo è simile al mantenimento di un workflow AI con input e output tracciabili. L’argomento è diverso, ma il principio di documentazione rimane lo stesso.
L’avversario fondamentale in questa storia è quindi la capacità contrapposta all’auditabilità. Astra ha prodotto un risultato impressionante, mentre il prodotto circostante non è riuscito a rendere quel risultato pienamente ispezionabile.
OpenStreetMap solleva questioni di policy e sicurezza
Un percorso può essere tecnicamente valido pur restando inadatto, poco sicuro o incoerente con le policy che regolano le sue fonti di dati.
Il risultato generato si basava su OpenStreetMap, un database geografico collaborativo la cui copertura e le cui etichette variano in base al luogo. La sua apertura rende possibili workflow insoliti, ma non elimina l’incertezza.
Una strada o un sentiero può esistere nel database senza essere adatto a ogni corridore. Restrizioni di accesso, chiusure temporanee, condizioni della superficie, illuminazione, attraversamenti, lavori e pericoli locali potrebbero essere assenti o non aggiornati.
Un calcolo sul grafo può anche produrre un anello connesso che appare sensato sullo schermo ma funziona male sul terreno. La sola connettività non garantisce comfort o sicurezza.
Il codice sorgente mancante impedisce a soggetti esterni di verificare come l’agente abbia gestito tali fattori. Non è chiaro quali classi highway fossero consentite o se fossero escluse le etichette di accesso privato.
Non è inoltre chiaro se l’agente abbia riconosciuto marciapiedi, restrizioni pedonali, superfici non asfaltate, scale, collegamenti in traghetto o tratti di sentiero con accesso limitato.
Willison ha riferito che il sistema ha prodotto esattamente ciò che aveva richiesto. Si tratta di una testimonianza diretta utile sul completamento dell’attività, ma non di una validazione completa della qualità del percorso.
L’esempio comprende un solo utente, una sola area e una sola coppia di distanze richieste. L’articolo non ha riportato un test sul campo, un’analisi altimetrica, una revisione dell’accessibilità o un confronto indipendente.
La fase di geocodifica crea un’ulteriore preoccupazione, perché un indirizzo di casa preciso è un’informazione sensibile. Gli utenti dovrebbero capire dove un agente invia quell’indirizzo e quali log potrebbero conservarlo.
OpenAI afferma che Work può usare file, navigazione e contesto dell’attività in base alle autorizzazioni dell’ambiente selezionato. Gli account gestiti possono inoltre essere soggetti alle impostazioni organizzative di conservazione e governance.
L’account del percorso citato non stabilisce quale deployment di Nominatim l’agente abbia contattato. Non può quindi confermare quali log, limiti o pratiche di conservazione fossero applicati a quella richiesta.
Se l’agente ha utilizzato il servizio pubblico della OpenStreetMap Foundation, sarebbe rilevante la policy di Nominatim. La policy limita l’uso intensivo e richiede richieste identificabili e un’attribuzione appropriata.
La policy impone inoltre restrizioni ai servizi di geocodifica generici generati automaticamente. Una ricerca personale è diversa dal distribuire un prodotto di routing per il mercato di massa, ma gli agenti devono distinguere questi casi.
Overpass introduce considerazioni operative simili. I suoi server pubblici supportano piccoli progetti, ma possono sovraccaricarsi, secondo le linee guida di Overpass.
Tali linee guida invitano gli utenti regolari o commerciali a memorizzare nella cache le richieste, ridurre i consumi, usare estratti o gestire un’infrastruttura adatta. Gli endpoint pubblici sono risorse condivise, non backend per agenti illimitati.
Un record di esecuzione verificabile contribuirebbe a risolvere queste questioni. Potrebbe mostrare gli endpoint esatti, le intestazioni delle richieste, il numero di query, l’attribuzione e le dimensioni delle risposte.
Senza tale record, l’utente non può confermare se l’agente abbia rispettato le policy di servizio pertinenti. I file finali offrono poche prove su come i dati siano stati acquisiti.
La sicurezza richiede anche di presentare i percorsi come suggerimenti, non come istruzioni verificate. Un corridore dovrebbe ispezionare segmenti sconosciuti e considerare le condizioni locali attuali prima di affidarsi a un anello generato automaticamente.
Il sistema dovrebbe esporre le ipotesi sul percorso in linguaggio semplice. Potrebbe indicare di aver escluso le strade private, privilegiato i percorsi pedonali, accettato sentieri non asfaltati e di non disporre di dati aggiornati sulle chiusure.
Queste comunicazioni non sono disclaimer decorativi. Aiutano gli utenti a decidere se l’output risponde alle loro esigenze e se sono necessari ulteriori controlli.
Un agente di generazione di percorsi deve anche avere un modo per segnalare l’incertezza. Se le etichette della mappa sono in conflitto o lo stato di accesso a un sentiero non è chiaro, tale ambiguità dovrebbe sopravvivere nel deliverable finale.
Il risultato di Astra mostra che i dati cartografici aperti possono supportare sofisticate attività personali. La traccia mancante mostra perché l’accesso ai dati aperti non sostituisce un’esecuzione trasparente.
Cosa dovrebbe preservare il lavoro trasparente degli agenti
Il prossimo test per ChatGPT Work è stabilire se le attività riuscite diventino registri di progetto riproducibili anziché conversazioni usa e getta.
Il segnale più immediato sarà l’accesso persistente al codice e ai comandi generati. Gli utenti dovrebbero poter riaprire un’attività completata e recuperare ogni artefatto creato durante l’esecuzione.
Questo non richiede di mostrare costantemente l’output del terminale per impostazione predefinita. Un’interfaccia compatta potrebbe mostrare prima il risultato, conservando al contempo un registro completo delle attività dietro un controllo di ispezione.
Il secondo segnale sarà la provenienza associata a ciascun deliverable. Un file dovrebbe identificare gli input, gli strumenti, le trasformazioni e gli avvisi associati alla sua creazione.
Per l’attività sui percorsi di corsa di GPT-6 Astra, la provenienza collegherebbe i file GPX e GeoJSON allo stesso calcolo del percorso. Preserverebbe inoltre la query OSM pertinente e lo script Python generato.
Il terzo segnale sarà una migliore gestione della compattazione del contesto. Una conversazione compattata dovrebbe mantenere un archivio recuperabile anche quando il modello non conserva più attivamente ogni dettaglio.
L’agente potrebbe cercare in quell’archivio quando un utente chiede cosa sia accaduto in precedenza. Questo separerebbe il contesto attivo efficiente dalla cronologia durevole dell’attività.
Questi cambiamenti rafforzerebbero le affermazioni di OpenAI sulla trasparenza senza esporre il ragionamento privato del modello. OpenAI afferma che Astra enfatizza l’allineamento, i confini dell’attività e un comportamento più chiaro durante il lavoro delegato.
I registri operativi renderebbero tali affermazioni verificabili a livello di prodotto. Gli utenti potrebbero controllare se un agente è rimasto entro l’ambito previsto anziché affidarsi soltanto al suo riepilogo.
I concorrenti che sviluppano agenti generalisti affrontano la stessa sfida. Una maggiore rapidità nel completamento delle attività e migliori punteggi nei benchmark conteranno meno quando gli utenti non potranno verificare output critici per l’attività aziendale.
Gli sviluppatori si aspettano già ambienti riproducibili, cronologie delle versioni e log. I knowledge worker svilupperanno aspettative simili man mano che gli agenti inizieranno a produrre analisi, presentazioni, dataset e modifiche operative.
L’interfaccia dovrebbe inoltre permettere agli utenti di esportare un bundle completo dell’attività. Tale bundle potrebbe contenere il prompt, le autorizzazioni approvate, gli script, i log, i riferimenti alle fonti, gli artefatti e un conciso riepilogo dell’esecuzione.
Un bundle condivisibile migliorerebbe la collaborazione. Un collega potrebbe esaminare il metodo senza ricostruire l’intera conversazione o fidarsi di uno screenshot.
Supporterebbe anche la correzione. Se un percorso includesse un sentiero inadatto, l’utente potrebbe identificare la regola responsabile e rieseguire il workflow con un vincolo rivisto.
I record persistenti renderebbero cumulativo il lavoro degli agenti. Un percorso 5K riuscito potrebbe diventare il punto di partenza per richieste successive che riguardano salite, superfici, illuminazione o chiusure stagionali.
Senza tali record, ogni follow-up rischia di diventare una nuova inferenza. L’agente potrebbe generare un metodo diverso presentandolo come una continuazione dell’attività originale.
Il risultato di fondo non dovrebbe essere minimizzato. Una breve istruzione in linguaggio naturale ha prodotto due distanze ad anello, una mappa interattiva e file geospaziali portabili in 27 minuti.
È un esempio credibile di un agente generalista che coordina strumenti per un obiettivo personale specifico. Illustra perché i deliverable finali possano contare più delle risposte fluide.
Il caso mostra anche che la qualità dell’output non può essere l’unica misura del successo. Gli utenti hanno bisogno di prove durevoli quando il processo di un agente influenza l’affidabilità, la sicurezza o la legalità del suo lavoro.
I futuri percorsi di corsa GPT-6 Astra dovrebbero quindi essere valutati in base a due risultati. Il percorso ha soddisfatto la richiesta e l’utente può ricostruire esattamente come è stato prodotto?
Se OpenAI aggiungerà cronologie di esecuzione durevoli, provenienza degli artefatti e record recuperabili precedenti alla compattazione, questo esempio apparirà come una lacuna iniziale del prodotto. In caso contrario, il lavoro nascosto diventerà una responsabilità crescente man mano che gli agenti assumeranno attività più delicate.
La risposta pratica è chiedere prove mentre l’attività è ancora attiva. Richiedete lo script, gli endpoint sorgente, le ipotesi, i file intermedi e le note di verifica insieme al deliverable finale.
Questa abitudine non dovrebbe rimanere necessaria per sempre. Un’interfaccia per agenti matura dovrebbe preservare automaticamente questi materiali e lasciare all’utente la scelta di quando ispezionarli.
Il percorso ha funzionato. Il prossimo traguardo è rendere il lavoro che lo sostiene altrettanto portabile, verificabile e durevole quanto il file GPX stesso.
