L'AI non ti salva se non capisci cosa c'è sotto

Esiste una narrativa comoda che circola da qualche anno nei corsi online, nei thread LinkedIn e nelle presentazioni aziendali: impara a usare l'AI e puoi fare tutto. Scrivere codice senza sapere programmare. Progettare sistemi senza capire l'architettura. Gestire dati senza conoscere i database.

È una bugia. Una bugia gentile, venduta con buone intenzioni o con secondi fini commerciali, ma pur sempre una bugia.

🎚️​​ L'AI è un moltiplicatore, non un punto di partenza

Un moltiplicatore amplifica quello che hai. Se hai competenze solide, l'AI le rende più veloci, più potenti, più produttive. Se non hai competenze, l'AI amplifica il vuoto, e il vuoto, amplificato, produce danni proporzionali.

GPT-4, Claude, Gemini: sono strumenti straordinari per chi sa già cosa sta facendo. Sanno generare codice SQL, suggerire pattern architetturali, ottimizzare query, proporre strutture dati. Ma non sanno, e non possono sapere, se quello che producono è giusto per il tuo contesto specifico. Questo lo devi sapere tu.

Se non sai cos'è un indice su un database, non puoi valutare se la query che l'AI ti ha scritto scaverà una fossa nella tua produzione. Se non capisci come funziona la memoria di un sistema, non puoi capire perché il tuo modello va in timeout sotto carico. Se non hai mai ragionato su latenza e throughput, non puoi progettare un sistema che regge.

L'AI non sostituisce la comprensione. La presuppone.

🙅‍♂️​ Diffida da chi ti dice il contrario

Ci sono buone ragioni commerciali per convincerti che non hai bisogno di capire le cose sottostanti. Corsi più brevi, promesse più grandi, target di mercato più ampio. "Impara il prompting in 10 ore e costruisci applicazioni AI" è un titolo che vende. "Studia come funzionano i database, l'hardware e la programmazione, poi l'AI diventerà uno strumento potente nelle tue mani" è un titolo che non vende altrettanto bene, ma è quello onesto.

Il prompting è una skill reale. Sapere come parlare a un modello, come strutturare il contesto, come ottenere output utili, tutto questo ha valore. Ma è l'ultimo strato di una torta che ha bisogno di tutti gli strati sotto per reggersi.

Un buon prompt non sostituisce una buona architettura. Un buon output dell'AI non sostituisce la capacità di valutarlo. La velocità che l'AI ti dà non vale nulla se vai veloce nella direzione sbagliata.

🛠️ Hardware: perché devi sapere dove girano le cose

Quando parli di AI in produzione, parli di GPU, di VRAM, di banda di memoria, di inferenza su CPU versus acceleratori dedicati. Parli di quanto costa far girare un modello, di quanto spazio occupa, di quanto tempo ci mette a rispondere sotto carico.

Un modello da 70 miliardi di parametri non gira su un laptop. Un'inferenza su CPU è ordini di grandezza più lenta della stessa su GPU. La differenza tra un'architettura transformer ottimizzata per batch processing e una ottimizzata per latency real-time non è un dettaglio accademico, è la differenza tra un prodotto che funziona e uno che non scala.

Se stai costruendo qualcosa con l'AI, devi sapere almeno:

• dove gira il modello e cosa costa farglielo fare
• quale hardware limita le prestazioni e perché
• come cambia il comportamento del sistema sotto carico reale

Non devi diventare un ingegnere hardware. Devi capire abbastanza da non prendere decisioni cieche.

👨🏻‍💻​ Programmazione: il codice che l'AI scrive è tuo

L'AI scrive codice velocemente. A volte scrive codice buono. Spesso scrive codice che sembra buono ma ha problemi sottili: race condition, memory leak, gestione degli errori mancante, assunzioni implicite sul contesto che nel tuo sistema non reggono.

Chi valuta quel codice sei tu. E per valutarlo devi capirlo.

Non è sufficiente testare che "funziona" in sviluppo. Devi capire cosa fa, perché lo fa in quel modo, e cosa succede quando le assunzioni cambiano. Un collega umano che ti consegna codice che non capisci è già un problema. Un sistema automatico che genera migliaia di righe che non capisci è un problema moltiplicato per mille.

Il rischio non è teorico. Ci sono già casi documentati di sistemi andati in produzione con codice generato da AI che nessuno aveva davvero capito, con conseguenze che vanno dall'inefficienza grave alla perdita di dati. Il codice che l'AI scrive è tuo. La responsabilità è tua. Per prenderti quella responsabilità devi sapere leggere quello che ti viene consegnato.

​🗃️​ Database: dove vivono i dati, dove muoiono le performance

Quasi ogni sistema AI di produzione ha un database sotto. Spesso più di uno. E quasi ogni problema di performance in produzione ha le sue radici lì.

L'AI può scrivere query. Non può sapere se quella query su quella tabella con quel volume di dati e quella distribuzione di valori esploderà sotto carico. Non può sapere se manca un indice, se la cardinalità di una colonna rende un piano di esecuzione inefficiente, se una join tra due tabelle da milioni di righe è innocua in sviluppo e letale in produzione.

L'AI può suggerirti CQRS, read replica, denormalizzazione. Ma se non sai cosa significa consistenza eventuale, se non hai mai ragionato su come funziona una replica PostgreSQL sotto lag, se non capisci la differenza tra un modello di lettura ottimizzato e un modello normalizzato, non puoi valutare quale consiglio è giusto per il tuo caso. Puoi solo sperare di aver scelto bene.

La speranza non è un'architettura.

🤦‍♂️​ Il problema del "funziona sul mio laptop"

C'è uno schema ricorrente in chi impara a usare l'AI senza le basi sottostanti. Si costruisce qualcosa. Funziona. Si va in produzione. Si rompe.

Si rompe perché in locale il dataset era piccolo e in produzione è grande. Si rompe perché in locale c'era un solo utente e in produzione ce ne sono mille simultanei. Si rompe perché in locale la latenza era zero e in produzione c'è una rete reale con un'API esterna che va in timeout.

Questi non sono problemi di AI. Sono problemi di sistemi distribuiti, di scalabilità, di gestione degli errori, di infrastruttura. Problemi che esistevano prima dell'AI e che l'AI non ha risolto, li ha solo nascosti meglio durante la fase di sviluppo.

Chi capisce i sistemi sottostanti riconosce questi problemi prima che arrivino in produzione. Chi non li capisce li scopre quando l'alert alle tre di notte sveglia qualcuno.

​😯​​ Cosa fare, concretamente

Non si tratta di tornare all'università o di diventare esperti di ogni tecnologia prima di toccare un modello. Si tratta di costruire la comprensione in modo stratificato e onesto.

Capire come funziona la memoria e il calcolo a un livello sufficiente per ragionare sui costi e sui limiti. Saper leggere il codice che usi, anche se non lo scrivi da zero. Avere un modello mentale di come i dati si muovono nel sistema, dove si accumula la latenza, dove si nascondono i colli di bottiglia.

Non è conoscenza per la conoscenza. È conoscenza per poter prendere decisioni informate, scegliere lo strumento giusto, riconoscere quando qualcosa non va, capire perché un sistema si comporta in modo inatteso.

L'AI è lo strumento più potente che la maggior parte dei developer ha a disposizione oggi. Per usarlo bene, devi essere un developer. Non solo un utilizzatore.

Arkemis forma developer che capiscono i sistemi, non solo gli strumenti. Perché gli strumenti cambiano. La comprensione resta.

Entra nella nostra Community