Dentro la caotica promessa dello sviluppo guidato dalle sensazioni

Se ultimamente hai passato un po’ di tempo a curiosare su LinkedIn nel settore tecnologico, probabilmente ti sei imbattuto nel concetto sempre più rumoroso di "programmazione a sensazione". Per chi non lo conoscesse, la "programmazione a sensazione" consiste nel fatto che gli sviluppatori (e anche i non sviluppatori, diciamolo) usano istruzioni per l'IA e "sensazioni" intuitive per mettere insieme del codice, invece di seguire i tradizionali e meticolosi metodi riga per riga.

Sembra essere o l'ultimo miracolo della tecnologia o la moda più imbarazzante dai tempi in cui gli NFT hanno iniziato a comparire nelle biografie di LinkedIn. 

A favore del lasciarsi andare completamente

Il rapido successo di progetti creati con la programmazione a sensazione, come quello del non sviluppatore che ha creato e lanciato in modo redditizio un'applicazione generata dall'IA di 100K righe nel giro di poche settimane, o Workcade, un'app per la produttività e le attività da svolgere in stile videogioco con centinaia di utenti già nella prima settimana, suggerisce che dietro questo clamore potrebbe esserci qualcosa di concreto.

Ma dove ci sono sensazioni, c'è anche... caos.

Solo sensazioni negative

La programmazione a sensazione sembra avere un problema di sicurezza. Prendiamo il caso dell'imprenditore non tecnico Leo Jr., che ha cavalcato l'onda della programmazione a sensazione, costruendo e lanciando apertamente la sua app, e ha iniziato rapidamente a realizzare profitti.

È il fondatore di Enrichlead, uno strumento che raccoglie indirizzi IP e utilizza un LLM per generare contatti commerciali. Leo ha creato l'intera app usando Cursor, dichiarando con orgoglio: “Nessuna riga di codice scritta a mano. L'IA non è più soltanto un'assistente: è chi costruisce. Puoi lamentartene oppure puoi iniziare a costruire.”

Naturalmente, internet ha scelto la violenza.

Nel giro di 48 ore, gli hacker si sono scatenati. Gli abbonamenti sono stati aggirati. I costi sono schizzati alle stelle. L'LLM ha iniziato ad allucinare dati sui contatti commerciali dal nulla. Leo ha pubblicato un SOS su Twitter: “ragazzi, sono sotto attacco … stanno succedendo cose casuali.” E poi la frase decisiva: “Non sono tecnico, quindi mi ci vuole più tempo del solito per capire cosa sta succedendo.”

Per usare Enrichlead, gli utenti installano un frammento JavaScript che raccoglie gli indirizzi IP. L'LLM prova a trasformarli in contatti commerciali. Raramente ha abbastanza informazioni per riuscirci, quindi si limita a inventare. Leo, sempre ottimista, insiste: “Però funziona.”

Ora dice che sta imparando a programmare. “Nel modo più difficile,” naturalmente.

Quindi ecco la domanda per i CTO moderni: la programmazione a sensazione è una scorciatoia innovativa o stiamo semplicemente manifestando bug con un'esperienza utente migliore?

Analizziamo quando lasciarsi guidare dalle sensazioni e quando invece evitarle.

Quali sono le ultime novità?

David Beale, veterano del DevOps, non nasconde il suo entusiasmo per questa tendenza. Come sostiene, facciamo "programmazione a sensazione" da anni:

"Copiare e incollare da Stack Overflow, GitHub Gist, discussioni su Reddit, conversazioni su Slack, commenti su Hacker News: tutto ciò che serve. I grandi ingegneri non imparano a memoria: risolvono i problemi. Cercano, riconoscono schemi, si adattano e costruiscono. L'istruzione è semplicemente la prossima evoluzione di qualcosa che è sempre esistito."

La sua posizione non è priva di merito. La programmazione a sensazione basata sull'IA potrebbe davvero diventare un acceleratore essenziale nella cassetta degli attrezzi di un CTO. Il codice generato dall'IA potrebbe ridurre il lavoro monotono, lasciando agli sviluppatori più tempo per attività strategiche e ad alto valore.

Steven Donaghy, responsabile dell'ingegneria presso Microsoft, si spinge oltre:

"L'IA è come l'alcol. Amplifica ciò che sei già. Se sei un ottimo programmatore, ti rende ancora più bravo. Se sei pessimo, il risultato è ancora peggiore."

Per Donaghy, la programmazione a sensazione dà il meglio di sé in due momenti cruciali: all'inizio e alla fine dei progetti. Nelle fasi iniziali, l'IA aiuta a superare la paralisi da analisi. Alla fine, eccelle nello sfruttare esempi perfezionati per accelerare il nuovo lavoro.

In sintesi, nella sua forma migliore, la programmazione a sensazione consente ai team competenti di creare rapidamente prototipi, innovare e fornire valore più velocemente. Da questa prospettiva, l'IA non fa altro che potenziare una pratica già consolidata.

Ma aspetta, le sensazioni potrebbero essere sbagliate

Prima di raccogliere i cristalli e iniziare a manifestare funzionalità dal nulla, fermati.

Come osserva saggiamente il direttore di Slalom Adam D’Angelo, la programmazione a sensazione non è priva di svantaggi significativi. Sottolinea rischi concreti e pragmatici che i CTO devono tenere in considerazione:

"Le vulnerabilità di sicurezza sono una preoccupazione primaria. Gli LLM possono generare inavvertitamente codice soggetto ad attacchi di inserimento, scripting tra siti (XSS) e vulnerabilità di autenticazione."

D’Angelo evidenzia ulteriori grattacapi, tra cui problemi di "manutenibilità" dovuti a standard di programmazione incoerenti, "accumulo di debito tecnico" e complesse "difficoltà di verifica", soprattutto in settori fortemente regolamentati come quello sanitario o finanziario.

Avverte inoltre delle possibili gravi implicazioni legali e di conformità:

"Gli LLM possono generare codice che incorpora librerie a codice sorgente aperto con licenze incompatibili... le organizzazioni devono garantire la conformità alle normative specifiche del settore."

Inoltre, un'eccessiva dipendenza potrebbe ostacolare la capacità del tuo team di comprendere e risolvere i problemi in modo autonomo, portando a quella che D’Angelo definisce appropriatamente «impotenza appresa».

Accidenti. Improvvisamente, la programmazione a intuito non sembra più così fantasiosa.

Stiamo ignorando il «debito dell'intuito»?

Nonostante il suo fascino intuitivo, la programmazione a intuito comporta rischi concreti. Tra i principali vi sono il debito tecnico e la complessità nascosta che emergono quando le «buone sensazioni» iniziali svaniscono. Le fasi intermedie dei progetti software richiedono un'architettura meticolosa e un'analisi rigorosa, ambiti in cui la programmazione a intuito spesso non è all'altezza.

Ho davvero riso quando Josh Wymer ha messo abilmente in evidenza questi punti ciechi in un post virale su LinkedIn che prendeva in giro un annuncio di lavoro eccessivamente «basato sulle sensazioni», alla ricerca di sviluppatori con titoli di studio avanzati in «Prevenzione retroattiva dei problemi» e competenze nell'«allineamento energetico».

La satira di Wymer ironizza sul fatto che l'innovazione non consiste solo in buone intenzioni: richiede esecuzione, responsabilità e disciplina. Se affidi l'intera tua strategia di prodotto alle sole sensazioni, ti stai preparando ad affrontare sessioni di debug piuttosto dolorose.

Quindi, cosa dovrebbe fare un CTO curioso della programmazione a intuito?

Per i CTO alle prese con l'IA, l'evoluzione dell'infrastruttura e una crescente pressione da parte dei vertici aziendali, il dibattito sulla «programmazione a intuito» si riduce a una domanda: la programmazione intuitiva può coesistere con un'ingegneria disciplinata?

Sì… se definisci strategicamente il ruolo che può ricoprire nella tua organizzazione. Considera questa lista di controllo pratica:

• Innovazione iniziale e prototipazione: lasciati guidare dall'intuito. Gli strumenti di programmazione basati sull'IA accelerano notevolmente la creatività nelle fasi iniziali.
• Applicazioni critiche: aumenta il rigore. Affidati a revisioni rigorose e a pratiche di programmazione strutturate.
• Scalabilità e sicurezza: rigore non negoziabile. Le sensazioni non risolveranno le vulnerabilità di sicurezza né gli incubi legati alla scalabilità.

Indicazioni pratiche (che non si basano solo sulle buone sensazioni)

La «programmazione a intuito» non è né una soluzione miracolosa né un disastro annunciato. È un altro strumento nell'arsenale di un CTO. I leader tecnologici più capaci combinano strategicamente la programmazione intuitiva basata sull'IA con una solida disciplina ingegneristica, definendo chiaramente quando e dove la programmazione a intuito è accettabile.

Come consiglia Beale, «Non denigrare la programmazione a intuito: imparala alla perfezione.» 

• Adottala strategicamente, non ciecamente. La programmazione a intuito non è una scusa per abbandonare le buone pratiche. Come afferma Donaghy, la programmazione a intuito amplifica le competenze esistenti.
  
• Stabilisci paletti chiari. Segui le indicazioni di D’Angelo e definisci revisioni rigorose della sicurezza, strutture di audit e protocolli per la qualità del codice generato dall'IA.
  
• Usa la programmazione a intuito per potenziare, non sostituire, le capacità ingegneristiche. Dai priorità alla formazione del team per mantenere la competenza tecnica ed evitare la trappola della dipendenza dall'IA.

Programma con responsabilità

In definitiva, la programmazione a intuito non è un'apocalisse, né una panacea. In quanto CTO esperto, la scelta migliore è programmare con responsabilità: sfrutta l'innovazione senza perdere il controllo strategico.

La responsabilità principale di un CTO è trasformare le buone sensazioni in ottimo software. Quindi, sentiti libero di usare la programmazione a intuito nel prossimo sprint di innovazione (queste piattaforme per la programmazione a intuito ti aiuteranno a iniziare), ma non avvicinarti troppo al sole.

Iscriviti alla newsletter di The CTO Club per altre opinioni senza mezzi termini!