Negli ultimi due decenni, i governi e altri soggetti hanno speso miliardi per insegnare alle persone a programmare. Si pensava che fosse una delle poche professioni al sicuro in un mondo in cambiamento, ma si è scoperto che scrivere e manipolare il codice è una delle attività per cui i modelli AI sono più adatti. Le aziende tecnologiche hanno licenziato oltre 1 milione di dipendenti negli ultimi anni, e Microsoft ha offerto 60.000 incentivi all’uscita solo la settimana scorsa. È un momento terrificante e del tutto disorientante per le persone del settore del software.

Circa un mese fa ho scritto un memo interno in cui ho dettagliato il percorso di adozione dell’AI che Proton deve seguire per restare competitiva e sicura, e cosa abbiamo finora trascurato come organizzazione e che dobbiamo correggere per rendere un successo questa transizione inevitabile. Non c’è dubbio che le organizzazioni che non si trasformano abbastanza rapidamente finiranno per deludere i propri team e chi si affida a loro.

Il memo aveva anche un altro scopo: convincere i miei colleghi che non siamo attori passivi di questo cambiamento, che l’azienda ha bisogno dei loro talenti e delle loro competenze per realizzarlo e che questa transizione offre opportunità a chi sceglie di prepararsi e di affrontarla.

Il memo non è un documento tecnico approfondito. Non entra nei dettagli di sicurezza, affidabilità o infrastruttura. Indica piuttosto la direzione di marcia per l’intero settore.

Il memo completo è disponibile di seguito.

Scarica il manifesto AI in PDF(nuova finestra)

AI @ Proton, manifesto di ingegneria

Non dovrebbe sorprendere nessuno in Proton, tantomeno nell’ingegneria, che l’ingegneria del software sia cambiata irreversibilmente quest’anno, se non prima. Gli LLM e gli strumenti associati hanno acquisito la capacità di scrivere codice al punto che un ingegnere senior di Proton mi ha detto pochi giorni fa, cito: “Nessuno scrive più codice in {business unit name}.” Come memorizzare i numeri di telefono nel XX secolo o andare a cavallo nel XIX, scrivere manualmente codice di qualità è una competenza fondamentale la cui epoca è finita.

Si tratta in generale di una cosa fantastica. Gran parte della scrittura di codice è stata ed è un lavoro noioso e dispendioso in termini di tempo, almeno in produzione e su larga scala. Documentazione e test sono entrambi elementi necessari che pochi amano fare e che storicamente sono stati spesso trascurati a scapito della comunicazione, dell’efficienza e dell’affidabilità. Il boilerplate è l’emblema della fatica dell’ingegneria del software, e potrebbe non essere mai più qualcosa di cui un essere umano debba preoccuparsi. I modelli possono ora consigliare e proporre architetture e progettazioni di sistemi che, pur essendo spesso imperfette, contribuiscono in modo significativo alla discussione, al processo decisionale e alla formazione.

Fuori da Proton, la rivoluzione dell’AI sta conquistando il mondo. Molto di questo è fuffa e superficialità, campagne cosmetiche fatte più per apparire innovativi che per esserlo davvero. Ma gran parte è molto reale, e gli investimenti che quelle aziende (compresi i nostri concorrenti) stanno facendo ora determineranno l’ambiente imprenditoriale in cui opereremo in futuro. Non si tratta di inseguire mode: qui stiamo restando indietro, ed è una minaccia esistenziale per il successo della missione stessa.

Allora perché, in Proton, non sembra che la rivoluzione sia arrivata? Perché la produttività non è aumentata drasticamente se tutti usano già gli LLM tutto il tempo? Credo che la questione si riduca a tre cose, che dovremo correggere tutte se vogliamo avere successo nella nuova era che è già qui oggi, non in arrivo.

La prima è un cambiamento nella cultura dell’ingegneria e nella mentalità degli ingegneri. Il tuo lavoro è cambiato radicalmente. Non consiste più nello scrivere codice, e gli LLM non sono qui per aiutarti a scrivere codice migliore più velocemente. Il tuo lavoro è aiutare l’LLM a scrivere codice migliore più velocemente. Ogni ingegnere è ora un team leader, un manager, e i tuoi riporti diretti sono i modelli e gli agenti che usi. Guidarli direttamente e correggerli quando sbagliano ne fanno parte, senza dubbio. Ma un team di due persone che hanno sempre programmato in coppia non sarebbe granché come team, e nemmeno un team in cui nessuno lavora quando il team leader è in riunione. L’AI deve poter lavorare in modo autonomo e continuo con sempre meno supervisione umana. Il tuo lavoro è identificare i problemi che l’LLM non riesce a risolvere da solo e aiutarlo non solo a risolverli questa volta, ma a essere in grado di risolverli meglio la prossima, non solo per te ma per tutti: file di contesto a livello di repository, competenze e prompt condivisi e l’abitudine ad assicurarsi che i fallimenti ripetuti diano avvio a un’indagine e a una correzione. Il tuo lavoro è spingere i limiti di ciò che l’LLM può fare autonomamente, intervenire per le cose che non può fare e pensare sempre a come migliorare lo status quo.

Questa non è la morte della competenza. L’LLM è veloce. Tu sei lento, ma porti con te una vita di esperienza, valutazioni e comprensione. Sei anche (si spera) molto meno incline alle allucinazioni e a farti ingannare da input errati o malevoli, e sei responsabile verso te stesso, i tuoi colleghi e Proton in un modo in cui un modello non potrà mai esserlo. Insieme potete fare molto di più e molto più rapidamente di quanto ciascuno possa fare da solo.

Non è nemmeno la morte delle buone pratiche di ingegneria. Manutenibilità e velocità sono migliori su basi di codice ben progettate. Documentazione e test restano cruciali. Detto questo, dobbiamo essere aperti al cambiamento delle buone pratiche man mano che costi e capacità cambiano. I test sono un buon esempio. La vecchia buona pratica dice che troppi test (in particolare i test end-to-end) sono un cattivo compromesso in un mondo in cui scrivere e mantenere i test è costoso. Se scrivere e mantenere i test diventa economico, anche il punto in cui tracciamo quella linea probabilmente cambierà.

La seconda ragione per cui non siamo riusciti a sfruttare appieno la rivoluzione dell’AI è che siamo rimasti quasi completamente bloccati alla fase 1: usare gli LLM per accelerare le attività nell’ambito dei flussi di lavoro esistenti. Ma scrivere codice non è l’unica parte del ciclo di vita dello sviluppo del software, e cosa succede quando elimini un collo di bottiglia? Un altro prende il suo posto. Forse è la velocità e la capacità della CI. Forse sono progettazione, approvazioni, specifiche e revisioni del codice (sì, dobbiamo e arriveremo a un punto in cui la maggior parte delle revisioni umane del codice finirà). Forse il flusso di lavoro non cambia molto, ma gli LLM ci consentono finalmente di investire nell’automazione che prima era troppo costosa. Se non guardiamo a tutti i nostri processi in modo olistico e non eliminiamo senza pietà i colli di bottiglia, non raggiungeremo il nostro pieno potenziale. Spesso eliminare questi colli di bottiglia non comporterà solo l’ottimizzazione di parti dei nostri flussi di lavoro esistenti, ma la loro rielaborazione e ripensamento complessivo. Questa è la fase 2, e dobbiamo arrivarci ora.

La terza ragione è un problema di azione collettiva. Usare efficacemente gli LLM per scrivere codice è qualcosa che un singolo ingegnere può fare per conto proprio. Ricostruire o ottimizzare il processo CI per un intero team, una business unit o un’azienda è un’impresa molto più gravosa, e comporta costi opportunità e compromessi. Non è impossibile, e molte persone in Proton hanno fatto cose straordinarie da sole, alcune delle quali si sono diffuse ampiamente. Ma riorganizzare l’azienda nel suo complesso richiede un livello di organizzazione e risorse in cui semplicemente non abbiamo ancora investito. Per quanto riguarda la discussione sul ciclo di vita dello sviluppo del software nel paragrafo precedente, in molti casi non sappiamo nemmeno dove siano i colli di bottiglia perché non abbiamo investito negli strumenti necessari per scoprirlo. Una certa cautela potrebbe essere stata giustificata in passato: ci è voluto del tempo per capire come usare al meglio questi nuovi strumenti e continueremo a incoraggiare la sperimentazione. Ma è ormai tempo di impegnarsi, come organizzazione, nella trasformazione che il momento richiede.

Quindi cosa significa per te, ingegnere? Beh, sia la tua autonomia sia le tue responsabilità si sono ampliate. Non sei solo responsabile che il lavoro venga fatto, ora gestisci anche il modo in cui viene fatto e, di conseguenza, sei responsabile dell’ottimizzazione continua e dell’automazione massima (e della condivisione di questi miglioramenti con i colleghi: il successo in Proton è uno sport di squadra). È anche tua responsabilità segnalare e inoltrare i miglioramenti necessari che non puoi realizzare da solo. Proton, dal canto suo, organizzerà e fornirà risorse per gli investimenti critici necessari per superare la fase 2 e realizzare pienamente il potenziale della rivoluzione dell’AI.

In sostanza, siamo in un nuovo mondo. “La programmazione” è morta. L’ingegneria no, e nemmeno la competenza. Il tuo vecchio lavoro non c’è più. Il tuo nuovo lavoro come builder ti permetterà di fare di più e avere più impatto di quanto tu abbia mai fatto, se coglierai l’opportunità. E Proton ti metterà in condizione di farlo, iniziative su cui sentirai parlare di più nei prossimi giorni e nelle prossime settimane. L’era della sperimentazione continua, ma è ora di agire. Il futuro è qui: facciamolo nostro.

Immagine di copertina di: Bernard Leonardo
Instagram: @dranreboel
Sito web: https://dranreboel.myportfolio.com/work