L'AI non ti fa dormire meglio. Ogni layer in più lo paghi in produzione.
Integrare un modello non alleggerisce il sistema. Lo sposta. Dipendenze, output che non si ripetono uguali, superfici di errore che prima non c'erano. In Snowinch lo diciamo quando si valuta un'architettura: la complessità che non vedi in costruzione arriva dopo, quando gli utenti sono dentro e i dati sono loro.
Il malinteso comodo
Circola una storia: l'AI semplifica. Meno codice, meno logica scritta a mano. Descrivi, il modello fa.
È vero sul momento in cui monti qualcosa. Arrivi prima a un oggetto che risponde. Quello che non fa è semplificare l'insieme: componenti, stati, vendor, comportamenti che il prodotto deve gestire da acceso.
Confondere le due cose è da founder che misura il progresso in "si vede". Poi la notte arriva il conto.
Dove si paga
Il codice generato spesso "funziona nei casi che hai provato". Porta dietro assunzioni del training, strutture ragionevoli in generale, non necessariamente per il tuo perimetro. Il problema non è che sia sempre sbagliato. È che nessuno lo ha letto come si legge quello che hai scritto tu. Generato, provato in superficie, incollato. Tiene, finché non tiene, per un motivo che richiede di capire un file che nessuno ha capito.
Questo è debito sottile: non codice sporco, codice non compreso. Il costo esce quando devi cambiarlo sotto pressione, con qualcuno che aspetta.
Ogni integrazione tira dentro dipendenze che nello schema a scatole stanno pulite. Versione del modello, forma della risposta, latenza che non comandi. Contesto che fai entrare e che sposta l'output. In sviluppo i volumi sono bassi e le condizioni le scegli tu. In produzione emergono sotto carico, su input che non avevi messo nei test. Il debug è più lento di un sistema che, a parità di ingresso, fa sempre la stessa cosa. Qui non è così. Lo stesso prompt, un contesto diverso, un carico sul vendor: risposta diversa. In condizioni tranquille è rumore. Sotto stress è una fattura sbagliata, un permesso concesso, un testo mandato a un cliente.
Per un prodotto con utenti veri, ogni comportamento storto va investigato. Investigare un sistema che non si riproduce uguale costa attenzione. Quella attenzione, di notte, è sonno.
Anzi, usare AI per il boilerplate lo facciamo anche noi. Il problema è quando il layer diventa l'architetto: decide come si parlano i pezzi, tiene la logica di soldi o di accessi, e nel team nessuno ha una mappa.
C'è un momento preciso in cui il debito smette di essere una preoccupazione da retrospettiva. Il sistema si rompe in produzione. Devi capire perché, in fretta. La domanda non è "come funziona l'AI". È: questo input, questo output sbagliato, come lo correggo senza tirare giù il resto.
Se i layer sono chiusi, con ingresso e uscita detti, e l'uscita si verifica, quella domanda ha una strada. Se il modello ha deciso la forma del sistema e le assunzioni stanno in una chat vecchia, la strada è lunga. Costruire pensando solo al primo "funziona" è firmare quella notte in anticipo.
Su autenticazione, pagamenti e cancellazione dati preferisco il noioso e il deterministico. Costa in teatro: sembri meno "AI-native". Lo prendo. Quello che muove soldi e identità non è il posto in cui voglio un output che cambia idea.
Un aside vero, e specifico: mi è capitato di aprire un modulo di auth generato perché "tanto è standard". Standard lo era nello stile. Nelle assunzioni su sessione e logout no. A schermo, in ufficio, passava. Al primo utente vero che chiudeva il browser e rientrava, no. Non era un problema di modello linguistico. Era un file che nessuno aveva letto come se dovesse tenere i dati di qualcun altro.
Strumento, non architetto
Usare i modelli su task chiusi (una bozza che poi leggi, un processo con ingresso e uscita verificabili, un testo che passa da una persona) tiene il sistema comprensibile. Il debito cresce come in qualsiasi prodotto.
Delegare le decisioni di forma (come si connettono i pezzi, dove sta la regola di business, cosa succede se il vendor è giù) alza la velocità iniziale e abbassa la comprensione. Ogni modifica successiva è archeologia. Ogni estensione inizia da "aspetta, cos'ha già deciso questo posto".
Isola il layer. Il resto del prodotto non deve sapere cosa c'è dentro, solo cosa accetta e cosa deve rifiutare. Non toglie il non-determinismo. Lo tiene in un recinto.
Verifica l'uscita, non il ragionamento interno. I criteri li scrivi tu. Fuori dai criteri è un errore da gestire, non una sorpresa da ignorare.
Tieni un fallback sui percorsi che, se falliscono, ti svegliano: soldi, accessi, dati. Manuale, regola fissa, sistema più stupido. Non come piano eterno. Come rete per quando il modello non fa quello che avevi in testa.
Scrivi le assunzioni. Perché questo modello. Cosa ti aspetti in quali casi. Cosa fate quando l'uscita è storta. Dal codice non esce. Se cambia, si aggiorna. Altrimenti la notte successiva la passi a ricostruire una chat.
Notti quiete
Non basta validare un'idea, e non basta un prototipo che "usa l'AI". Serve roba in produzione che tenga utenti, dati, e ti faccia dormire. Ogni layer in più o è un recinto con un responsabile, o è un debito che chiamerà.
Se lo scope è "mettiamo un modello su tutto, poi vediamo", si dice di no. Se ti serve un referente su un perimetro che deve restare acceso, si può parlare. Se vuoi sentire che l'AI ha semplificato e che i problemi sono finiti, questa è la call sbagliata.
