Ho smesso di chiedere codice all’IA. E ho iniziato a chiederle di pensare.

Qualche settimana fa mi sono seduto davanti a una chat con l’ennesima idea per la testa: volevo un modo semplice per ascoltare le radio migliori del mondo, senza dover aprire dieci app diverse o passare dieci minuti a cercare quella giusta. Un progetto piccolo, se vogliamo. Uno di quelli che di solito liquidi in un pomeriggio. Ho fatto quello che faccio sempre, in teoria: ho aperto la chat e stavo per scrivere “creami un player radio in HTML e JavaScript”. Poi mi sono fermato.Non per un’intuizione geniale. Per stanchezza, se devo essere onesto. Ero stanco del solito copione: chiedo codice, ricevo codice, il codice fa metà di quello che voglio, chiedo correzioni, ricevo altro codice, e dopo tre o quattro giri mi ritrovo con qualcosa che funziona ma che non assomiglia più a niente. Un frankenstein di patch.

Così ho scritto una cosa diversa. Ho scritto: “Come agirai?”

Non “fammi un player”. Non “usa React o vanilla JS”. Solo: come pensi di procedere.

La domanda che ha cambiato tutto

Non mi aspettavo niente di speciale da quella domanda. Volevo solo vedere cosa sarebbe successo se, per una volta, non fossi stato io a dettare i passaggi tecnici da zero.Quello che è successo è che l’IA non ha prodotto una riga di codice. Ha iniziato a farmi domande. Cosa intendevo per “migliori radio del mondo”. Se pensavo a un elenco fisso o a qualcosa che si aggiornasse. Se l’utente doveva cercare o doveva scoprire. Se contava di più la velocità o la qualità della selezione. Sulle prime mi ha quasi infastidito. Volevo un player, non un colloquio. Ma ho risposto lo stesso, tanto per vedere dove si andava a parare. E lì ho capito una cosa che, detta oggi, sembra banale, ma che vissuta dal vivo non lo è affatto: io non avevo ancora chiaro cosa stessi davvero costruendo. Avevo in testa un bisogno — ascoltare buona musica da tutto il mondo senza sbattimenti — ma quel bisogno non aveva ancora una forma. “Player radio” era solo l’etichetta più comoda che avevo trovato per descriverlo, non il progetto vero.

Da “player” a “motore di selezione”

A un certo punto della conversazione l’IA ha detto una frase che mi ha fatto fermare a pensare. Ha detto, più o meno: forse non stiamo costruendo un player. Stiamo costruendo un motore che sceglie le radio giuste.

È un dettaglio che sembra di poco conto, ma cambia tutto quello che viene dopo. Un player è un’interfaccia con dei bottoni. Un motore di selezione è un sistema che deve capire cosa proporre, in che ordine, con quali criteri. Sono due progetti diversi, anche se all’utente finale sembrano la stessa cosa: uno schermo con su scritto “play”.

Da lì in poi non ho più parlato di pulsanti. Ho parlato di criteri, di priorità, di cosa rende “buona” una radio agli occhi di chi ascolta. Ogni risposta che davo restringeva il campo. Ogni domanda che l’IA mi faceva eliminava una strada che, se avessi iniziato scrivendo codice, avrei probabilmente imboccato per inerzia, salvo poi tornare indietro tre giorni dopo.

Governare, non programmare

Mi sono reso conto, andando avanti, che il mio ruolo in quella conversazione non era più scrivere istruzioni tecniche. Era decidere. Chiarire. Tagliare le ambiguità che io stesso non sapevo di avere.

L’IA, dal canto suo, non stava più solo “generando”. Stava facendo l’analista quando c’era da capire il problema, l’architetto quando c’era da immaginare la struttura, il progettista quando c’era da definire i dettagli. Il codice, quando finalmente è arrivato, è stato l’ultima cosa, non la prima. Ed è arrivato quasi da solo, come conseguenza naturale di tutto quello che avevamo già deciso insieme.

Non fraintendetemi: non sto dicendo che il codice non conti. Conta eccome, è quello che poi funziona o non funziona sul serio. Ma ho iniziato a vederlo per quello che è davvero: la parte finale di un ragionamento, non il ragionamento stesso. Se quel ragionamento è zoppo, il codice sarà zoppo, non importa quanto sia scritto bene.

Meno rigenerazioni, più direzione

Il beneficio più concreto che ho notato, alla fine di quella sessione, è stato quanto poco ho dovuto rifare. Di solito i miei progetti con l’IA passano per cinque, sei versioni prima di assestarsi. Questa volta ci sono arrivato quasi diretto, perché le domande fatte prima avevano già chiuso le porte sbagliate.

Non voglio dire che sia sempre così, e non voglio nemmeno dire che questo metodo sia la soluzione universale. Se devo sistemare due righe di CSS, non mi metto certo a discutere di filosofia progettuale per venti minuti. Per quello, il “vecchio” modo va benissimo.

Ma per un progetto che nasce da un’idea vaga — “voglio ascoltare le radio migliori del mondo” non è una specifica tecnica, è un desiderio — fermarsi prima di scrivere, e lasciare che sia il ragionamento a guidare il codice invece del contrario, ha fatto la differenza. Non in astratto. L’ho visto succedere, riga dopo riga di conversazione, in tempo reale.

Cosa mi porto a casa

Non ho una teoria da vendere. Ho un’esperienza che voglio raccontare così com’è stata, senza ingigantirla e senza sminuirla.

Quello che ho imparato è che a volte la domanda giusta da fare a un’IA non è “cosa mi costruisci”, ma “come pensi di procedere”. E che vale la pena avere la pazienza di rispondere alle sue domande, invece di saltarle per arrivare prima al codice. Perché il codice, quello arriva sempre. La parte difficile — e quella che davvero conta — è tutto quello che succede prima.

Questo articolo racconta un’esperienza personale maturata durante lo sviluppo di un progetto reale nell’ambito di OfflineMind. Non pretende di essere una regola valida per ogni situazione, ma un’osservazione che mi sento di condividere con chiunque lavori ogni giorno, come me, a stretto contatto con questi strumenti.

---

E se avessi torto?

Ho raccontato questa storia con un certo entusiasmo. Ho parlato di una domanda che cambia tutto, di un’IA che smette di scrivere codice e inizia a fare domande, di un progetto che converge invece di disperdersi. L’ho vissuta così, e non ho intenzione di rinnegarla.

Ma devo essere onesto fino in fondo, anche a costo di togliermi qualcosa da sotto i piedi.

Il dubbio che non mi sono tolto

C’è una versione di questa storia in cui non ho scoperto niente. In cui ho semplicemente parlato di più, prima di scrivere codice, e ho scambiato la quantità di conversazione per qualità del ragionamento. Un progetto piccolo come un player radio, per quanto lo si complichi, resta un progetto piccolo: forse sarebbe convenuto lo stesso, anche partendo dritto per dritto con il codice, e sistemando per strada.
Non ho un modo per esserne certo. Ho un solo caso. Un solo progetto, una sola sessione, un solo autore che è anche l’unico giudice di se stesso. Se avessi cronometrato le due strade — quella diretta e quella riflessiva — forse avrei scoperto che il tempo speso a “capire prima” è stato uguale, se non superiore, a quello che avrei speso correggendo dopo. Non lo so. Non l’ho misurato.

L’ipotesi opposta

C’è di più. È possibile che il metodo funzioni bene proprio nei casi in cui io, da persona, sono ancora incerto su cosa voglio — e che sia inutile, se non dannoso, nei casi in cui il problema è già chiaro in partenza. Se so esattamente cosa mi serve, fermarmi a discutere con l’IA di “come agirà” prima di ottenere una riga di codice potrebbe essere solo tempo perso, un rituale che dà l’illusione del rigore senza portare nessun beneficio reale.
Ed è anche possibile che questo tipo di conversazione, così densa di domande e risposte, funzioni bene con me perché io stesso sono abituato a pensare per struttura. Con un’altra persona, con un altro modo di ragionare, la stessa sequenza di domande potrebbe risultare frustrante, dispersiva, o semplicemente inutile. Non ho controprove. Ho solo la mia esperienza, e la mia esperienza non basta a fare una regola.

Perché lo scrivo comunque

Non lo scrivo per sminuire quello che ho raccontato prima. Lo scrivo perché penso che un metodo, per essere davvero utile, debba sopravvivere al dubbio di chi lo propone. Se avessi scritto solo la versione entusiasta, avrei raccontato una mezza verità: quella che mi conveniva raccontare.
La verità intera, per quanto meno soddisfacente, è questa: ho vissuto un’esperienza in cui fermarmi a ragionare prima di scrivere codice ha prodotto un risultato che percepisco come migliore. Non so se sia stato il metodo, il caso, o semplicemente il fatto di avere più tempo e meno fretta quel giorno. Non lo so, e non fingerò di saperlo solo per dare a questo articolo una conclusione più elegante.

Cosa resta, allora

Resta una domanda aperta, non una certezza chiusa. Resta il fatto che vale la pena, ogni tanto, chiedersi se il modo in cui si lavora con l’IA sia davvero il migliore possibile, o se sia solo quello a cui ci si è abituati per pigrizia. E resta, soprattutto, il sospetto — sano, credo — che ogni metodo che sembra funzionare vada messo alla prova più di una volta, prima di essere chiamato tale.
Chi legge questo articolo dopo l’altro, quello entusiasta, avrà probabilmente la sensazione che mi stia contraddicendo. In parte è vero. Ma penso che raccontare un’esperienza senza raccontare anche i suoi limiti sia disonesto quanto non raccontarla affatto.

Questa riflessione chiude, per ora, il racconto di un’esperienza personale nell’ambito di OfflineMind. Non è una conclusione, ma un invito a continuare a interrogarsi — cosa che, in fondo, è proprio quello che il metodo descritto chiedeva di fare fin dall’inizio.