Dentro la promessa caotica dello sviluppo guidato dalle sensazioni

Se ultimamente hai passato del tempo a dare un’occhiata furtiva a 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" è quando gli sviluppatori (e anche i non sviluppatori, diciamocelo) usano istruzioni per l’IA e "sensazioni" intuitive per creare codice, invece dei tradizionali e meticolosi metodi riga per riga.

Sembra 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. 

Perché lasciarsi andare alla programmazione a sensazione

Il rapido successo dei progetti creati con la programmazione a sensazione, come quello del non sviluppatore che ha realizzato e lanciato con profitto un’app generata dall’IA con 100.000 righe di codice nel giro di poche settimane, oppure Workcade, un’app di produttività con lista di attività e meccaniche di gioco che ha raccolto centinaia di utenti nella prima settimana, suggerisce che dietro tutto questo clamore potrebbe esserci qualcosa di concreto.

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

Solo brutte sensazioni

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 iniziando rapidamente a guadagnare.

È il fondatore di Enrichlead, uno strumento che raccoglie indirizzi IP e usa un LLM per generare contatti commerciali. Leo ha costruito l’intera app usando Cursor, dichiarando con orgoglio: “Zero codice scritto a mano. L’IA non è più soltanto un’assistente: è la costruttrice. Puoi lamentartene oppure iniziare a costruire.”

Naturalmente, internet ha scelto la violenza.

Nel giro di 48 ore, gli hacker si sono riversati sul progetto. 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 strane.” E poi la ciliegina sulla torta: “Non sono un tecnico, quindi mi ci sta volendo più tempo del solito per capire cosa sta succedendo.”

Per usare Enrichlead, gli utenti installano uno snippet JavaScript che raccoglie gli indirizzi IP. L’LLM cerca di trasformarli in contatti commerciali. Raramente ha abbastanza informazioni su cui lavorare, quindi se le inventa. Leo, sempre ottimista, insiste: “Però funziona.”

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

Quindi ecco la domanda per i CTO moderni: la programmazione a sensazione è una scorciatoia innovativa oppure stiamo semplicemente manifestando bug con una UX migliore?

Analizziamo quando lasciarsi guidare dalle sensazioni e quando evitarle.

Qual è il pettegolezzo del momento?

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 Gists, discussioni su Reddit, conversazioni su Slack, commenti su Hacker News: tutto ciò che serve. I grandi ingegneri non memorizzano: risolvono. Cercano, riconoscono schemi, si adattano e costruiscono. Le istruzioni sono semplicemente la prossima evoluzione di qualcosa che è sempre esistito."

La sua posizione non è priva di fondamento. 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 la monotonia del lavoro, 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 già sei. 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 breve, nella sua forma migliore, la programmazione a sensazione permette ai team competenti di creare rapidamente prototipi, innovare e fornire valore più velocemente. Da questa prospettiva, l’IA sta semplicemente portando al massimo una pratica già consolidata.

Aspetta, le sensazioni potrebbero essere sbagliate

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

Come sottolinea con attenzione Slalom il direttore Adam D’Angelo, la programmazione a sensazione non è priva di svantaggi significativi. Evidenzia rischi concreti e pragmatici che i CTO devono considerare:

"Le vulnerabilità di sicurezza sono una preoccupazione primaria. Gli LLM potrebbero generare inavvertitamente codice vulnerabile ad attacchi di iniezione, scripting tra siti (XSS) e difetti di autenticazione."

D’Angelo sottolinea ulteriori problemi, tra cui quelli di "manutenibilità" dovuti a standard di codifica incoerenti, l’"accumulo di debito tecnico" e le complesse "difficoltà di audit", soprattutto in settori altamente regolamentati come quello sanitario o finanziario.

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

"Gli LLM potrebbero 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 autonomamente i problemi, portando a quella che D’Angelo definisce appropriatamente "impotenza appresa".

Accidenti. Improvvisamente, la programmazione d'istinto non sembra più così spensierata.

Stiamo ignorando il "debito d'istinto"?

Nonostante il suo fascino intuitivo, la programmazione d'istinto comporta rischi concreti. Tra i principali ci sono il debito tecnico e la complessità nascosta che emergono una volta svanite le iniziali "buone vibrazioni". Le fasi intermedie dei progetti software richiedono un'architettura meticolosa e un'analisi rigorosa, ambiti in cui la programmazione d'istinto spesso non è all'altezza.

Mi sono fatto davvero una bella risata quando Josh Wymer ha messo abilmente in luce questi punti ciechi in un post virale su LinkedIn che prendeva in giro un annuncio di lavoro eccessivamente "istintivo", alla ricerca di sviluppatori con lauree avanzate in "Prevenzione retroattiva dei problemi" ed esperienza nell'"allineamento energetico".

La satira di Wymer mette in luce con ironia il fatto che l'innovazione non consiste solo in buone intenzioni: richiede esecuzione, responsabilità e disciplina. Se affidi la tua intera strategia di prodotto esclusivamente all'istinto, ti stai preparando a sessioni di correzione degli errori piuttosto dolorose.

Quindi, cosa dovrebbe fare un CTO curioso della programmazione d'istinto?

Per i CTO che si occupano di IA, evoluzione dell'infrastruttura e crescenti pressioni da parte dei vertici aziendali, il dibattito sulla "programmazione d'istinto" si riduce a una domanda: la programmazione intuitiva può convivere con un'ingegneria disciplinata?

Sì… se definisci strategicamente dove può inserirsi nella tua organizzazione. Considera questa lista di controllo pratica:

• Innovazione e prototipazione iniziali: lasciati guidare dall'istinto. Gli strumenti di IA accelerano significativamente la creatività nelle fasi iniziali.
• Applicazioni critiche per la missione: aumenta il rigore. Affidati a revisioni rigorose e pratiche di programmazione strutturate.
• Scalabilità e sicurezza: rigore imprescindibile. L'istinto non risolverà le vulnerabilità di sicurezza né gli incubi legati alla scalabilità.

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

La "programmazione d'istinto" non è una soluzione miracolosa né una catastrofe annunciata. È un altro strumento nell'arsenale di un CTO. I leader tecnologici più accorti combinano strategicamente la programmazione intuitiva basata sull'IA con una solida disciplina ingegneristica, definendo chiaramente quando e dove la programmazione d'istinto è accettabile.

Come consiglia Beale, “Non denigrare la programmazione d'istinto: padroneggiala.” 

• Adottala strategicamente, non ciecamente. La programmazione d'istinto non è una scusa per abbandonare le buone pratiche. Come afferma Donaghy, la programmazione d'istinto 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 d'istinto per potenziare, non sostituire, le competenze ingegneristiche. Dai priorità alla formazione del team per mantenere la competenza tecnica ed evitare la trappola della dipendenza dall'IA.

Lasciati guidare dall'istinto responsabilmente

In definitiva, la programmazione d'istinto non è né un'apocalisse né una panacea. In qualità di CTO esperto, la scelta migliore è lasciarti guidare dall'istinto responsabilmente: sfrutta l'innovazione senza perdere il controllo strategico.

La responsabilità principale di un CTO è trasformare le buone vibrazioni in ottimo software. Quindi, procedi pure e lasciati guidare dall'istinto nella prossima sessione intensiva di innovazione (queste piattaforme per la programmazione d'istinto ti aiuteranno a iniziare), ma non avvicinarti troppo al sole.

Iscriviti alla newsletter di The CTO Club per altre opinioni incisive!