Proton dichiara morto il coding manuale: gli sviluppatori devono guidare gli agenti AI

L’intelligenza artificiale sta cambiando radicalmente il lavoro degli sviluppatori software, al punto che scrivere codice in modo manuale potrebbe non rappresentare più la competenza principale di un programmatore. A sostenerlo è Bart Butler, CTO di Proton, l’azienda svizzera conosciuta soprattutto per Proton Mail e Proton VPN, che ha pubblicato il 1° novembre 2026 un manifesto destinato a far discutere chiunque lavori nell’ingegneria del software.

Per oltre 20 anni, governi, università e aziende hanno investito risorse considerevoli nell’insegnamento della programmazione. La diffusione dei Large Language Models (LLM) ha però modificato le prospettive: attività che richiedevano ore di lavoro – dalla scrittura di funzioni alla produzione di test – possono oggi richiedere pochi minuti. Secondo il rapporto DORA 2025, basato su quasi 5.000 professionisti del settore tecnologico, il 90% degli intervistati utilizza l’AI sul lavoro e oltre l’80% ritiene che migliori la propria produttività.

Eppure, aumentare la velocità di produzione del codice non significa sviluppare software migliore. È proprio da tale contraddizione che trae spunto il manifesto sull’intelligenza artificiale pubblicato da Proton: un documento nato inizialmente come comunicazione interna, nel quale Butler descrive una trasformazione che coinvolge responsabilità degli ingegneri, organizzazione dei team, automazione e controllo della qualità.

Proton: il programmatore tradizionale ha esaurito il suo ruolo

La dichiarazione più provocatoria del manifesto riguarda la capacità di scrivere manualmente codice di qualità: secondo il CTO di Proton, queste attività starebbero perdendo il ruolo centrale che avevano in passato. Non perché il codice abbia perso importanza, anzi, ma perché i modelli generativi riescono ormai a produrne quantità considerevoli, spesso con risultati tali da accelerare significativamente il lavoro.

Butler riferisce addirittura che, in una delle unità aziendali di Proton, un ingegnere senior gli avrebbe confidato che ormai nessuno scrive più codice. È una testimonianza interna, non una misura della produttività aziendale; indica comunque quanto rapidamente possano cambiare le abitudini di sviluppo.

Un IDE (Integrated Development Environment) con funzionalità di completamento automatico suggerisce istruzioni mentre il programmatore le digita. Un agente AI per lo sviluppo software può invece analizzare un repository, individuare i file coinvolti in una modifica, proporre un’implementazione, eseguire comandi e correggere gli errori rilevati durante i test, purché disponga degli strumenti e dei permessi appropriati.

L’ingegnere non deve più dedicare la maggior parte del tempo a tradurre un requisito in istruzioni: deve stabilire cosa costruire, specificare i vincoli, valutare le alternative e verificare che il risultato soddisfi le condizioni richieste.

Come abbiamo detto analizzando le dichiarazioni del creatore di Claude Code, Boris Cherny, il ruolo del programmatore tende a spostarsi dall’implementazione diretta delle istruzioni verso la definizione degli obiettivi e la supervisione delle modifiche. Generare codice e progettare software affidabile sono attività differenti: un modello può produrre rapidamente un’implementazione apparentemente corretta senza comprenderne tutte le conseguenze su sicurezza, compatibilità, manutenzione e comportamento delle applicazioni.

Ogni sviluppatore diventa responsabile di un gruppo di agenti AI

Il manifesto propone un cambiamento ancora più profondo: considerare gli sviluppatori alla stregua di responsabili di piccoli team, nei quali gli esecutori sono modelli linguistici e agenti autonomi.

Butler parla di strumenti capaci di lavorare con crescente autonomia, evitando che ogni singola operazione richieda un intervento umano. L’ingegnere interviene quando emerge un problema che il sistema non riesce a risolvere e, soprattutto, modifica le istruzioni affinché lo stesso errore non ricompaia continuamente.

Un esempio concreto riguarda i file di istruzioni associati ai repository, come AGENTS.md, che alcuni strumenti di sviluppo assistito dall’AI utilizzano per acquisire indicazioni persistenti sul progetto. Possono descrivere convenzioni di codifica, procedure di compilazione, comandi per eseguire i test e regole per modificare determinate directory.

Accanto a tali file, un’organizzazione può mantenere prompt condivisi, istruzioni riutilizzabili e procedure automatizzate. Se un agente continua a introdurre una dipendenza non autorizzata oppure ignora una particolare regola di compatibilità, la soluzione non dovrebbe consistere nel correggerlo manualmente ogni volta. Meglio individuare la causa, migliorare le istruzioni e predisporre controlli automatici.

L’esperienza dello sviluppatore diventa un mezzo per migliorare il comportamento degli strumenti, anziché una risorsa impiegata esclusivamente nella produzione diretta del software.

I modelli possono generare codice rapidamente, ma non possiedono la responsabilità personale di un ingegnere e possono interpretare erroneamente informazioni incomplete o manipolate. Il giudizio umano rimane quindi decisivo, soprattutto quando una modifica coinvolge componenti critici.

Perché gli sviluppatori usano l’AI ma la produttività non esplode?

Butler riconosce apertamente una contraddizione: se gli ingegneri di Proton utilizzano già i LLM, perché la produttività aziendale non è aumentata in maniera verticale?

La risposta riguarda il modo in cui le organizzazioni adottano l’automazione. Molte aziende sfruttano l’AI soltanto per accelerare singole attività, lasciando invariato il resto del processo di sviluppo.

Immaginiamo uno sviluppatore che completi in 2 ore una modifica per la quale prima servivano 2 giorni. Se la richiesta rimane bloccata per giorni durante revisione, integrazione e approvazione, il vantaggio ottenuto nella generazione del codice incide relativamente poco sul tempo complessivo di consegna.

La tesi trova un interessante riscontro in una ricerca di Harvard sul rapporto tra agenti AI e produttività degli sviluppatori, che abbiamo esaminato su IlSoftware.it. L’adozione degli agenti si associa a un aumento di commit e modifiche al codice, senza un corrispondente incremento statisticamente significativo delle funzionalità completate. Il lavoro di revisione può assorbire parte dei guadagni.

La seconda fase: automatizzare l’intero ciclo di sviluppo

Proton vuole superare quella che Butler definisce la prima fase di adozione dell’AI: accelerare attività individuali senza ripensare il funzionamento complessivo dei team.

La fase successiva richiede di intervenire sui colli di bottiglia del ciclo di sviluppo software: il CTO cita esplicitamente infrastrutture di continuous integration (CI), progettazione, specifiche, approvazioni e revisione del codice.

Un sistema CI basato, ad esempio, su GitHub Actions o GitLab CI può diventare un limite quando gli agenti producono modifiche più rapidamente della capacità disponibile per compilazioni e test. Aumentare il numero di esecutori paralleli può aiutare, ma spesso occorre intervenire anche sulle dipendenze tra i processi, sul caching e sulla selezione dei test da eseguire.

Butler arriva a ipotizzare che gran parte delle revisioni umane del codice possa scomparire. Ed è questo uno dei passaggi più controversi del manifesto.

Una code review automatizzata può identificare violazioni delle convenzioni, errori ricorrenti, regressioni e alcune vulnerabilità. Non offre però garanzie assolute sulla correttezza dell’implementazione. Per modifiche che coinvolgono autenticazione, crittografia, autorizzazioni o dati personali, affidare esclusivamente agli agenti la valutazione finale introduce rischi difficili da giustificare.

La stessa distinzione tra velocità e affidabilità costituisce il cuore del nostro approfondimento sul vibe coding e sui rischi del software generato dall’AI. Descrivere un risultato in linguaggio naturale è semplice; verificare che il programma continui a funzionare correttamente in condizioni impreviste richiede competenze decisamente più profonde.

Il terzo problema: l’automazione richiede investimenti collettivi

Il terzo ostacolo individuato da Butler riguarda l’organizzazione aziendale. Un programmatore può scegliere di utilizzare Claude Code o Codex, ma non può riprogettare da solo le infrastrutture condivise, modificare le procedure di rilascio o sostituire gli strumenti di controllo adottati da centinaia di colleghi.

Proton riconosce di non aver ancora destinato risorse sufficienti a tali interventi. In alcuni casi, osserva il CTO, l’azienda non dispone nemmeno degli strumenti necessari per identificare con precisione dove si concentrino i ritardi.

Misurare il problema richiede indicatori più significativi delle semplici righe di codice. Tempi di attraversamento delle modifiche, frequenza dei rilasci, errori introdotti in produzione e tempi di ripristino permettono di valutare se l’automazione migliori effettivamente la capacità di consegnare software affidabile.

La responsabilità non può ricadere soltanto sui singoli ingegneri: servono investimenti coordinati, infrastrutture adeguate e procedure condivise. In assenza di tali condizioni, anche gli agenti più avanzati rischiano di produrre soprattutto una maggiore quantità di lavoro da controllare.

La programmazione è davvero morta? La questione è più complessa

Butler conclude il manifesto osservando come la programmazione tradizionale sarebbe ormai superata, mentre ingegneria del software ed esperienza professionale conserverebbero tutta la loro importanza.

Non tutti condividono una posizione così radicale. Nel nostro articolo dedicato al valore della programmazione manuale nell’era dell’intelligenza artificiale, abbiamo ripreso le considerazioni dell’allora CEO di GitHub Thomas Dohmke, secondo cui conoscere il codice rimane indispensabile per rilevare le implementazioni sbagliate e sfruttare efficacemente gli strumenti generativi.

Esiste poi una questione spesso trascurata: se gli sviluppatori junior scrivono sempre meno codice, come acquisiranno l’esperienza necessaria per riconoscere gli errori degli agenti? Affidarsi completamente all’automazione potrebbe indebolire proprio quelle competenze che Proton considera decisive. Ed è un po’ quello che sottolineavamo nella lettera aperta a Bill Gates sull’AI.

Nemmeno gli aspetti giuridici possono passare in secondo piano. Come abbiamo spiegato esaminando la proprietà intellettuale del codice generato dall’AI e il caso Claude Code, la presenza di contributi automatici apre interrogativi su autorialità, licenze open source e responsabilità nella distribuzione del software.

Come ha sempre sostenuto Leslie Lamport, coding e programmazione sono due cose molto diverse ed è per questo che il ruolo del programmatore non può e non deve scomparire. Delegare la scrittura del software non significa poter delegare anche la comprensione del suo funzionamento!