Descrivi cosa vuoi costruire, il modello scrive il codice, tu accetti i suggerimenti e vai avanti. Il vibe coding ha reso il passaggio da idea a prototipo funzionante una questione di ore, non di settimane, e su questo non c'è dibattito: funziona, ed è qui per restare.
Il problema è quello che succede dopo il prototipo. "Funziona in demo" e "pronto per la produzione" sono due condizioni completamente diverse, e la distanza tra le due si misura in vulnerabilità di sicurezza, obblighi normativi ignorati, e in Italia e in Europa anche in sanzioni concrete. Un'analisi su migliaia di app generate con l'AI ha trovato che la stragrande maggioranza conteneva almeno una vulnerabilità critica — non per malafede di chi le ha costruite, ma perché l'AI scrive codice che funziona, non codice che è automaticamente sicuro o conforme. Il primo pezzo di questa raccolta è proprio la checklist per il deploy in produzione, che copre sicurezza tecnica, igiene del deploy, privacy e cookie secondo il Garante, e accessibilità secondo l'European Accessibility Act.
C'è però un secondo livello del discorso, altrettanto trascurato: con cosa costruisci, non solo cosa controlli prima di pubblicare. Il modo in cui un agente AI accede a strumenti, contesto e conoscenza del progetto è cambiato radicalmente nell'ultimo anno, e oggi convivono almeno quattro approcci diversi, spesso confusi tra loro.
Il più semplice, e probabilmente il più sottovalutato, è un file AGENTS.md (o CLAUDE.md, a seconda dello strumento) nella root del repository: un documento Markdown che l'agente legge a ogni turno, con i comandi del progetto, le convenzioni di stile, gli errori da evitare. Combinato con gli strumenti da riga di comando che l'agente ha già a disposizione — git, npm, grep, i comandi del tuo stack — è la superficie di estensione con meno overhead di tutto l'ecosistema, e in certi benchmark batte approcci molto più sofisticati.
Poi ci sono le Skills: cartelle che raccolgono istruzioni, script e risorse che l'agente carica quando servono, pensate per essere condivise in un team per imporre coerenza — la stessa "voce" del progetto, le stesse regole di formattazione, lo stesso modo di affrontare un certo tipo di task, riutilizzabili invece di essere riscritte ogni volta.
Diverso ancora è 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 incorporati. È quello che rende possibile, per esempio, collegare un agente direttamente a Gmail, Google Drive o Asana senza dover scrivere un'integrazione su misura per ognuno.
E infine ci sono i tool veri e propri che dai in mano a un agente all'interno di questi sistemi: le singole funzioni che l'agente può chiamare, con il loro schema di input e output — un argomento che ho già trattato a fondo parlando di come un tool mal descritto rompa tutto il loop in cui viene usato.
Ognuno di questi quattro pezzi — CLI/AGENTS.md, Skills, MCP, tool — meriterà un articolo dedicato in questa raccolta, perché capire quando usare l'uno invece dell'altro è probabilmente la decisione architetturale più importante che prendi quando costruisci con l'AI oggi, più della scelta del modello stesso. Aggiungo i pezzi man mano che affronto problemi concreti lavorando così ogni giorno, non secondo un calendario fisso.
