Introduzione
Nell'ultimo anno circa, ho iniziato a usare strumenti di AI come ChatGPT e GitHub Copilot per aiutarmi nelle mie attività di software engineering.
Per la maggior parte del tempo, questi strumenti sono stati di grande aiuto. GitHub Copilot mi ha aiutato ad automatizzare la generazione di codice boilerplate e a creare unit test.
ChatGPT è stato di grande aiuto nel brainstorming di idee, nella generazione di documentazione e persino nel debug di alcuni problemi complessi.
Ma finora ho scoperto che questi strumenti funzionano meglio come assistenti, velocizzando il mio lavoro, aiutandomi a essere più produttivo e permettendomi di trovare soluzioni migliori ai problemi, ma nulla che potesse cambiare profondamente il mio modo di lavorare.
Questo, fino a quando non ho provato Claude. E so che potresti pensare "l'ennesimo entusiasta dell'AI che cerca di venderti la prossima grande novità", ma ascoltami: sono sempre stato estremamente scettico riguardo all'hype sull'AI, ma non possiamo continuare a ignorare l'elefante nella stanza. L'AI è una realtà, e sta già cambiando il nostro modo di lavorare. Non è come quando un paio di anni fa volevano venderci il metaverso; quella cosa non è mai decollata.
Nell'ultima settimana ho usato Claude Max, e in una sola settimana il mio modo di lavorare è cambiato profondamente, così come la mia percezione del ruolo del Software Engineer nell'era dell'AI.
L'AI non è più solo un assistente; è una componente reale del processo di software engineering.
Ma voglio essere chiaro: questa non è una visione distopica del futuro, in cui l'AI sostituisce i Software Engineer. Al contrario, credo che l'AI cambierà semplicemente questo ruolo, con pro e contro che non possiamo ignorare.
Il ruolo del Software Engineer oggi
Prima di discutere come l'AI cambierà il ruolo del Software Engineer, voglio prendermi un momento per riflettere su cosa sia questo ruolo oggi.
Penso che il ruolo del Software Engineer oggi possa essere riassunto principalmente in due parti:
- Engineering: che significa progettare architetture e trovare soluzioni ai problemi.
- Coding: che significa scrivere codice, testarlo e debuggarlo.
Questo significa che attualmente il ruolo del Software Engineer è un mix di pensiero ad alto livello e implementazione a basso livello.
Ci sono molti ruoli ingegneristici in altri campi, come l'ingegneria civile o meccanica, dove il ruolo è principalmente focalizzato sul pensiero ad alto livello, con l'implementazione gestita dai tecnici.
Hai mai visto un ingegnere civile costruire un muro? No, perché non è il suo lavoro. Il suo lavoro è progettare il muro, trovare i materiali migliori e assicurarsi che sia sicuro e durevole. La costruzione vera e propria è fatta dagli operai edili.
Il ruolo in evoluzione del Software Engineer
Il Software Engineer 2.0
Con l'avvento di strumenti AI avanzati, che, come ho detto, esistono già oggi, credo che il ruolo del Software Engineer passerà da un mix di engineering e coding a principalmente engineering; questo è ciò che chiamo il Software Engineer 2.0.
Il cosiddetto Vibe coding semplicemente non funziona. L'engineering umano è ancora necessario per costruire sistemi complessi, e l'AI non è ancora capace di sostituire completamente la creatività umana e le capacità di problem-solving; forse non lo sarà mai.
L'ho visto con i miei occhi: sono riuscito a costruire cose esattamente come le volevo, fornendo un piano a Claude e facendogli generare il codice per me. E il codice, non importa quanto complesso, era quasi sempre scritto perfettamente, con un'eccellente copertura di test. Quando il codice non era perfetto, era facile per me guidare Claude nel migliorarlo.
Il fatto è che ho ottenuto gli stessi identici risultati che avrei ottenuto scrivendo tutto il codice da solo, ma in una frazione del tempo. Non mi sono sentito come se stessi "barando" o "prendendo scorciatoie"; mi sono sentito come se stessi usando uno strumento potente per aiutarmi a raggiungere i miei obiettivi più velocemente.
Mi sono sentito più un ingegnere, concentrandomi sul design ad alto livello e sull'architettura del sistema, mentre Claude gestiva i dettagli implementativi a basso livello.
Claude sarebbe in grado di scrivere lo stesso codice senza un ingegnere competente a guidarlo? Assolutamente no. Ha bisogno di un ingegnere umano che fornisca il contesto giusto, i requisiti e i vincoli per generare il codice.
Diventeremo semplicemente "prompt engineer"?
Questa è una preoccupazione valida, ma credo che il ruolo del Software Engineer 2.0 non riguardi solo lo scrivere prompt per strumenti AI. Riguarda comprendere il dominio del problema, progettare soluzioni e guidare l'AI nell'implementare quelle soluzioni efficacemente.
Dopotutto, al giorno d'oggi, i software engineer sono più considerati per la loro capacità di progettare sistemi e risolvere problemi che per le loro abilità di coding. Il coding è solo un mezzo per raggiungere un fine. E scrivere codice non ha nulla a che fare con l'architettura del codice stesso, che è ancora necessaria per costruire sistemi manutenibili e scalabili, anche con l'uso di strumenti AI. È solo la manifattura del codice che sta cambiando.
Quindi non avremo più bisogno di imparare a programmare?
Non esattamente. Credo che imparare a programmare sia ancora essenziale per i Software Engineer, anche nell'era dell'AI. Tuttavia, il focus dell'apprendimento potrebbe spostarsi dal padroneggiare specifici linguaggi di programmazione e framework alla comprensione dei concetti fondamentali di programmazione, algoritmi e strutture dati. Inoltre, penso che in alcuni casi ci sarà sempre un livello di coding richiesto per perfezionare e personalizzare il codice generato dall'AI per casi d'uso specifici.
In ogni caso, mi aspetto che nei prossimi anni la revisione del codice generato dall'AI diventi una competenza fondamentale per i Software Engineer.
Ma a me piace programmare
Questo è ciò che mi preoccupava di più quando ho iniziato a realizzare questo cambiamento. Amo programmare, e il pensiero di non programmare più era un po' inquietante.
Tuttavia, ho realizzato che questo cambiamento non significa che smetteremo di programmare del tutto. Possiamo ancora programmare quando vogliamo, per i nostri progetti personali o quando dobbiamo implementare qualcosa di molto specifico che gli strumenti AI non riescono ancora a gestire.
E i linguaggi di programmazione?
Da Rustacean, sono un po' preoccupato che i linguaggi di programmazione potrebbero, a un certo punto, essere "astratti" dagli strumenti AI, rendendoli meno rilevanti.
Tuttavia, credo ancora che parte dell'engineering sia scegliere gli strumenti giusti per il lavoro, e i linguaggi di programmazione rimangono una parte cruciale di questo.
Potremo ancora essere fan del nostro linguaggio di programmazione preferito? Questo potrebbe essere difficile da dire. Quello che penso, però, è che gli ingegneri avranno semplicemente strumenti diversi a disposizione per fare il loro lavoro, e forse assisteremo a talk entusiastici alle conferenze su questi framework piuttosto che sui linguaggi di programmazione.
Impatto sul mercato del lavoro
Vale la pena considerare come questo cambiamento impatterà il mercato del lavoro per i Software Engineer.
Dato che sto parlando di velocizzare il coding, si potrebbe sostenere che questo potrebbe portare a una riduzione della domanda di Software Engineer.
Ma credo che potrebbe non essere così. Penso infatti che quello che facciamo oggi è spesso fatto male, con molte inefficienze, scarsa documentazione, debito tecnico, copertura di test limitata, e così via. Non perché siamo scarsi, ma perché siamo umani con tempo limitato, spesso siamo pigri e facciamo errori.
Ridurre il tempo speso nel coding potrebbe portare a software di qualità superiore concentrandosi di più su design, architettura e testing.
Per la cronaca, ho creato un cookbook per la mia libreria dbms in 12 minuti, che mi avrebbe richiesto diverse ore per scriverlo da solo, e la qualità era eccellente.
O che dire della coverage? Raggiungere il 100% di copertura dei test è uno dei compiti più noiosi per un Software Engineer, perché spesso devi scrivere molti test per casi limite a cui potresti nemmeno pensare. Con gli strumenti AI, raggiungere un'alta copertura dei test potrebbe diventare molto più facile, portando a software più affidabile e manutenibile.
Quindi credo fermamente che la domanda di Software Engineer non diminuirà; invece, la qualità del software consegnato migliorerà significativamente.
La vittima della rivoluzione AI: il coder
Ogni rivoluzione tecnologica ha le sue vittime; per esempio, le piattaforme di streaming musicale hanno ucciso l'industria dei CD. L'AI nello sviluppo software probabilmente ucciderà il ruolo del "coder" come lo conosciamo oggi.
Non tutte le persone che programmano oggi sono Software Engineer; molte persone scrivono semplicemente codice per vivere senza comprendere profondamente i problemi che stanno risolvendo o i sistemi che stanno costruendo.
Sfortunatamente, queste persone potrebbero trovarsi senza lavoro man mano che gli strumenti AI diventano più diffusi nello sviluppo software.
Odio essere così negativo, ma queste persone non dovrebbero pensare che questo futuro sia lontano: sta già accadendo. Molti compiti di coding a basso livello sono già automatizzati dagli strumenti AI, e questa tendenza probabilmente continuerà.
Tuttavia, credo che non sia troppo tardi. Se pensi di non essere capace di ingegnerizzare sistemi software, puoi ancora imparare. Ci sono molte risorse disponibili online per aiutarti a migliorare le tue competenze e diventare un Software Engineer migliore.
Conclusione
In conclusione, il ruolo del Software Engineer sta cambiando rapidamente con l'avvento degli strumenti AI. Mentre il coding sarà ancora una parte rilevante del lavoro, il focus si sposterà maggiormente verso l'engineering e il design ad alto livello.
Questo cambiamento sta separando i ruoli di engineering e manifattura dal Software Engineer, portando all'emergere del Software Engineer 2.0.
Ovviamente, questa riflessione non tiene conto di molti altri fattori, come le possibili limitazioni degli strumenti AI o la sostenibilità dei modelli AI, dato che anche chi paga per questi servizi probabilmente non sta pagando il costo reale del loro funzionamento.