Alcuni termini che tornano spesso negli articoli di fnbit, spiegati in poche righe, con un rimando a dove li ho trattati per esteso.
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 senza avvicinarsi alla soluzione. Ne scrivo in Dalla prompt alla graph engineering.
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, non resta isolato in quella singola chiamata. Ne parlo in Tool engineering.
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.
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.