Hai mai chiesto a Cursor, GitHub Copilot o Claude Code di "iniziami un nuovo progetto web" o "creami un boilerplate per un SaaS"?
La risposta è quasi sempre un copia-incolla statistico, sacro e intoccabile: Next.js, Tailwind CSS, Prisma e PostgreSQL (spesso con Supabase).
Funziona? Sulla carta, sì. È la scelta giusta per il tuo progetto specifico? Quasi mai.
Questo non è un complotto delle Big Tech, ma un classico bias di disponibilità. I modelli linguistici sono addestrati su milioni di repository, tutorial e articoli pubblici. Poiché quello specifico ecosistema è il più diffuso e chiacchierato negli ultimi anni, per l'AI rappresenta il "percorso di minima resistenza" statistico per generare codice che non vada in errore immediato.
Il problema è che l'AI è un esecutore eccezionale, ma un architetto mediocre se non viene guidata. Se le dai un prompt vago, ti restituirà la media di GitHub, non la soluzione ottimale per i tuoi vincoli.
Se vuoi usare l'AI per sviluppare (il cosiddetto "vibecoding") senza trasformare il tuo side project in un incubo di manutenzione, devi smettere di subire lo stack di default. Ecco come riprendere il controllo.
1. Perché l'AI è ossessionata da questo stack?
Per capire come battere il sistema, bisogna capire come "pensa" il modello:
- Bias nei dati di training: La stragrande maggioranza dei tutorial "How to build a SaaS in 2024/2025" usa esattamente questa combinazione. L'AI predice il token successivo più probabile, e quel stack è la modalità statistica.
- La "Happy Path" Illusion: L'AI evita i casi limite. Sceglie tool con il maggior numero di risposte su StackOverflow, anche se sono overkill per un progetto che deve solo mostrare tre pagine e un form di contatto.
- Vendor Lock-in mascherato da best practice: L'ecosistema Vercel/Supabase è pesantemente promosso nei dati di addestramento. L'AI lo suggerisce come "standard", nascondendo i costi nascosti (limiti delle serverless functions, cold start, pricing a scalare) che per un progetto indie possono essere letali.
2. Il costo nascosto del "Default Stack"
Accettare il boilerplate di default significa importare la complessità di qualcun altro:
- Prisma è fantastico per team grandi, ma per un progetto piccolo introduce un overhead di build, un bundle più pesante e noti problemi di cold start nelle funzioni serverless.
- Next.js con App Router e Server Components aggiunge un livello di astrazione e debugging che per un sito a prevalenza lettura (o un tool interno) è puro spreco di tempo.
- Tailwind va bene, ma spesso l'AI ne abusa, creando classi inline illeggibili invece di usare componenti riutilizzabili o CSS nativo quando sarebbe più semplice.
## 3. La regola d'oro del Vibecoding: se non è in un file .md, non esiste
L'AI non ha memoria a lungo termine delle tue intenzioni architetturali, e il contesto della chat si perde dopo pochi scambi. Se vuoi che l'AI rispetti le tue decisioni, devi scriverle nel codice, prima di scrivere il codice.
Prima di generare anche solo una riga, crea questi file nella root del tuo progetto e istruisci l'AI a leggerli sempre:
- PRD.md (Product Requirements Document): Cosa stiamo costruendo e per chi. In 10 righe secche.
- ARCHITECTURE.md: Lo stack scelto e, soprattutto, il perché. Esempio: "Usiamo Astro invece di Next.js perché il sito è 90% contenuto statico e vogliamo zero JavaScript inviato al client. Usiamo SQL diretto invece di Prisma per evitare l'overhead del bundle e mantenere le query trasparenti".
- AI_RULES.md (o .cursorrules): Le leggi non scritte del progetto. Esempio:
- "Non installare mai nuove dipendenze senza chiedermelo prima."
- "Preferisci sempre la semplicità alla cleverness."
- "Se una funzionalità può essere fatta con HTML/CSS nativo, non usare JavaScript."
Quando l'AI ha questi file nel contesto, smette di essere un generatore di boilerplate e diventa un pair programmer che conosce i vincoli del tuo progetto.
4. Usa le "Skills" per blindare il tuo stack
Strumenti moderni come Cursor o Claude Code permettono di definire "Skills" o regole globali. Questo è il livello successivo della documentazione: trasformare le tue regole .md in vincoli attivi e inattaccabili.
Invece di sperare che l'AI si ricordi di non usare un certo pattern, configura una skill che glielo impedisca. Se hai deciso che il tuo progetto usa un approccio leggero, la skill deve contenere istruzioni esplicite come:
> "Quando generi codice per il database, usa sempre query SQL native. Non suggerire mai Prisma, Drizzle o altri ORM a meno che non venga esplicitamente richiesto. Spiega brevemente perché la query SQL è più efficiente in questo contesto."
Stai codificando la tua architettura nelle istruzioni stesse del modello, forzandolo a ragionare prima di agire.
5. Il prompt architetturale (da copiare e incollare)
Smetti di chiedere "creami un'app". Inizia a chiedere così:
> "Agisci come un architetto software senior. Leggi i file PRD.md, ARCHITECTURE.md e AI_RULES.md nella root. Devo implementare [X]. I miei vincoli non negoziabili sono: 1) Budget hosting < 5€/mese, 2) Zero SSR se non strettamente necessario, 3) Nessun ORM, solo SQL nativo. Proponi 3 opzioni di implementazione confrontando pro e contro rispetto a questi specifici vincoli*. Poi, scrivi la struttura delle cartelle e il codice di avvio per l'opzione più semplice."*
Conclusione
Il vero superpotere dello sviluppo moderno non sta nel far scrivere codice all'AI, ma nel saperle fornire il contesto giusto.
La prossima volta che il tuo assistente AI ti suggerisce automaticamente Next.js, Tailwind e Prisma, fermati. Non accettare il default. Apri un file ARCHITECTURE.md, scrivi i tuoi vincoli reali, e costringi l'AI a ragionare su quelli.
La complessità non è un badge d'onore. È un costo. E come architetti, il nostro lavoro è tenerla sotto controllo.
