Salvatore Mosaico · 2026
La collaborazione tra intelligenza artificiale e progettista: dal risultato corretto alla qualità del sistema.
Un’applicazione funziona: le pagine si aprono, i dati vengono salvati, i calcoli restituiscono i risultati attesi. Possiamo dire che il lavoro è finito?
Non necessariamente. Il funzionamento è indispensabile, ma non basta a descrivere la qualità di un software. Occorre chiedersi anche quanto sia comprensibile, modificabile e riutilizzabile. E soprattutto: dove sono state collocate le responsabilità?
Lo sviluppo con l’intelligenza artificiale rende questa domanda particolarmente importante. L’IA può realizzare rapidamente le funzionalità richieste, ma la successione di soluzioni corrette non garantisce, da sola, un’architettura coerente.
Indice
- 1. Una funzionalità alla volta nasce anche un progetto
- 2. Il confronto che ha fatto emergere il problema
- 3. Semplificare l’utilizzo, non negare la complessità
- 4. Un sistema non si comprende contando i suoi oggetti
- 5. Quando le specifiche vengono dal sistema
- 6. Con l’IA, documentare dopo significa anche verificare
- 7. Una pagina web che documenta il database
- 8. La collaborazione che produce qualità
- Conclusione
1. Una funzionalità alla volta nasce anche un progetto
Il lavoro con l’IA procede spesso per richieste successive:
«Aggiungi un gioco.»
«Ora rendilo multilingua.»
«Introduci le stanze per giocare a distanza.»
«Aggiungi la gestione amministrativa.»
«Prepara le statistiche.»
Ogni richiesta sembra riguardare una funzione. In realtà può comportare decisioni sulla struttura dei dati, sulle dipendenze e sulla distribuzione della logica.
L’IA, quindi, non sta soltanto scrivendo codice: sta partecipando alla progettazione, anche quando nessuno le ha chiesto esplicitamente di progettare l’intero sistema.
Il rischio è che ogni nuova esigenza venga affrontata come un problema locale, aggiungendo un’altra soluzione senza riesaminare sufficientemente quelle precedenti.
Non significa che l’IA generi inevitabilmente cattivo software. Significa che la qualità dipende anche dalla guida ricevuta, dal contesto disponibile e dalla revisione delle decisioni accumulate.
2. Il confronto che ha fatto emergere il problema
La discussione è nata confrontando due database.
Nel sito sviluppato insieme all’IA erano state individuate 36 tabelle, senza viste, procedure o trigger. Nel precedente progetto SPIAGGE erano presenti 10 tabelle, 59 viste e 2 trigger; questi richiamavano tre procedure, recuperate separatamente perché non incluse nel dump esaminato.
Non sono numeri con cui assegnare un voto. I progetti gestiscono esigenze differenti e una vista non sostituisce necessariamente una tabella.
Il confronto ha però fatto emergere una differenza architetturale: nel primo sistema molta logica risiedeva nel codice applicativo; nel secondo una parte consistente era organizzata nel database.
L’osservazione decisiva del progettista è stata:
Nel mio PHP non scrivo join. Interrogo le viste con SELECT, WHERE e ORDER BY.
Non era una rinuncia alle relazioni tra i dati. Era il risultato di averle già definite nel livello sottostante.
3. Semplificare l’utilizzo, non negare la complessità
Una pagina può avere bisogno di un preventivo completo di risorse, periodi, prezzi e sconti.
Se questi elementi vengono ricostruiti nel PHP, chi sviluppa la pagina deve conoscere le tabelle, i collegamenti e le formule. Se una vista li presenta già nella forma necessaria, il codice applicativo può limitarsi a richiedere il risultato.
La complessità non scompare: viene affrontata nel livello competente e resa riutilizzabile.
Chi mantiene quel livello deve conoscere bene il database. Chi realizza una pagina non deve necessariamente conoscere tutti i passaggi interni del calcolo.
Questo rende possibile anche una divisione del lavoro: il progettista definisce servizi e regole; lo sviluppatore applicativo li utilizza attraverso un’interfaccia più semplice.
Non significa che ogni operazione debba stare nel database. Significa che la sua collocazione deve essere una scelta consapevole, non la conseguenza occasionale dell’ultima richiesta.
4. Un sistema non si comprende contando i suoi oggetti
Il progettista racconta un’esperienza precedente: un sistema operativo da anni, con circa 120 tabelle e 1.200 viste. Due software house, coinvolte successivamente per sostituirlo, tentarono di rifare il sistema partendo dal database, senza riuscire a completare la sostituzione.
Questa testimonianza non dimostra, da sola, perché quei tentativi fallirono. Suggerisce però una domanda essenziale:
Prima di sostituire la struttura, erano stati compresi i servizi che offriva e le regole che incorporava?
Un grande numero di viste può rappresentare stratificazione inutile, ma può anche contenere una scomposizione del problema maturata negli anni. Per distinguerle occorre studiare definizioni, dipendenze e utilizzi.
Allo stesso tempo, un’architettura di qualità deve poter essere trasferita ad altre persone. Se le sue ragioni restano soltanto nella testa dell’autore, una parte importante del progetto rimane fragile.
Qui entra in gioco la documentazione.
5. Quando le specifiche vengono dal sistema
Circa trent’anni fa, il progettista aveva già visto applicare un processo di documentazione automatica: collegandosi a Oracle con le credenziali appropriate, uno strumento leggeva la struttura del database e, attraverso macro e un template Word, produceva un documento di circa 250 pagine, organizzato in capitoli e paragrafi. Nel suo ricordo, la generazione avveniva senza errori.
Il cambiamento non riguardava soltanto la velocità.
Nel processo tradizionale che descrive, il progettista consegnava un documento con le strutture dati e il programmatore del database le implementava. Documento e implementazione erano due rappresentazioni da mantenere allineate.
Nel nuovo processo, il progettista implementava direttamente la struttura e da questa veniva ricavata la documentazione.
Le specifiche, nella sua espressione, «venivano indietro»: descrivevano il sistema realizzato, invece di essere soltanto un’istruzione per costruirlo.
Questo non elimina la necessità di definire prima obiettivi, requisiti e vincoli. Evita però di trascrivere manualmente informazioni strutturali che il database conosce già.
6. Con l’IA, documentare dopo significa anche verificare
Nel nostro percorso il progetto è cresciuto attraverso funzionalità successive. La documentazione della struttura effettivamente realizzata deve quindi seguire l’implementazione.
A posteriori non significa necessariamente alla fine. Può significare dopo ogni modifica significativa.
La documentazione diventa così uno strumento per osservare ciò che l’IA ha contribuito a costruire:
- Quali strutture sono state aggiunte?
- Quali responsabilità sono state duplicate?
- Dove risiedono le regole?
- Quali componenti dipendono dagli stessi dati?
- Esistono servizi già disponibili che il nuovo codice non utilizza?
È quanto è accaduto in questa discussione: la documentazione del database ha reso visibile una differenza progettuale che il semplice funzionamento delle pagine non avrebbe evidenziato.
7. Una pagina web che documenta il database
L’evoluzione naturale è una pagina amministrativa che legga i metadati del database e produca un documento secondo un modello prestabilito.
Un capitolo per le tabelle, un paragrafo per ciascuna, una tabella con campi e tipi. Poi relazioni, viste, trigger e procedure, con indice ed esportazione in Word o PDF.
La fonte può essere un dump oppure una connessione eseguita sul server, protetta e dotata dei soli permessi necessari.
Occorre distinguere due attività:
Estrarre la struttura è un compito deterministico. Nomi, tipi e vincoli non devono essere inventati dall’IA.
Spiegarne il significato può beneficiare dell’IA. Una query complessa può essere descritta, una procedura riassunta, una dipendenza evidenziata. Le interpretazioni devono però restare distinguibili dai fatti estratti.
Inoltre, se la logica risiede nel PHP, documentare il database non basta a documentare l’applicazione: occorre analizzare anche il codice.
8. La collaborazione che produce qualità
Il collegamento con il metodo MOSAICO è diretto.
Nel passaggio da RandomNumero a RandomRange, il problema non era soltanto ottenere un numero nell’intervallo corretto. Era riconoscere una capacità già disponibile e utilizzarla senza riprodurne il meccanismo.
Lo stesso principio vale per una vista, una procedura o un servizio applicativo.
L’utilizzatore esperto non si limita a dire all’IA che cosa manca. Le indica anche quali responsabilità esistono già, quali interfacce devono essere rispettate e quali duplicazioni vanno evitate.
L’IA, a sua volta, può aiutare a rendere esplicite le alternative, ricostruire le dipendenze e verificare la coerenza delle nuove modifiche.
La collaborazione diventa quindi un ciclo: si chiarisce l’esigenza, si individua la responsabilità, si implementa, si verifica il risultato e si aggiorna la documentazione. Poi si riesamina l’insieme.
Conclusione
L’IA può accelerare enormemente la produzione del codice. Ma produrre più codice, più rapidamente, non equivale automaticamente a costruire un sistema migliore.
Il valore dell’esperienza sta anche nel riconoscere ciò che non deve essere riscritto, nel mantenere semplici le interfacce e nel rendere comprensibili le decisioni.
Se l’IA costruisce il progetto una funzionalità alla volta, la documentazione generata dal sistema permette al progettista di tornare a vedere e governare l’insieme.
È in questa collaborazione più stretta che si passa da un prodotto semplicemente funzionante a un prodotto di buona qualità: non chiedendo soltanto all’IA di aggiungere qualcosa, ma ragionando insieme su dove debba stare e su come debba integrarsi con ciò che esiste già.