Problemi comuni nel costruire con AI:10 soluzioni
Problemi comuni nel costruire con AI, decifrati: cosa vedi, cosa succede davvero sotto, la soluzione esatta — e il prompt che ti sblocca. Le 10 soluzioni.
Quando ti blocchi costruendo con l'AI, si tratta quasi sempre di uno dei problemi comuni nel costruire con AI — quasi mai di uno nuovo. Gli stessi dieci scenari spiegano quasi ogni momento da "non ho idea di cosa fare adesso" in cui incappa un fondatore non tecnico — e ognuno ha una causa nota e una soluzione nota. Sbloccarsi non è eroismo. È riconoscere gli schemi.
Questa è la top ten selezionata da un elenco di venti scenari di blocco che tengo per gli studenti del corso AI Product Builder — quelli che tornano più e più volte. Trova il tuo sintomo nella tabella, capisci cosa sta succedendo davvero, applica la soluzione. Se non hai ancora imparato a leggere i messaggi di errore nella console del browser, fallo prima — trasforma ogni scenario qui sotto da mistero in diagnosi.
Perché ti blocchi (e perché non è mai a caso)
Ogni scenario di blocco ha una di tre radici. O il tuo ambiente si è disallineato (il database non è sincronizzato con il codice, manca un'impostazione, una cache è obsoleta), o il tuo codice ha un difetto specifico (un refuso, un controllo mancante, un import sbagliato), o i tuoi dati non sono ciò che pensi (filtrati via, nell'account sbagliato, segnati come inattivi). Il codice generato dall'AI aggiunge una complicazione: spesso il codice funziona — sono le ipotesi attorno a rompersi.
Ecco perché "riprova" funziona di rado e perché il metodo batte l'affanno. Abbina il sintomo, controlla la radice, applica la soluzione.
I 10 problemi comuni nel costruire con AI, decifrati
| Cosa vedi | Cosa sta succedendo davvero | La soluzione |
|---|---|---|
| 400 Bad Request, "column does not exist" | Il codice si aspetta una colonna del database che non è mai stata creata — codice e database non sono sincronizzati | Applica le migrazioni del database in sospeso, poi controlla la tabella nella dashboard di Supabase per confermare che la colonna esista |
| I dati esistono ma non compaiono | I dati vengono filtrati via: flag di inattività, stato di bozza, oppure appartengono a un altro account | Controlla la riga nella dashboard del database — guarda flag come is_active e l'account a cui appartiene |
| 401 Unauthorized | La sessione è scaduta o sei stato disconnesso | Esci e rientra; se persiste, cancella i dati del sito nel browser e accedi da zero |
| 403 Forbidden o 406 Not Acceptable | Hai effettuato l'accesso ma le regole di sicurezza del database (RLS) bloccano l'operazione | Controlla il tuo ruolo utente e le policy di sicurezza su quella tabella nella dashboard di Supabase |
| Violazione di chiave duplicata | Stai creando qualcosa con un nome o un indirizzo che esiste già — devono essere univoci | Usa un valore diverso, oppure aggiorna il record esistente invece di crearne uno nuovo |
| Cannot read property of undefined | Il codice viene eseguito prima che i dati arrivino dal database | Chiedi all'AI di aggiungere un controllo di caricamento prima di usare i dati |
| Module not found | Un refuso in un percorso di import, un file che non esiste o un pacchetto mai installato | Controlla l'esatta ortografia e le maiuscole del percorso; esegui il comando di installazione; riavvia il server di sviluppo |
| Build non riuscita al deploy | Errori di tipo ignorati in locale, oppure impostazioni (variabili d'ambiente) mancanti sulla piattaforma di hosting | Esegui prima la build sulla tua macchina per vedere l'errore vero; copia ogni variabile d'ambiente nella dashboard dell'hosting |
| Deploy fatto, ma il sito mostra la versione vecchia | Il tuo browser o la CDN servono una copia in cache del vecchio sito | Aggiornamento forzato (Cmd + Shift + R); prova in una finestra privata; rifai il deploy svuotando la cache |
| Codice cambiato, non succede nulla | Il server di sviluppo non è in esecuzione, il file non è stato salvato o hai modificato il file sbagliato | Controlla che il terminale stia eseguendo il server, salva il file, fai un aggiornamento forzato — poi conferma di aver modificato il file a cui l'errore punta davvero |
Tre problemi che in realtà sono uno solo
Guarda di nuovo le righe due, tre e quattro. "Dati che non compaiono", "401" e "403" sembrano tre disastri diversi, ma sono una famiglia: identità e permessi. Il database pone sempre le stesse tre domande — chi sei, a quale account appartieni e sei autorizzato a farlo? Quando una risposta è sbagliata, ottieni uno di quei tre sintomi.
Quindi fai il debug in quest'ordine. Primo: sono davvero connesso? Secondo: questi dati sono nel mio account, o li ho creati con un'altra email? Terzo: la policy di sicurezza su questa tabella consente al mio ruolo di farlo? Nove volte su dieci non arrivi mai alla terza domanda.
Funziona sulla tua macchina, si rompe in produzione
Lo scenario più demoralizzante merita una sezione tutta sua: in locale funziona tutto, fai il deploy e il sito online è rotto. Nulla è "andato storto" — locale e produzione sono semplicemente ambienti diversi. Impostazioni diverse, database diverso, modalità di build diversa. La checklist:
- Prima le variabili d'ambiente. Ogni impostazione che il tuo codice legge deve esistere nella dashboard della piattaforma di hosting, non solo sulla tua macchina. È la causa più spesso di tutte le altre messe insieme.
- Controlla a quale database stai puntando. La tua app online deve usare l'indirizzo del database di produzione, non uno di sviluppo.
- Leggi i log del deploy. La tua piattaforma di hosting registra errori che sulla tua macchina non compaiono mai.
- Fai la build in locale come in produzione. Esegui sulla tua macchina il comando di build di produzione — se fallisce lì, hai trovato il tuo bug senza un altro ciclo di deploy.
Il prompt che ti sblocca
Quando la tabella non basta, affida il problema all'AI come si deve. Suppliche vaghe producono ipotesi vaghe — e un'AI che tira a indovinare può peggiorare le cose, come ho mostrato in come l'AI sabota il tuo codice. Il prompt per sbloccarsi ha quattro parti:
Sono bloccato su [cosa stavi cercando di fare]. Cosa mi aspettavo: [risultato atteso]. Cosa succede davvero: [sintomo esatto]. Messaggio di errore completo: [incollalo, con file e riga]. Cosa ho già provato: [il tuo elenco]. Diagnostica la causa più probabile prima di proporre una soluzione.
Quell'ultima frase conta. Costringere a una diagnosi prima di tutto impedisce all'AI di sparare soluzioni a caso sul tuo codice — l'equivalente nel debug di un medico che prescrive prima di visitare. E un'abitudine evita che accada a te la metà di questo articolo: fai il commit del codice funzionante prima di ogni esperimento, così "andava tutto bene e ora è rotto" ha sempre una via d'uscita con un solo comando.
Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →Domande frequenti
Cosa devo fare per prima cosa ogni volta che sono bloccato?
Apri la console del browser e leggi l'errore vero — ecco come leggere qualsiasi errore in 30 secondi. Poi controlla il terminale in cui gira il tuo server di sviluppo. Tra questi due posti, la vera causa è quasi sempre già scritta per te; la capacità sta nel guardare prima di tirare a indovinare.
Ieri andava tutto bene e non ho cambiato nulla. Cos'è successo?
Qualcosa è cambiato — solo che non te ne sei accorto. I soliti sospetti: hai scaricato nuovo codice senza aggiornare le dipendenze o il database, un merge è andato storto o un file è stato annullato per sbaglio. Chiedi al tuo controllo di versione cosa è cambiato dall'ultimo stato funzionante e ripristina da lì. Per questo fare commit spesso del codice funzionante è l'assicurazione più economica del software.
Quando devo smettere di fare debug e chiedere aiuto all'AI?
Dopo un passaggio sistematico: console letta, sintomo confrontato con gli scenari comuni, una soluzione provata. Se non risolve, incolla il contesto completo — errore, aspettativa, cosa hai provato — usando il prompt per sbloccarsi qui sopra. Venti minuti di tentativi ostinati da solo valgono meno di due minuti di richiesta ben preparata.
Questi problemi sono un segno che non dovrei costruire senza uno sviluppatore?
No — ogni sviluppatore al mondo incappa in questi scenari esatti; li ha solo visti abbastanza volte da riconoscere gli schemi. Quel riconoscimento si impara in settimane, non in anni. Le dieci righe qui sopra sono la maggior parte di ciò che significa "anni di esperienza" nel debug di tutti i giorni.
Quanto sei intrappolato, davvero?
Fai l'Indice di Soffocamento Aziendale, la valutazione gratuita per capire se sei pronto a diventare solopreneur.