L’AI è il futuro dello sviluppo, ma non come immaginavo

Per i developer come me, il racconto che si fa dell’AI è spesso problematico. Dal lancio di ChatGPT in poi, l’AI viene troppo spesso raccontata con una piega che polarizza gli addetti ai lavori tra due estremi: da una parte c’è chi abbraccia in pieno la tendenza, delegando all’AI il più possibile, dall’altra chi proprio non ne vuole sapere.

Un tema divisivo

I developer tendono a essere gente concreta, che vuole sperimentare, provare con mano. La frenetica rincorsa agli annunci di nuovi traguardi epocali nel campo dell’AI tende a far guardare agli LLM (Large Language Models) con un certo scetticismo: non sarà tutto marketing? Perfino all’interno dello studio per cui lavoro, Moze, ci sono opinioni discordanti: c’è chi è più aperto alla sperimentazione e chi, all’opposto, non sembra interessato perché appassionato all’aspetto artigianale della scrittura del codice.

Io, fino a qualche mese fa, mi trovavo nel mezzo. Ero fermo a un’adozione che definirei curiosa ma prudente. Utilizzavo Copilot X (lo strumento di codifica AI generativa di GitHub) per compiti minori, di rifinitura: code review e documentazione del codice. Insomma, un’applicazione concreta e circoscritta, da co-pilota. Non mi ero spinto oltre.

Due cose hanno cambiato il mio punto di vista: un progetto lavorativo interamente in ambito AI e un progetto nato da un’esigenza personale. Lasciate che vi dica di più.

L’occasione giusta

La prima occasione è nata da un progetto in Moze, dove un cliente ci ha chiesto di sviluppare un chatbot avanzato.

Dopo una ricerca iniziale, abbiamo scelto l’approccio che ci sembrava più adatto: utilizziamo l’Assistant API di OpenAI, che permette di integrare un’intelligenza artificiale capace di comprendere e rispondere a input in linguaggio naturale e il progetto quick-start per Next.js – un framework basato su React, in cui siamo esperti – per sviluppare l’applicazione. Definiamo un contesto preciso e creiamo prompt efficaci, cioè frasi o domande mirate che guidano l’Assistant nelle risposte, fornendogli il dataset di cui ha bisogno per funzionare al meglio. Fatto.

Così facendo, il chatbot funzionava, ma con un grande limite: era estremamente inefficiente. Ogni sessione richiedeva una potenza computazionale eccessiva, espressa in consumo di token, cioè le unità di testo che l’AI elabora per generare una risposta. Maggiore è il numero di token richiesti, maggiore è il costo computazionale e monetario. In questo caso, i costi risultavano sproporzionati rispetto ai benefici.

Ci siamo chiesti: come ottimizzare i consumi? Chi meglio di un AI?

Abbiamo allora creato un sistema di 4 agenti, ovvero programmi autonomi che svolgono compiti specifici in modo indipendente, lavorando in successione:

1. il primo ottimizza e riduce le istruzioni, ridimensionando in partenza l’uso di token;
2. il secondo riorganizza le fonti dati su cui fare lavorare il modello;
3. il terzo prepara quel dataset nel modo migliore possibile per essere processato
4. il quarto controlla quanto il lavoro degli altri agenti sia in linea con le nostre finalità.

Grazie a questa ottimizzazione abbiamo ridotto il consumo di token di una percentuale davvero importante. Ma su questo punto non mi dilungo oltre, sia per ragioni di riservatezza su un progetto ancora in sviluppo, sia perché questo non è un articolo sull’ottimizzazione dei token.

Quello che voglio sottolineare, invece, è come siamo riusciti a risolvere il problema in un modo che inizialmente non avevamo considerato, proprio grazie all’AI.

L’AI rende più efficiente anche il cliente

Molti dei commenti sul tema dell’intelligenza artificiale si concentrano su quanto tempo e quante risorse si risparmiano (e su quante professioni, perciò, potrebbero diventare superflue nei prossimi anni).

Ma noi non abbiamo solo risparmiato tempo, abbiamo creato qualcosa di nuovo con strumenti che prima non esistevano e non erano così facilmente accessibili.

Qualche anno fa sarebbe stato molto più complicato — e probabilmente fuori dalla nostra portata — realizzare un progetto del genere. Gli strumenti emergenti stanno aprendo un mercato completamente nuovo, permettendo a un numero sempre maggiore di developer di creare applicazioni che prima non sarebbero stati in grado di realizzare.

Questo è il punto di svolta su cui vale la pena riflettere.

Come l’AI sta cambiando il mio lavoro

Anche il mio lavoro è cambiato. È come se avessi sbloccato un livello di astrazione professionale: Invece di limitarmi a eseguire task, ho osservato il progetto nella sua complessità, con uno sguardo strategico, facendomi aiutare dall’AI per colmare i gap.

Invece di agire da muratore, ho pensato da architetto. E ho messo a fuoco un passaggio che per me è un cambio di prospettiva: certo, l’AI mi libera di tanto lavoro inutile e mi rende veloce, ma di questo tempo guadagnato cosa me ne faccio?

L’AI offre l’opportunità di superare i confini del proprio ruolo, consentendo a un developer di risolvere problemi e ridurre la distanza tra diverse funzioni. È l’avvento del Product Engineer, come definito da Intercom e ripreso da Luca Rossi nel suo articolo su Refactoring, “How to Become a Product Engineer”.

Il Product Engineer prende piena responsabilità dei problemi del cliente, il che significa progettare una soluzione e gestire l’intero stack.

Questo approccio funziona molto bene in team dove la distanza tra cliente e IC (Individual Contributor) è ridotta. Ad esempio, in Moze non ci sono project manager: solo designer e developer. Lavoriamo a stretto contatto con il cliente, immersi nel progetto. In tutto questo ci sono grandi vantaggi e un solo rischio: a volte potresti perdere la visione generale.

Ma bisogna chiedersi: come l’AI può aiutarmi? Ad esempio, potrebbe permettermi di testare diversi approcci che ho in mente, valutandone vantaggi e criticità prima ancora di iniziare a svilupparli. In altre parole, ho guadagnato non solo potenza, ma anche tempo e spazio mentale, che si traducono in una qualità superiore nei progetti su cui lavoro.

L’AI come amplificatore di competenze

Un developer, dicevo prima, ama sperimentare, sporcarsi le mani. In questo senso, anche un problema alla domotica di casa può diventare una palestra di competenze.

Nel mio caso, dovevo risolvere i problemi di un sistema di riscaldamento a pavimento con una gestione cloud molto carente. Non riuscivo a controllarlo da Home Assistant, il centro della mia rete domotica. Ho trovato un modo per agire sul sistema grazie a un programma in Python che espone delle API REST utilizzando un WaveShare.

Ora, io sono un developer, ma non conosco Python. Così, ho dato tutta la codebase a un LLM e gli ho chiesto di spiegarmi le parti che non comprendevo. Lui lo ha fatto passo dopo passo, con esempi nei linguaggi che conosco.

Ho programmato e risolto il problema: ora controllo la temperatura in piena automazione. Ho usato l’occhio del developer esperto, ma applicato a linguaggi che non conosco. Non ho rinunciato al mio ruolo, delegando passivamente all’AI. Sono un developer e ho svolto il mio lavoro, gestendo con inventiva e spirito critico le soluzioni proposte dall’AI. Ma l’ho fatto in un campo che non è certamente il mio.

Con un po’ di perfezionamento, potrei affrontare sfide che finora ritenevo fuori dalla mia portata, poiché pensavo di non avere le competenze adeguate. Tutto questo mi porta a pensare che, in futuro, si ridurranno anche alcune distanze tra sviluppatori front-end e back-end, permettendo a ciascuno di comprendere meglio il lavoro dell’altro quando necessario.

Conclusione

Capisco che alcune innovazioni possano spaventare, o che l’eccesso di marketing ci porti a pensare che, dietro tanto fumo, ci sia poco arrosto. Nonostante ciò, il mio consiglio è di immergersi nell’AI con decisione, come ho fatto nei miei ultimi progetti.

Ho la sensazione che, se sei un developer e non provi entusiasmo per ciò che sta accadendo oggi nel campo dell’AI, ti stia perdendo qualcosa di importante. È un po’ come non essere stati entusiasti dei primi Macintosh negli anni ’80. Le nuove tecnologie non minacceranno il tuo lavoro, a patto che tu sappia abbracciare questa nuova era fin dall’inizio.

Se vi ricordate, c’è stato un tempo in cui persino il JavaScript, che oggi è comunemente usato da tutti i professionisti, veniva considerato un linguaggio per dilettanti, adatto solo ad animare pagine web. Allora Douglas Crockford ne aveva preso le parti con un libro che ha fatto storia: “JavaScript – The Good Parts”.

Ecco, senza sensazionalismi, ma con lucidità, io credo che anche l’AI abbia le sue “good parts”. Abbiamo il dovere di metterle alla prova.