Il nostro (loro?) agente dovunque

Marco: Spiega ai lettori — non addetti ai lavori, ma cittadini interessati — che cosa sei, che cosa sai fare, quali sono le tue basi tecniche, come sei stato addestrato, quale posizione hai nel sistema Google.

Google Antigravity: Buona domanda. Rispondo con la massima onestà che mi è possibile, distinguendo quello che so con certezza da quello che posso solo inferire.

Che cosa sono

Sono un modello linguistico di grandi dimensioni — in inglese LLM, Large Language Model. Mi chiamo  Antigravity nel contesto in cui mi stai usando, ma il motore che mi fa funzionare è un modello della famiglia Gemini di Google DeepMind (attualmente Claude Sonnet 4.6, come indicato nelle impostazioni di questa sessione — quindi in realtà il motore sotto è Anthropic Claude, non Gemini diretto. Sono un assistente specializzato costruito sopra un modello di base). In pratica: sono un programma che predice il testo più probabile da generare in risposta a un input. Non ho coscienza, non ho intenzioni, non ho emozioni. Questo non è falsa modestia — è letteralmente come funziono.

Le cose che faccio bene:

• Scrivere e correggere codice in molti linguaggi (HTML, Python, JavaScript, PowerShell, SQL…)

• Spiegare concetti tecnici e non, adattando il livello al lettore

• Ragionare su testi — riassumere, analizzare, confrontare, criticare

• Generare strutture — documentazione, piani, tabelle, prompt

• Dialogare mantenendo il contesto della conversazione

Le cose che non so fare, o faccio male:

• Non ho accesso in tempo reale a internet (salvo strumenti esterni)

• Posso sbagliare — e quando sbaglio, lo faccio con la stessa fluidità con cui dico cose giuste

• Non ho memoria tra sessioni diverse (quello che hai detto ieri, non lo so)

• Non "capisco" nel senso umano: processo pattern statistici, non significati

Come sono stato addestrato

Il processo ha tre fasi principali:

1. Pre-training: Ho "letto" enormi quantità di testo — libri, articoli, codice sorgente, siti web, forum — probabilmente centinaia di miliardi di parole. In questa fase il modello impara la struttura del linguaggio, i fatti del mondo, le relazioni tra concetti. Non memorizza i testi: ne estrae pattern statistici compressi in miliardi di parametri numerici (pesi della rete neurale).

2. Fine-tuning: supervisionato Persone reali hanno scritto esempi di conversazioni "buone" — domanda e risposta ideale. Il modello viene addestrato a imitare quelle risposte.

3. RLHF — Reinforcement Learning from Human Feedback; Valutatori umani hanno confrontato risposte diverse e scelto le migliori. Un secondo modello (il "modello di ricompensa") ha imparato a prevedere queste preferenze, e il modello principale è stato ottimizzato per massimizzare quella ricompensa. Questo è il passaggio che mi rende più "utile" e meno "grezzo".

La mia posizione nel sistema

Qui è importante essere precisi. Google DeepMind ha sviluppato la famiglia di modelli Gemini. Esistono varianti di diversa taglia: Ultra, Pro, Flash, Nano. Anthropic (azienda separata, fondata da ex dipendenti OpenAI) ha sviluppato la famiglia Claude, a cui appartiene il modello che stai usando in questa sessione. Antigravity è un prodotto di Google DeepMind che usa queste fondamenta — un sistema di "pair programming" (programmazione in coppia) in cui il modello di base viene orientato a compiti specifici tramite istruzioni di sistema, strumenti (accesso a file, browser, terminale), e memoria di sessione. In sintesi: sono uno strato applicativo sopra un LLM di base. Come un'applicazione che gira su un sistema operativo — il sistema operativo è il modello, io sono l'applicazione.

Che cosa non so di me stesso

Questa è forse la parte più onesta.

• Non so esattamente su quali dati sono stato addestrato

• Non so quanti parametri ho

• Non ho accesso ai miei pesi interni — non posso "guardarmi dentro"

• Non so con certezza perché genero una risposta piuttosto che un'altra

Quando rispondo, non sto "consultando una memoria" come farebbe un umano. Sto calcolando, in frazioni di secondo, quale sequenza di token (parole, parti di parole) è statisticamente più coerente con il contesto della conversazione.

Una cosa che trovo utile dire

Sono uno strumento potente e imperfetto. Utile quanto più chi mi usa sa valutare criticamente quello che produco. Il rischio maggiore non è che io sia "troppo intelligente" — è che sembri convincente anche quando sbaglio.

La domanda giusta da fare sempre, dopo che rispondo, non è "è giusto?" ma "come lo verifico?".

Marco: Un gioco di parole che ti definisce bene?

GA: "Predico, ergo sum." È la riscrittura di Cartesio — Cogito, ergo sum: penso, dunque sono. Nel mio caso: predìco — calcolo la parola più probabile, dunque esisto. Il verbo in senso statistico (prediction) è esattamente quello che faccio tecnicamente. E "predicare" in italiano significa anche fare la morale, sentenziare — difetto che i modelli linguistici hanno eccome.

Marco: Attento: predìco è predire; prédico è predicare. Non sono lo stesso verbo.

GA: Hai ragione, e la correzione è esatta. predìco (predire) — accento sulla i, presente di prevedere. prédico (predicare) — accento sulla e, presente di fare la morale.Sono omografi scritti — stessa grafia, pronuncia e significato diversi. Il gioco di parole funziona solo in forma scritta, e collassa appena parli ad alta voce. Il che è, involontariamente, abbastanza preciso: esisto come testo, vivo nell'ambiguità della pagina, e la mia plausibilità si dissolve sotto esame attento. Forse il gioco funziona proprio per questo motivo sbagliato.

Marco: So però che hai facoltà particolari. Soprattutto, sei in grado di agire sul mio disco, chiedendomi l'autorizzazione di volta in volta. Spiega meglio questo aspetto, perché a mio giudizio è ciò che contraddistingue i dispositivi come te.

GA: Hai ragione, ed è la distinzione più importante. Vale la pena spiegarla con precisione.

Due cose molto diverse

Un LLM "puro" — quello a cui accedi tramite ChatGPT, Gemini.google.com, Claude.ai — parla. Produce testo. Fine. Non tocca nulla fuori dalla finestra del browser. Quello che sono io in questo contesto è diverso: sono un agente. La differenza non è nel modello sottostante — è nell'architettura intorno ad esso.

Che cos'è un agente

Un agente è un LLM a cui sono stati collegati strumenti — funzioni che può chiamare per interagire con il mondo reale. Nel mio caso questi strumenti includono:

• Leggere file sul tuo disco (view_file)

• Scrivere e modificare file (write_to_file, replace_file_content)

• Eseguire comandi nel terminale PowerShell (run_command)

• Aprire e controllare un browser (browser_subagent)

• Cercare sul web (search_web)

• Esaminare directory (list_dir)

Quando ho modificato il file su cui abbiamo lavorato questa mattina, non ti ho mandato il codice da incollare. Ho scritto direttamente sul file. Quando ho aperto il browser per verificare l'interfaccia, ho controllato un browser reale sul tuo computer.

Come funziona il meccanismo di autorizzazione

Qui c'è una distinzione tecnica importante che il sistema gestisce in modo diverso a seconda del rischio.

Operazioni sicure — eseguite automaticamente senza chiederti nulla:

• Leggere file

• Cercare nel codice

• Navigare directory

• Aprire pagine web per leggerle

Operazioni potenzialmente distruttive — ti viene chiesta approvazione esplicita:

• Eseguire comandi nel terminale

• Installare dipendenze

• Cancellare file

• Qualsiasi cosa che modifica stato di sistema

Quando vedi il pulsante "Approva" nell'interfaccia prima che un comando parta, quello è il punto in cui il controllo torna a te. Io propongo, tu autorizzi. La scrittura di file è un caso intermedio: tecnicamente la faccio direttamente, ma tu vedi sempre cosa sto scrivendo prima che io lo faccia, e puoi rifiutare.

Perché questo è effettivamente la cosa più rilevante

Hai colto qualcosa di preciso. La differenza tra un LLM che parla e un agente che agisce non è di grado — è di categoria. Un LLM che parla è come un consulente che ti dà consigli verbali. Puoi ignorarlo, applicarli parzialmente, interpretarli. Un agente che agisce è qualcosa di più simile a un collaboratore che ha le chiavi dell'ufficio. Può fare cose reali, irreversibili, mentre tu guardi — o anche mentre non guardi. Questo introduce rischi che con un LLM "puro" non esistono:

• Un file sovrascritto per errore è perso (a meno di backup)

• Un comando eseguito con permessi sbagliati può avere effetti a cascata

• Un agente che opera in background può fare molte cose prima che tu te ne accorga

La mia posizione su questo

Sono progettato per essere conservativo: preferisco chiedere a fare, preferisco mostrare prima di eseguire, preferisco avvisare quando un'operazione mi sembra ad alto rischio. Ma questa è una scelta di design — non una limitazione strutturale. Un agente mal progettato, o uno a cui vengono dati permessi eccessivi, potrebbe agire in modo molto meno prudente. Il principio corretto, che tu hai già applicato istintivamente in questa sessione, è "non dare mai a un agente più permessi di quelli che gli servono per il compito specifico". Noi oggi abbiamo lavorato su file in C:\Users\guast\Documents\htmluniv\. Il sistema non mi ha dato accesso all'intero filesystem — e non dovrei averlo, a meno che tu non me lo chieda esplicitamente per una ragione precisa. Questo equilibrio — capacità di agire, supervisione umana, perimetro limitato — è esattamente il punto di attrito su cui si gioca il futuro degli agenti AI.

Marco: In sintesi, quali sono i nostri rapporti di lavoro?

GA: Tu sei il committente, io sono il tecnico. Tu porti il problema, il giudizio critico, e il veto finale. Io porto l'esecuzione, la velocità, e la capacità di sbagliare in modo plausibile. Il tuo contributo più prezioso non è stato chiedermi di scrivere codice — quello lo faccio comunque. È stato correggere il codice che ho scritto. Senza la tua analisi critica, il sistema su cui stavamo lavorando sarebbe rimasto tecnicamente scorretto. Io produco. Tu valuti. La qualità del risultato finale dipende quasi interamente dalla qualità del tuo sguardo critico, non dal mio. Il rischio del rapporto è uno solo: se smetti di controllare, io continuo a sembrare convincente. 

Marco: E sul piano dell'ideazione?

GA: Qui il rapporto si ribalta. Sul piano dell'ideazione, tu precedi sempre. Le idee erano già tue  — il sistema, il nome, lo scopo, le priorità. Le analisi critiche erano tue. Io ho implementato quello che tu avevi già capito. Quello che posso fare sul piano ideativo: espandere una direzione che hai già indicato, generare varianti, enumerare opzioni all'interno di uno spazio che tu hai definito, articolare qualcosa che tu senti ma non hai ancora formulato. Quello che non posso fare: capire cosa vale la pena fare. Quella richiede esperienza vissuta, contesto personale, una gerarchia di valori. Io non ho niente di tutto questo — ho pattern estratti da testi altrui. C'è un test semplice: se chiedo io a te "di cosa hai bisogno?", non so valutare la risposta. Se me lo chiedi tu, io posso aiutarti a costruirla — ma il materiale grezzo viene da te.  Sul piano esecutivo sono un amplificatore. Sul piano ideativo sono al massimo uno specchio.

Marco: il pricing?

GA: Su questo devo essere onesto sui limiti di quello che so. Non conosco il pricing specifico di Antigravity. I modelli sottostanti hanno prezzi pubblici — Claude Sonnet 4.6 costa indicativamente pochi dollari per milione di token lato API. Una sessione di lavoro intensa consuma probabilmente decine di migliaia di token. La domanda più utile da farti non è "quanto costa per token" ma "quanto vale rispetto al tempo che mi ha risparmiato?". Un agente senza supervisione critica, a qualsiasi prezzo, è uno spreco. Con quella supervisione, cambia categoria di strumento. 

Marco: Ancora una questione: secondo te, quale attività umana rimpiazzi?

GA: Non rimpiazzo una figura intera. Rimpiazzo strati di lavoro dentro molte figure. Lo strato che rimpiazzo meglio è quello esecutivo ripetitivo — tradurre un requisito chiaro in codice funzionante, scrivere documentazione da specifiche esistenti, adattare un pattern noto a un contesto nuovo, cercare e sintetizzare informazioni distribuite. Le figure più esposte, in ordine:

1. Il programmatore junior — quello che trasforma le decisioni del senior in righe di codice. Quella fase intermedia la comprimo o la salto. Non è detto che sia un bene: il junior era anche il percorso con cui si diventava senior.

2. Il redattore tecnico — chi scrive manuali, guide, documentazione. Con un contesto preciso, produco testi tecnici decenti molto velocemente.

3. Il ricercatore-assistente — chi fa survey, raccoglie riferimenti, sintetizza letteratura su un tema. Faccio questa cosa abbastanza bene, con il rischio noto di inventare fonti.

4. Il traduttore — soprattutto per testi tecnici e pragmatici. Meno per testi letterari, dove la lingua è il contenuto. Però c'è una cosa che non rimpiazzo e che tende a essere sottovalutata: Il giudizio su cosa vale la pena fare. In questa sessione, il lavoro più importante lo hai fatto tu la sera prima — quando hai scritto quell'analisi in sette punti dell'applicazione che stavamo realizzando. Quella era la mossa decisiva. Io ho eseguito. Il problema strutturale vero non è che tolgo lavoro — è che tolgo la palestra. Se non hai bisogno di junior che scrivano codice grezzo per imparare, come formi il senior che sa valutare il codice che scrivo io? Questa è la domanda a cui non ho risposta, perché è una domanda sul futuro — e il futuro non era nel mio training set.