La mia teoria del codice Frankenstein e come non l’ho risolta (ma questo è già un buon risultato)
di Salvatore Martino
C’è un’espressione che uso da tempo per descrivere un certo modo di costruire software: il codice Frankenstein. Con questa metafora indico un software fatto di pezzi cuciti insieme in momenti diversi…
Ho passato mesi a pensare che la colpa fosse del modo in cui lavoro con l’IA. Chiedo codice, ricevo codice, il codice fa metà di quello che voglio, chiedo una correzione, ne ricevo un’altra ancora, e dopo il quarto giro il progetto non assomiglia più a niente di quello che avevo in testa all’inizio. Cucito, appunto. Frankenstein.
Poi ho provato una cosa diversa. Ho iniziato a chiedere all’IA “come agirai” prima di chiederle “cosa mi costruisci”. L’ho raccontato in un altro articolo, quello sull’app per ascoltare le radio del mondo, e l’ho raccontato con entusiasmo, perché quella volta ha funzionato davvero: meno correzioni, meno rigenerazioni, un progetto che è arrivato quasi dritto invece di arrivare a zigzag.
Ho pensato di aver trovato la cura al codice Frankenstein. La teoria era semplice: se ragioni prima, il mostro non nasce.
Poi mi sono fermato di nuovo
E qui viene la parte che mi è più difficile scrivere, perché va contro l’entusiasmo di prima. Mi sono fermato a chiedermi: e se non fosse la cura? E se fosse stata solo fortuna, o un progetto abbastanza piccolo da non mettere alla prova davvero la teoria?
Non ho una risposta. L’ho scritto in un’altra riflessione, e lo ripeto qui perché è il cuore di questo articolo: non sono riuscito a dimostrare che il metodo funzioni sempre. Ho un solo caso a favore. Non ho un solo caso contro, ma solo perché non ho ancora provato abbastanza volte a farlo fallire.
Quindi la mia teoria del codice Frankenstein resta, in un certo senso, non risolta. Non so con certezza se “ragionare prima di scrivere codice” sia la soluzione definitiva al problema, o se sia solo un cerotto che ho messo su una ferita che si riapre comunque, in altre condizioni, con altri progetti, con altri modelli.
Perché considero questo un buon risultato
Qui arriva la parte che, se l’avessi scritta un anno fa, avrei considerato una sconfitta. Oggi non la vedo così.
Non risolvere del tutto la teoria significa che non ho smesso di guardarla con sospetto. Significa che continuo a chiedermi se il metodo che uso oggi sia davvero il migliore, o solo il migliore che ho provato finora. E questo, per chi lavora ogni giorno con strumenti che cambiano velocemente quanto cambiano le IA, è più prezioso di una certezza chiusa.
Le teorie chiuse sono comode. Ti dicono cosa fare e smetti di farti domande. Ma è proprio smettere di farsi domande il primo passo verso un nuovo codice Frankenstein, fatto questa volta non di pezzi di codice cuciti male, ma di convinzioni cucite male, prese in prestito da un’esperienza che magari non si ripeterà mai più uguale.
Cosa mi porto a casa, davvero
Non un metodo infallibile. Mi porto a casa un’abitudine: fermarmi, ogni tanto, a chiedere all’IA come pensa di procedere prima di chiederle cosa produrrà. E mi porto a casa anche il dubbio che questa abitudine, in altri contesti, potrebbe non servire a niente.
Tenere insieme queste due cose — l’abitudine e il dubbio — è, credo, l’unico modo onesto per lavorare con uno strumento che sta ancora imparando a ragionare quanto lo sto imparando io. Il codice Frankenstein, alla fine, non l’ho sconfitto. Ho solo imparato a riconoscerlo un po’ prima. E per ora, mi sembra un buon punto da cui ripartire.
Questo articolo fa parte di una serie di riflessioni pubblicate su OfflineMind sul rapporto tra ragionamento umano e intelligenza artificiale nella progettazione software. Non propone conclusioni definitive, ma un percorso ancora aperto.