Il modello, quello che chiamano LLM, è un programma a cui passi del testo e che ti risponde con altro testo che ha senso. Gli scrivi una domanda e ti risponde, gli chiedi una funzione e te la scrive. È la parte che ragiona.

Da solo però si ferma al pensiero. Non apre i tuoi file, non lancia comandi sul tuo computer, non sa niente del tuo progetto finché non sei tu, o qualcosa per te, a passarglielo. Tutto quello che serve per agire davvero sul codice lo aggiungono i pezzi che vengono dopo.

Il modello gira sui computer di qualcuno, e il provider è chi te lo mette a disposizione. Per usarlo ti colleghi a lui, di solito con una chiave personale o con un abbonamento. Anthropic ti serve Claude, OpenAI ti serve GPT, Google ti serve Gemini, Z.AI ti serve GLM.

C'è anche un'altra strada. Molti modelli sono aperti e puoi scaricarli per farli girare direttamente sul tuo computer, in locale: Llama, Qwen, Gemma, e perfino versioni aperte di GLM. Qui non c'è un provider esterno, ma serve un programma che faccia girare il modello sulla tua macchina, e quel programma fa da provider locale. I due più usati sono Ollama, che lavora da terminale, e LM Studio, che ha un'interfaccia grafica.

Quale modello riesci davvero a far girare dipende dalle risorse del tuo computer, soprattutto la memoria e la scheda video: più il modello è grande, più ne chiede. Programmi come LM Studio ti aiutano proprio in questo, perché ti mostrano quali modelli il tuo hardware regge e quanto serve per ciascuno, così scegli quello giusto per la tua macchina.

Perché un programma possa usare un modello, deve sapere come parlargli. Gli manda la domanda e ne riceve la risposta seguendo un formato preciso, e quel formato è l'API. Il fatto è che di formati ne esistono diversi.

I due mondi che contano oggi sono lo stile di OpenAI, che storicamente si chiama chat completion e ha una versione più recente chiamata responses, e lo stile di Anthropic. Funzionano come prese elettriche di forma diversa: un programma costruito per l'API di OpenAI non riesce a infilarsi in quella di Anthropic, anche se dietro c'è un modello bravissimo.

Qui arriviamo al pezzo centrale. Un agente prende un modello, che per conto suo saprebbe soltanto parlare, e lo mette in condizione di lavorare davvero sul codice. È un involucro costruito intorno al modello, e dentro ci sono quattro cose che lavorano insieme.

• Il modello, cioè il cervello, che l'agente raggiunge via API oppure in locale.
• I tool, gli strumenti operativi, le mani con cui legge e scrive i file, lancia comandi, fa ricerche.
• La memoria e il contesto, cioè quello che l'agente sa del tuo progetto e si tiene a mente mentre lavora.
• Il loop, il ciclo che fa girare tutto, e gira così: pensa → agisce → guarda com'è andata → ripensa, finché il compito non è finito.

Non tutti gli agenti si portano dietro un modello di casa. Alcuni nascono senza cervello proprio: il modello glielo dai tu, con la tua chiave, e loro lo fanno lavorare. È la famiglia che si chiama BYOK — sigla inglese di Bring Your Own Key, «porta la tua chiave» — e tre esempi aperti aiutano a vederla.

• Cline vive come estensione dentro VS Code.
• KiloCode è anch'esso un'estensione per l'editor, su VS Code, Cursor e perfino JetBrains. È nato come superset di Cline e Roo Code, cioè le rifà tutte e due e ci aggiunge roba sopra. È open source.
• OpenCode invece vive nel terminale, ed è provider-agnostic: lo colleghi a oltre settanta provider diversi. Anche lui open source.

Sono lo stesso tipo di pezzo, lo stesso operaio senza cervello fisso, montato su porte diverse: KiloCode nell'editor, OpenCode nel terminale. Tienilo a mente, torna utile fra due pezzi.

Lo stesso agente lo puoi comandare da posti diversi, e questi posti si chiamano superfici. Prendi Claude Code. Da dove lo usi?

• da una CLI, cioè il terminale dove dai comandi scritti
• da una app desktop, una finestra con i suoi bottoni
• da un'estensione dentro un IDE, agganciato all'editor dove scrivi codice
• dal web, direttamente nel browser

È sempre lo stesso agente con lo stesso cervello dietro, e quello che cambia è solo la porta da cui entri. Anche Codex funziona così, con la sua CLI, la sua app, l'estensione per l'IDE e una versione che gira nel cloud.

Un IDE, per esempio VS Code, è il programma dove apri i file di un progetto, vedi com'è fatto a cartelle e lo modifichi. È l'officina dove guardi il codice. Gli IDE di oggi accettano plugin ed estensioni, e questo cambia le cose, perché dentro l'officina ci puoi far entrare uno o più agenti.

Una domanda che viene naturale. E un modello, ce lo posso mettere dentro? Ha senso mettere Opus dentro VS Code? Da solo no, perché un modello è solo un cervello che risponde e non sa toccare i file. Quello che agganci all'IDE è sempre un agente, o un'estensione, che il modello lo usa per conto suo. Quando senti dire Opus dentro VS Code, in pratica vuol dire installare un'estensione-agente collegata a Opus.

E qui c'è il passaggio che confonde di più, ed è su Cursor. Cursor è un IDE che si porta dietro un agente suo, il Cursor Agent, già pronto di fabbrica. Siccome però è costruito sulla base di VS Code, dentro Cursor puoi farci entrare anche un altro agente, per esempio Claude Code, installandolo come estensione oppure scrivendo claude nel suo terminale integrato. A quel punto, nella stessa finestra, hai due agenti diversi che convivono, il Cursor Agent e Claude Code. Ognuno ragiona per conto suo, con il suo cervello e il suo abbonamento, e non sa nemmeno cosa sta facendo l'altro. È sempre la stessa officina, ma dentro ci lavorano due agenti diversi.

Il lavoro può girare sul tuo computer, in locale, e allora i file restano da te e serve la tua macchina accesa. Può girare su un computer nel cloud, da qualche parte sui server di qualcuno, e in quel caso va avanti anche a computer tuo spento. Oppure può lavorare in modo ibrido, una parte da te e una parte nel cloud.

Per ora bastano queste tre risposte. Esistono varianti più tecniche, un server tuo raggiunto da remoto o le pipeline che girano da sole, ma non ti servono per capire il quadro.