L'idea sbagliata più diffusa è pensare che il muro contro cui si sbatte sia un problema di "bravura nel programmare". In realtà il problema è quasi sempre un altro: l'AI ha eliminato la barriera per scrivere codice, ma non quella per strutturarlo. Sono due abilità diverse, e finché il tuo progetto è piccolo la differenza non si vede — l'assistente tiene tutto in testa al posto tuo. Il problema emerge quando il progetto cresce abbastanza da avere bisogno di essere capito, non solo generato: se non sai dove sta cosa, ogni modifica diventa un rischio, perché non hai modo di prevedere cosa altro si romperà.
AI per lo sviluppo software
Costruisci con l'AI ma non sai nulla di architettura? Guida di sopravvivenza
Hai avuto un'idea, l'hai descritta a un assistente AI, e in pochi minuti avevi codice funzionante. Poi hai aggiunto una funzionalità, poi un'altra, e intorno alla quinta qualcosa ha iniziato a rompersi senza che tu riuscissi più a spiegare perché. Non è colpa tua, ed è un problema che si risolve senza una laurea in informatica.
Il problema vero non è il codice, è capirlo
Regola 1: separa cosa si vede, cosa succede, dove sono i dati
Lasciata libera, un'AI tende a scrivere tutto in un unico file: la parte che disegna lo schermo, quella che fa i calcoli, quella che parla con il database, tutto mescolato insieme. Funziona, all'inizio. Ma quando tutto è nello stesso posto, ogni modifica rischia di rompere tutto il resto, perché niente è davvero separato da niente.
La correzione è tenere distinte tre cose: cosa vede l'utente (interfaccia, pulsanti, layout), cosa fa davvero l'app (la logica, le regole, i calcoli) e da dove arrivano i dati (database o servizi esterni). Una singola istruzione, ripetuta con costanza, previene la maggior parte dei crolli:
"Tieni separati in file diversi: interfaccia, logica di business
e accesso ai dati. Non mescolarli insieme."
Regola 2: un compito per ogni cosa, descrivibile in una frase
Una regola semplice da tenere a mente: un file o una funzione dovrebbe fare una cosa sola, descrivibile in una singola frase. Se per spiegare cosa fa un file ti serve dire "fa questo, e anche quest'altro, e pure quest'altra cosa", quel file sta facendo troppo — e diventerà il posto dove i bug si nascondono e le modifiche vanno storte.
Pezzi piccoli e con un solo scopo si possono trovare, capire e modificare senza paura. File enormi che fanno di tutto sono sabbie mobili: più contengono, più ogni modifica rischia di far franare qualcos'altro. Quando chiedi all'AI una nuova funzionalità, chiedile esplicitamente di aggiungerla come pezzo nuovo e separato, non di infilarla dentro un file già esistente e già grande.
Regola 3: fatti spiegare cosa ha appena scritto
L'ultima abitudine è la più semplice da applicare e la più spesso saltata: dopo che l'AI ha scritto o modificato qualcosa, chiedile di spiegartelo in due o tre frasi, prima di accettare la modifica. Non per controllare il codice riga per riga — non serve saperlo fare — ma per verificare che la tua idea di cosa il progetto sta facendo resti allineata con quello che il progetto sta facendo davvero. Il momento in cui smetti di poter descrivere il tuo progetto a parole semplici è lo stesso momento in cui hai smesso di poterlo governare, anche se continua a funzionare.
Fonte e approfondimento: Building With AI When You Don't Know Architecture: A Survival Guide, su dev.to