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 una questione di ore, non di settimane. Su questo non c'è dibattito: funziona.
Il problema è quello che succede dopo. «Funziona in demo» e «pronto per la produzione» sono due condizioni diverse, e la distanza si misura in vulnerabilità, obblighi normativi ignorati e, in Italia e in Europa, sanzioni concrete. Non per malafede di chi costruisce: l'AI scrive codice che funziona, non codice automaticamente sicuro o conforme.
Prima del deploy
- La checklist per portare in produzione un sito vibe-coded: sicurezza tecnica, igiene del deploy, privacy e cookie secondo il Garante, accessibilità secondo l'European Accessibility Act.
- Segreti, .env e chiavi API nei progetti vibe-coded: dove finiscono le chiavi (bundle client, storia Git, log di CI), come ruotarle e quali controlli mettere prima del push.
- Dipendenze inventate dall'AI: il modello a volte importa pacchetti che non esistono, e qualcuno può registrarli. Cos'è lo slopsquatting e cosa controllare prima di npm install o pip install.
Con cosa costruisci
Il secondo livello è meno discusso: non solo cosa controlli prima di pubblicare, ma con cosa costruisci. Il modello tende a proporre sempre lo stesso stack, e lo stack scelto per inerzia è un costo che paghi dopo.
- La trappola dello stack di default: perché l'AI suggerisce sempre Next.js, Tailwind e Prisma, e come uscirne.
- Cloudflare Workers + D1 + R2: lo stack serverless al posto del VPS per progetti indie, con quello che perdi.
- Vercel vs Cloudflare vs VPS per un prodotto indie: la domanda giusta non è il prezzo di partenza ma cosa ti costa uscire tra un anno, con i listini ufficiali e una checklist per scegliere.
- SQLite vs Postgres per un prodotto indie: la domanda non è la scala, sono hosting, backup e concorrenza in scrittura.
- Drizzle vs Prisma con D1 e SQLite: su un Worker l'ORM decide chi applica le migrazioni, cosa succede alle transazioni e quanto pesa sullo startup.
- Strapi vs EmDash vs WordPress: quale CMS headless scegliere, da chi li ha usati tutti e tre in produzione.
- Cloudflare spinge cf al posto di Wrangler: cosa cambia se il tuo agente genera ancora comandi wrangler.
Come dai regole all'agente
Il modo in cui un agente accede a strumenti, contesto e conoscenza del progetto oggi passa da quattro superfici diverse, spesso confuse tra loro.
- Un file
AGENTS.md(oCLAUDE.md, a seconda dello strumento) nella root del repository: comandi, convenzioni ed errori da evitare, letto a ogni turno. È la superficie con meno overhead, e insieme agli strumenti da riga di comando che l'agente ha già (git, npm, grep) copre molti casi. Cosa metterci dentro, e cosa leggono davvero Cursor e Claude Code, è in AGENTS.md, CLAUDE.md e regole di Cursor. - Le Skills: cartelle di istruzioni, script e risorse caricate quando servono, per imporre coerenza in un team. Le spiego in Skills per agenti AI.
- MCP (Model Context Protocol): un protocollo aperto per scoprire e chiamare strumenti esterni (API, database, servizi) con autenticazione e permessi.
- I tool veri e propri, le singole funzioni con schema di input e output: come progettarli è in Tool engineering.
Capire quando usare l'uno invece dell'altro pesa spesso più della scelta del modello. Le definizioni brevi sono nel glossario; il lato agenti e sistemi AI è nell'hub AI Engineering.
