Nel rumore costante dell’innovazione, raramente emerge un segnale davvero strutturale; questa volta, invece, Google ha fatto qualcosa di più sottile e potenzialmente destabilizzante di un semplice rilascio open source. Ha codificato un playbook. E quando una big tech codifica un playbook, non sta distribuendo codice; sta standardizzando il futuro. Il progetto agents-cli, apparentemente innocuo, è in realtà una dichiarazione di guerra silenziosa al modo in cui abbiamo costruito software negli ultimi trent’anni. Un solo comando, un agente che diventa ingegnere di agenti, un prompt che genera un sistema completo. Sembra una demo. Non lo è.

Il punto non è che strumenti come Claude Code, Gemini CLI o Codex possano ora scaffoldingare progetti, scrivere codice ADK in Python, eseguire valutazioni e distribuire su Cloud Run. Il punto è che questa sequenza, che fino a ieri rappresentava il ciclo di vita dello sviluppo software, oggi viene compressa in un’astrazione. Una sola frase: “costruisci un agente di customer support e deployalo”. Il resto diventa implementazione invisibile. È la fine della programmazione come processo esplicito e l’inizio della programmazione come intenzione.

Chi ha vissuto abbastanza cicli tecnologici riconosce il pattern. Negli anni Novanta si scriveva assembly, poi si è passati ai linguaggi ad alto livello, poi ai framework, poi alle piattaforme low-code. Ogni passaggio ha eliminato un livello di complessità visibile, spostandolo altrove. Questo è diverso. Qui non stiamo eliminando la complessità; la stiamo delegando a sistemi che la generano e la gestiscono autonomamente. È un cambio di paradigma che ricorda più l’automazione industriale che l’evoluzione del software. Il codice non è più un artefatto umano, ma un sottoprodotto di un sistema che ottimizza per obiettivi.

Nel frattempo, OpenAI spinge nella stessa direzione con gli agenti operativi dentro ChatGPT, mentre Salesforce e Google Cloud parlano apertamente di workflow autonomi. Non si tratta più di strumenti, ma di ecosistemi che competono per diventare il layer operativo delle aziende. Il software tradizionale, quello che si installa, si configura e si mantiene, appare improvvisamente come un residuo storico. Il nuovo modello è dinamico, adattivo, spesso opaco.

Naturalmente, ogni promessa di semplificazione porta con sé una nuova forma di complessità. Se un agente costruisce un agente, chi valida il comportamento emergente? Se il deployment è automatico, dove si colloca la responsabilità? Il playbook di Google include evals, certo, ma chi ha lavorato seriamente con sistemi di machine learning sa che la validazione non è mai definitiva. È probabilistica, contestuale, fragile. La differenza tra una demo e un sistema in produzione è fatta di edge case. E gli edge case, per definizione, non compaiono nei prompt.

La vera implicazione, tuttavia, è economica. Ridurre il costo marginale dello sviluppo software a quasi zero significa ridefinire la struttura dei costi aziendali. Non serve più un team di dieci sviluppatori per costruire un servizio di supporto clienti. Serve qualcuno che sappia formulare il problema, definire i vincoli, orchestrare gli agenti. Il ruolo dello sviluppatore non scompare, ma si trasforma. Diventa più vicino a un architetto di sistemi autonomi che a un costruttore di codice. È un’evoluzione che molti accolgono con entusiasmo, ma che nasconde una realtà meno romantica: la commoditizzazione delle competenze tecniche.

Nel frattempo, il mercato continua a oscillare tra entusiasmo e nervosismo. Le recenti correzioni nel software enterprise, con ServiceNow e Salesforce sotto pressione, suggeriscono che gli investitori stanno iniziando a interrogarsi sul reale impatto di queste tecnologie sui margini. Se costruire software diventa più economico, cosa succede ai modelli di business basati su licenze e abbonamenti? È una domanda che il settore preferisce evitare, almeno fino al prossimo trimestre.

Nel mondo dell’infrastruttura, la risposta è già chiara. Microsoft investe decine di miliardi per espandere capacità cloud, mentre Nvidia continua a dominare la catena del valore con i suoi chip. Il messaggio implicito è semplice: se il software diventa gratuito o quasi, il valore si sposta sull’hardware e sull’energia. Non è un caso che emergano partnership tra aziende come Oklo e laboratori di ricerca per alimentare fabbriche AI. L’equazione è brutale: più automazione, più consumo energetico, più dipendenza da infrastrutture critiche.

In questo contesto, l’open source assume un ruolo ambiguo. Da un lato democratizza l’accesso, dall’altro standardizza le pratiche. Il playbook di Google non è solo un insieme di strumenti; è un modo di pensare lo sviluppo software. Chi lo adotta, implicitamente accetta le regole del gioco. È una dinamica che ricorda quella dei sistemi operativi negli anni Ottanta o dei cloud provider negli anni Duemila. La differenza è che qui il lock-in non è solo tecnologico, ma cognitivo.

Una nota ironica, quasi inevitabile: per anni si è parlato di “citizen developer”, di democratizzazione del coding, di empowerment diffuso. Oggi, con un singolo comando, si può costruire un agente che costruisce altri agenti. Il risultato non è necessariamente più controllo, ma più astrazione. E l’astrazione, come insegnava Dijkstra, è utile solo se si comprende ciò che nasconde. Altrimenti diventa un’illusione.

Nel frattempo, le grandi aziende continuano a muoversi come se nulla fosse cambiato, firmando accordi miliardari e investendo in infrastrutture. Merck, Google Cloud, Meta che taglia costi mentre investe in AI, Taiwan Semiconductor Manufacturing Company che ottimizza i margini rallentando gli investimenti. Tutti segnali di un sistema che cerca equilibrio tra innovazione e sostenibilità. Un equilibrio instabile, per definizione.

Il paradosso finale è quasi elegante nella sua semplicità. Più automatizziamo lo sviluppo software, più aumenta la necessità di controllo strategico. Più deleghiamo agli agenti, più diventa critica la definizione degli obiettivi. In altre parole, stiamo spostando il valore dalla scrittura del codice alla formulazione delle intenzioni. È un cambiamento che favorisce chi pensa in termini di sistema e penalizza chi esegue.

Una frase, quasi aforistica, direbbe il Prof. Decaro potrebbe riassumere questo momento: il software non si scrive più, si descrive. E chi sa descrivere meglio, vince. Gli altri, inevitabilmente, eseguono.