Alcuni termini che tornano spesso negli articoli di fnbit, spiegati in poche righe, con un rimando a dove li ho trattati per esteso. Se ti serve prima il quadro d'insieme, parti da Cos'è l'AI engineering.
Prompt engineering
È il punto di partenza più familiare: scrivere l'istruzione giusta per ottenere la risposta giusta da un modello. Few-shot examples, chain-of-thought, ruoli assegnati al modello, formati di output specificati con precisione. Resta utile, ma nel 2026 il suo peso relativo si è ridimensionato, perché il divario tra i modelli di punta si è ristretto parecchio rispetto agli anni precedenti: i trucchi di prompting funzionano più o meno allo stesso modo su qualsiasi modello frontier. Ne parlo più a fondo in Dalla prompt alla graph engineering.
Context engineering
Non è scrivere un'istruzione migliore, è decidere cosa il modello vede prima di rispondere: quali dati recuperare, in che formato, in che ordine, quali strumenti rendere disponibili, quanta cronologia includere e cosa invece tagliare fuori perché rumore. È il motivo per cui più informazione non significa automaticamente risultati migliori: un modello con troppo contesto irrilevante comincia a dimenticare dettagli critici e a fare errori con sicurezza. Approfondito in Dalla prompt alla graph engineering.
Loop engineering
Un prompt singolo produce una risposta singola. Un agente ragiona in cicli: osserva lo stato attuale, decide un'azione, la esegue, osserva il risultato, decide il passo successivo. Progettare questo ciclo bene vuol dire definire condizioni di uscita chiare, gestire un errore senza far collassare l'intero processo, e capire quando fermarsi invece di lasciare che il modello giri in tondo. Ne scrivo in Dalla prompt alla graph engineering; quando il loop è di troppo, in Quando un agente non serve.
Graph engineering
Quando un singolo ciclo agente-azione-osservazione non basta più, il problema diventa orchestrare più agenti con responsabilità diverse, in un flusso che spesso si ramifica invece di essere lineare. La graph engineering modella il sistema come un grafo di nodi (agenti, strumenti, punti di decisione) e archi (le condizioni che determinano dove va il flusso), con percorsi condizionali espliciti. Approfondito in Dalla prompt alla graph engineering.
Tool engineering
Riguarda il modo in cui progetti i tool che dai in mano a un agente. Un tool va trattato come un'API pubblica rivolta a un modello che ha letto la descrizione una volta sola e non può fare domande di chiarimento: se la descrizione non specifica con precisione cosa fa il tool, quando va usato e cosa restituisce, l'agente lo userà nel modo sbagliato, e l'errore si propaga in tutto il loop successivo. Ne parlo in Tool engineering.
Skills
Cartelle di istruzioni, script e risorse che l'agente carica quando servono, pensate per far affrontare lo stesso tipo di task sempre nello stesso modo, anche in un team. Le metto a confronto con AGENTS.md, MCP e tool nella pagina Skills per agenti AI.
AGENTS.md
Un file Markdown nella root del repository (CLAUDE.md in alcuni strumenti) che l'agente legge a ogni turno: comandi del progetto, convenzioni di stile, errori da evitare. È la superficie di estensione con meno overhead. Lo uso anche per fissare lo stack, come racconto in La trappola dello stack di default.
MCP (Model Context Protocol)
Un protocollo aperto che permette a un agente di scoprire e chiamare strumenti esterni (API, database, servizi di terze parti) in modo standardizzato, con autenticazione e permessi granulari. Evita di scrivere un'integrazione su misura per ogni servizio. Il contesto è nell'hub Vibe coding.
Grounding
Dare al modello informazioni verificabili e aggiornate prima che risponda, invece di lasciarlo affidarsi a quello che ricorda dall'addestramento. Un caso concreto è la ricerca web live dentro un tool: lo racconto in Web Search API di Cloudflare.
AI locale
Tenere modello e loop sotto il tuo controllo: Ollama sul laptop, llama.cpp su una macchina dedicata, un fine-tune, un harness che chiama tool sul filesystem, anche un VPS tuo. Il punto non è «senza internet», è controllo su runtime, log e costi. Quando conviene e quando no: Guida AI locale 1.
Runtime
Il programma che carica i pesi di un modello e genera i token sulla tua macchina o su un server tuo: Ollama, LM Studio, llama.cpp, vLLM. Non fanno lo stesso mestiere. Ollama e LM Studio sono soprattutto un'esperienza comoda (download, impostazioni di default, API pronta), llama.cpp è spesso il motore che lavora sotto, vLLM è un sistema di serving pensato per tante richieste insieme. Si sceglie in base a quanti utenti hai, che hardware, e quanta manutenzione sei disposto a fare, non in base a una classifica. Il confronto con i vincoli veri è in Guida AI locale 2; prima ancora, se il locale ti serve davvero lo discuto in Guida AI locale 1.
GGUF
Il formato di file dei modelli per llama.cpp e per i runtime costruiti sulla stessa libreria (GGML). Un solo file contiene i pesi, spesso già quantizzati, e i metadati che servono a caricarli, come architettura e tokenizer: per questo un file .gguf si scarica e parte senza file accessori. Il nome segue una convenzione che dice a colpo d'occhio modello, dimensione, versione e tipo di quantizzazione. Ha preso il posto dei vecchi formati GGML e GGJT, come racconta la specifica ufficiale di GGUF. Dove si incastra tra i runtime lo spiego in Guida AI locale 2; un caso in cui il file sotto un modello cambia senza che tu faccia nulla è Ollama 0.40.
Quantizzazione
Salvare i pesi di un modello con meno bit, per esempio 4 o 8 invece di 16, per farlo stare in meno memoria e spesso farlo girare più veloce. Il prezzo è una perdita di precisione, che llama.cpp misura con perplexity e KL divergence rispetto al modello originale, come spiega il README di llama-quantize. Nei file GGUF il livello è nel nome (Q8_0, Q6_K, Q4_K_M…). Non è l'unica voce di memoria: anche la KV cache pesa, e cresce con il contesto. Come fare il conto della VRAM e scegliere tra Q4 e Q8 in base agli errori che tolleri è in Guida AI locale 3.
Q4 e Q8
Sono i livelli di quantizzazione che leggi nei nomi dei file GGUF: il numero indica più o meno quanti bit per peso, la parte dopo il trattino il metodo. Q8_0 è il livello alto, vicino all'originale; Q4_K_M è il punto di partenza più diffuso. Non sono bit esatti: i k-quants mescolano tipi diversi tra i tensori, e nella tabella del README di llama-quantize per Llama 3.1 8B Q4_K_M vale circa 4,89 bit per peso e Q8_0 circa 8,50. La pagina GGUF di Hugging Face elenca tutti i tipi. Tra i due non vince il file più grande: si sceglie dagli errori che il modello fa sul tuo compito, provando entrambi sullo stesso set di prompt, come spiego in Guida AI locale 3.
VRAM
La memoria della scheda video. Per far girare un modello in locale ci devono stare insieme tre cose: i pesi (che dipendono da parametri e quantizzazione), la KV cache (che cresce con il contesto e con le richieste in parallelo) e un margine. Per allenare il conto è diverso e molto più alto: nel full fine-tuning con Adam la guida di Transformers sulla memoria arriva a circa 18 byte per parametro, attivazioni escluse. Il conto per l'inferenza è in Guida AI locale 3, quello per il fine-tuning in LoRA, QLoRA o full fine-tuning. Su Mac con Apple Silicon la memoria è unificata, quindi il ragionamento cambia: ne parlo in Mac con Apple Silicon o GPU NVIDIA.
KV cache
Quando un modello genera testo, ogni nuovo token dipende dall'attenzione su tutti i token precedenti. La KV cache conserva quei calcoli intermedi (le chiavi e i valori dell'attenzione) così non vanno rifatti a ogni passo, come spiega la documentazione di Transformers. Il prezzo è la memoria: cresce con la lunghezza del contesto e con il numero di richieste servite insieme, e si somma ai pesi del modello. È il motivo per cui un modello che entra in VRAM può restare senza memoria quando allunghi il contesto. Alcuni runtime la possono quantizzare (Ollama lo documenta nelle sue FAQ), mentre vLLM la gestisce a blocchi per tenere tante conversazioni sulla stessa GPU. Che ruolo ha nello scheduler di un runtime lo trovi in Guida AI locale 2.
Prompt caching
Il provider dell'API tiene in memoria la parte iniziale del prompt che si ripete tra una richiesta e l'altra (istruzioni di sistema, definizioni dei tool, documenti lunghi) e te la fa pagare meno quando la riusa. Funziona solo sul prefisso identico: basta cambiare un carattere all'inizio e la cache non serve più. Da Anthropic la attivi con cache_control, con una durata di 5 minuti di default o di un'ora a costo maggiore (documentazione Anthropic); OpenAI la applica in automatico sui modelli supportati (guida OpenAI). Non è la cache delle risposte di un gateway, che restituisce una risposta già data: il confronto tra i provider è in Prompt caching nelle API LLM, la cache del gateway in Cloudflare AI Gateway.
API OpenAI-compatible
Un server che accetta le stesse richieste HTTP dell'API di OpenAI (stessi path, come /v1/chat/completions, stessi campi JSON, stesso formato di risposta), così il client ufficiale funziona cambiando indirizzo, chiave e nome del modello. Ollama, LM Studio, il server di llama.cpp e vLLM la espongono tutti. Compatibile però vuol dire sottoinsieme, non identico: tool calling, output strutturato e parametri meno comuni vanno verificati runtime per runtime. Come fare il cambio senza riscrivere il client: API OpenAI-compatible in locale.
LoRA
Low-Rank Adaptation: un modo di fare fine-tuning senza toccare i pesi del modello. Il modello base resta congelato e accanto agli strati scelti si allenano due matrici piccole, il cui prodotto rappresenta la modifica; quello che ottieni è un adapter, un file leggero da applicare sopra il modello base o da fondere nei suoi pesi. Il metodo viene dal paper di Microsoft del 2021, e le manopole principali (rank, alpha, moduli target) sono descritte nella guida concettuale di PEFT. Quando conviene rispetto al fine-tuning completo e quanta memoria chiede: LoRA, QLoRA o full fine-tuning.
QLoRA
LoRA con il modello base caricato a 4 bit. Il paper del 2023 introduce il tipo di dato NF4, la doppia quantizzazione e gli optimizer paginati; si allenano sempre e solo gli adapter. Il vantaggio è la memoria: nella tabella dei requisiti di Unsloth un modello da 8 miliardi di parametri chiede come minimo 6 GB con QLoRA contro 22 GB con LoRA a 16 bit. In cambio è leggermente più lento e, secondo la stessa documentazione, marginalmente meno accurato. Dopo l'allenamento l'adapter si fonde nel modello e si converte nel formato del runtime, come racconto in GGUF, safetensors o MLX; la scelta tra i tre metodi è in LoRA, QLoRA o full fine-tuning.
Vibe coding
Descrivi cosa vuoi, il modello scrive il codice, tu accetti e vai avanti. Porta da idea a prototipo in ore. La parte difficile è dopo: sicurezza, privacy, accessibilità e scelte di stack che il modello non fa per te. La raccolta è nell'hub Vibe coding, la lista di controllo in La checklist per portare in produzione un sito vibe-coded.
Architettura prima dell'implementazione
Un principio che torna spesso nei miei articoli: definire i confini dei componenti, come comunicano tra loro, dove vivono i dati, prima di scrivere codice, invece di lasciare che sia un modello AI a inventare la struttura mentre genera. È il tema centrale di La trappola dello stack di default, dove spiego perché l'AI converge sempre sullo stesso stack e come uscirne ragionando prima sui vincoli reali del progetto.
CMS headless
Un CMS che gestisce solo i contenuti e li espone via API, mentre il sito lo costruisci a parte (nel mio caso con Astro). Ho usato in produzione Strapi, WordPress headless ed EmDash: il confronto è in Strapi vs EmDash vs WordPress.
Stack serverless
Un'architettura in cui l'esecuzione del codice, il database e lo storage vivono su servizi gestiti che scalano in base all'uso reale, invece che su un server con capacità fissa da mantenere manualmente. Ne racconto un'applicazione concreta in Cloudflare Workers + D1 + R2; per la scelta del database, SQLite vs Postgres per un prodotto indie.
Binding
Il collegamento dichiarato nella configurazione di un Worker (il file Wrangler) tra il codice e una risorsa di Cloudflare: un database D1, un bucket R2, un namespace KV, un limite di richieste. Nel codice lo trovi come proprietà di env, per esempio env.DB, senza connection string né chiavi da gestire. La documentazione sui binding li presenta come la via più veloce e con meno restrizioni rispetto alle API REST, pensate per chi sta fuori da Workers. Il rovescio è il lock-in: sono API Cloudflare, e spostarsi vuol dire riscrivere quei pezzi, come spiego in Vercel vs Cloudflare vs VPS. Uno stack intero costruito sui binding è in Cloudflare Workers + D1 + R2.
Static Assets
La funzione di Workers che serve file statici (HTML, CSS, immagini, JavaScript del client) caricati insieme al Worker, con Cloudflare che si occupa di cache e consegna. Secondo la pagina su costi e limiti, le richieste che trovano un file statico sono gratuite e illimitate; quelle che passano dal codice del Worker, come il rendering lato server, si pagano come normali richieste Workers. È il pezzo che sostituisce Cloudflare Pages per i siti: il passaggio con Astro, binding ASSETS compreso, è in Migrare un sito Astro da Pages a Workers.
Object storage
Uno storage che salva file interi come oggetti dentro un bucket, ognuno con una chiave e dei metadati, invece che in cartelle su un disco o in righe di un database. Ci finiscono upload degli utenti, immagini, backup, export. L'interfaccia di riferimento è quella di Amazon S3, e molti servizi la imitano: Cloudflare R2 è compatibile con le API S3, quindi spesso cambi solo l'endpoint del client. Come si inserisce R2 in uno stack è in Cloudflare Workers + D1 + R2; perché ci mandi i backup di un database SQLite, in SQLite vs Postgres.
Egress
Il traffico in uscita: i dati che il tuo storage o il tuo server mandano verso Internet, per esempio quando un utente scarica un'immagine dal bucket. Molti provider cloud lo fanno pagare a GB, ed è la voce che cresce quando un progetto prende traffico, anche se lo storage resta piccolo. Sui prezzi di R2 l'egress verso Internet è gratuito per ogni classe di storage, mentre su Amazon S3 il trasferimento dati in uscita ha una sua tariffa. Ne parlo in Cloudflare Workers + D1 + R2 e, tra le voci di costo delle piattaforme, in Vercel vs Cloudflare vs VPS.
ORM
Object-Relational Mapping: una libreria che ti fa definire le tabelle e scrivere le query nel linguaggio dell'applicazione (TypeScript, per esempio) invece che in SQL a mano, con i tipi che seguono lo schema. Di solito porta con sé anche gli strumenti per generare le migrazioni. Drizzle e Prisma sono i due più usati nell'ecosistema TypeScript. Su un Worker con D1 la scelta non è di gusto: cambiano transazioni, migrazioni e peso del client, come spiego in Drizzle vs Prisma con D1 e SQLite.
Migrazione
Un file, di solito SQL, che porta lo schema del database da una versione alla successiva: crea una tabella, aggiunge una colonna, un indice. Le migrazioni si applicano in ordine e il database tiene traccia di quelle già eseguite. Su D1 i file stanno nella cartella migrations/ e quelle applicate finiscono nella tabella d1_migrations, come da documentazione D1; le applichi con wrangler d1 migrations apply. Chi le scrive, se tu o l'ORM, è una delle differenze tra Drizzle e Prisma in Drizzle vs Prisma con D1. Prima di lanciarne una su dati veri conviene segnarsi un punto di ripristino: vedi Time Travel.
Time Travel (D1)
Il sistema di backup e ripristino a un punto nel tempo di Cloudflare D1. È sempre attivo, non si configura e non costa nulla in più: secondo la documentazione di Time Travel puoi riportare il database a qualsiasi minuto degli ultimi 30 giorni sul piano Workers Paid, 7 su quello Free. Ripristina però l'intero database, non una tabella o una riga, e la cronologia vive dentro D1 stesso. Per questo una copia che controlli tu, l'export in SQL, resta utile: cosa copre e cosa no è in Backup di D1.
Rate limiting
Limitare quante richieste un client può fare in un intervallo di tempo, rispondendo con un errore 429 quando supera la soglia. Serve contro abusi, scraping e costi che esplodono su endpoint che chiamano API a pagamento. Su Workers c'è un binding dedicato: lo configuri con una soglia e un periodo di 10 o 60 secondi, e la documentazione del binding Rate Limiting avverte che il conteggio è approssimato, per location e aggiornato in background, quindi qualche richiesta può passare oltre il limite. Quando basta il binding e quando servono le regole WAF o un Durable Object è in Rate limiting su Cloudflare Workers.