Mario Zenz e Armen Roner spiegano perché gli agenti stanno cambiando il lavoro sul codice, ma anche perché la qualità resta fragile e la frizione serve ancora.
Piace a chi vuole strumenti semplici, stabili e prevedibili, anche quando una parte del lavoro resta non deterministica. Mario Zenz dice che il suo agente di codice nasce proprio da lì, dalla frustrazione per prodotti che cambiano comportamento mentre lui cerca solo di lavorare. Armen Roner arriva alla stessa conclusione da un altro lato, dopo aver visto teams e repository riempirsi di automazione, di pull request più lunghe e di un nuovo tipo di disordine. La domanda che resta sotto tutto il dialogo è se gli agenti stiano davvero migliorando il software o soltanto accelerando il modo in cui lo complicano.
Zenz entra nell’AI coding da una diffidenza molto pratica: gli strumenti gli interessano solo se restano semplici, stabili e affidabili, anche quando una parte del loro comportamento è non deterministica. Da lì nasce anche la sua idea più radicale, che Pi possa modificarsi da solo, e che persino richieste come “aggiungi MCP” possano essere delegate all’agente invece che a un umano.
Mi piacciono gli strumenti semplici, stabili, su cui posso contare, anche se hanno parti non deterministiche. Quindi puoi chiedere a Pi di modificare se stesso.
Le persone ora sono così concentrate sul fatto che tutti possano fare tutto che si dimenticano che serve ancora un processo per mettere i guardrail a tutto questo.
Roner arriva allo stesso territorio da una traiettoria diversa, più lunga e più scettica. Racconta un’infanzia da smanettone, i primi passi con QuickBasic, Pascal e poi Python, fino a Flask e a Sentry, e la sua postura verso l’AI resta inizialmente difensiva: Copilot gli sembra utile, ma anche potenzialmente controverso per il modo in cui si appoggia al codice open source.
Copilot mi dava la sensazione che sarebbe stato interessante, ma non in quel modo. Pensavo: sono nell’open source da così tanto tempo, e ora stanno facendo training sui dati open source, almeno sarà una cosa controversa.
11:40
A un certo punto cercavo di provocarlo in modo davvero avversariale. Provavo a vedere se avrebbe riprodotto codice GPL, e una volta sono riuscito a fargli sputare fuori la funzione della radice inversa di Quake.
12:14
La svolta, per entrambi, non arriva subito con i chatbot, ma con gli agent capaci di usare strumenti. Zenz dice che il momento decisivo è quando l’agente può leggere davvero l’intero filesystem, non solo cercare dentro indici o autocomplete più sofisticati; Roner parla di una sensazione simile, ma solo quando il modello smette di essere un giocattolo da provare e comincia a sembrare utile nei compiti di bug fixing e modifica concreta del codice.
La promessa degli agenti, qui, si rovescia quasi subito nel suo costo più visibile: producono più codice, più in fretta, ma anche più lavoro di controllo. Armen Roner racconta che nelle squadre che ha sentito il ritmo cambia soprattutto quando le persone hanno tempo libero, ferie, crediti gratuiti o un ordine esplicito del capo, poi tutto accelera e la qualità si incrina. Il punto non è che gli ingegneri diventino peggiori, ma che il sistema li spinge a entrare in una zona dove la revisione costa più di prima e la frizione umana si assottiglia.
Quando succede l’adozione, quando la gente è in vacanza, c’è più tempo speso a provare questi strumenti.
15:39
Dopo Natale, in più della metà delle aziende di cui ho parlato, è davvero esploso.
16:45
Roner insiste sul fatto che il guaio non è solo quantitativo. Le pull request diventano più lunghe, più frequenti e più difficili da leggere, perché contengono codice che un ingegnere non scriverebbe mai con lo stesso istinto di autoprotezione verso il proprio lavoro futuro. L’agente, dice in sostanza, non prova il fastidio che porta un senior a fermarsi prima di aggiungere complessità inutile.
La qualità scende, e non necessariamente perché la gente vuole scrivere codice peggiore, ma perché restare dentro questo richiede sforzo.
17:12
Un buon ingegnere è uno che dice no molto spesso e che dice: non mi serve questo.
22:05
Zenz parte da una tesi semplice: un agente di codice funziona davvero solo se il suo centro resta piccolo, leggibile, toccabile. Pi, racconta, nasce proprio come reazione a strumenti che cambiavano comportamento mentre lui cercava stabilità, e che quindi rendevano fragile il lavoro invece di aiutarlo.
Volevo strumenti semplici, stabili e affidabili, anche se hanno parti non deterministiche. Le parti deterministiche dovrebbero essere il più stabili possibile
33:34
Per Zenz, il problema non era il modello in sé, ma tutto ciò che gli ruotava attorno. In Pi il cuore resta un set minimo di operazioni, e proprio questa sottrazione diventa il punto di forza: meno logica incorporata nel prodotto, più spazio per adattarlo al contesto reale senza aspettare che il vendor cambi idea.
Più il modello fa cose incredibili, più noi estendiamo tutto al resto, come facciamo sempre nel software. È lo stesso errore che abbiamo fatto nell’edtech
31:19
La sua critica a Claude Code e a OpenCode è molto concreta. Zenz dice che entrambi intervenivano troppo sul contesto, nascondevano modifiche dietro le quinte e finivano per confondere il modello con diagnosi e segnali introdotti troppo presto, quando il lavoro non era ancora finito.
Mi toglievano il controllo del contesto. Iniettavano roba dietro le spalle, e i flussi che prima funzionavano smettevano di funzionare
33:36
Se mi affido a uno strumento di sviluppo, voglio che sia stabile e affidabile come un martello. Non voglio che il mio martello si rompa in un punto diverso ogni giorno
34:24
Il successo di Pi e di OpenClaw ha portato a galla un problema che prima restava ai margini: quando i repository diventano bersagli di agenti, il rumore cresce più in fretta della capacità umana di filtrarlo. Mario Zenz descrive un ecosistema in cui la manutenzione non è più solo scrivere codice, ma difendersi da pull request automatiche, issue sintetiche e contributi che arrivano senza intenzione reale dietro. L’effetto, per lui, è una nuova forma di assedio dell’open source.
Io ora mi godo tutte le istanze di OpenClaw che pensano che i bug di OpenClaw siano in realtà bug di Pi, quindi mi mandano autonomamente una quantità enorme di issue e pull request senza che probabilmente gli utenti ne sappiano nulla, e io devo gestirle nel mio open source. Questo è un effetto collaterale negativo.
49:00
Se non ho avuto contatti con te prima, il mio workflow GitHub chiude automaticamente la pull request. Un agente umano non importa. Mi serve solo un collo di bottiglia che mi permetta di processare il volume di cose in arrivo come un essere umano.
50:46
Zenz insiste che il vero problema non è la provenienza automatica dei contributi, ma la perdita di back pressure. Quando una persona doveva investire tempo per aprire una pull request, la soglia era già un filtro; ora basta chiedere a un agente di provarci, e la pressione finisce tutta sul maintainer. Per questo parla di bottlenecks, non di autenticazione umana: serve un modo per ridurre il flusso a una scala che un essere umano possa ancora trattare senza far marcire il codicebase.
Abbiamo bisogno di colli di bottiglia. Non mi serve necessariamente la verifica umana, o la verifica che tu sia umano. Mi serve un collo di bottiglia che mi permetta di processare la quantità di cose in arrivo.
53:29
La complessità che aggiungono è il loro peggior nemico, perché alla fine il codicebase sarà così grande e così complicato che l’agente non avrà alcun modo tecnico di inghiottire tutto il contesto che gli serve per fare il nuovo compito.
1:00:44
La correzione, per Zenz e Roner, non arriverà per gentilezza del mercato ma per stanchezza. Il ciclo che ha reso gli agenti irresistibili nelle demo, dicono, sta già producendo il suo rovescio, più complessità, più dipendenza da poche infrastrutture, più codice generato per problemi che prima si risolvevano in modo più semplice. La tesi è meno morale che ingegneristica: il sistema spinge verso l’eccesso, poi costringe a riscoprire i limiti.
Credo che si arriverà a una correzione automatica, perché non è sostenibile.
1:30:48
I team di ingegneria già mi dicono che hanno basi di codice che pensano di non poter più mantenere senza la macchina.
1:26:30
Roner legge il boom degli agenti come una classica fase di euforia: prima l’innamoramento, poi l’attrito. Racconta di persone partite in quarta con modelli nuovi e poi rallentate da edge case, review più dure e sistemi cresciuti troppo in fretta. Il punto non è che gli agenti non funzionino, ma che spesso funzionano aggiungendo strati che il lavoro umano deve poi smontare.
Ora tutti si stanno drogando di questa cosa a quantità inimmaginabili di sonno perso e di basi di codice terribili. E credo che si auto-correggerà, perché non è sostenibile.
1:30:48
Quando è davvero necessario, tornerà a raggiungerti. Se qualcosa resta nel discorso per tre settimane, allora c’è probabilmente qualcosa sotto.
1:28:06
Zenz sposta il discorso dalla velocità alla disciplina dell’attenzione. Dice che oggi è difficile non farsi trascinare, specie quando ogni settimana porta un nuovo salto di capacità percepita, ma sostiene che il tempo fa il suo lavoro meglio delle timeline di prodotto: separa ciò che resta da ciò che era solo eccitazione. È una posizione quasi anti-hype per metodo, non per nostalgia.
Perché Pi è diverso dagli altri agenti?
Pi è diverso perché ha un nucleo minimale e molti punti di estensione. Zenz sostiene che così l’utente può adattarlo al compito, perfino facendolo modificare da sé.
Perché i due diffidano degli agenti autonomi?
Perché, secondo loro, gli agenti non sentono il costo della complessità che aggiungono. Zenz dice che un buon engineer dice spesso no; l’agente tende invece ad accettare tutto.
MCP è bocciato del tutto?
No. Roner e Zenz gli riconoscono casi d’uso reali, soprattutto in enterprise. La loro obiezione è che spesso è poco composabile e meno flessibile della CLI o del codice.
Che ruolo ha la frizione nei processi?
Per loro la frizione serve a fermare cambiamenti rischiosi e a obbligare una decisione consapevole. Non è solo burocrazia: può evitare errori e mantenere qualità.
Perché parlano tanto di qualità del codice?
Perché vedono un nesso diretto tra velocità degli agenti e deterioramento del codicebase. Se nessuno sente più il costo delle decisioni, la complessità cresce più in fretta di quanto possa essere controllata.
Code (1999)
Zenz lo cita come il libro che raccomanda a chi gli chiede cosa fa il suo lavoro, perché mostra che il coding ha molto meno a che fare con i computer di quanto si pensi.
Breakneck
Roner lo menziona come lettura recente che gli è sembrata provocatoria nel confronto tra Cina, Europa e Stati Uniti.
Sintesi assistita dall'AI del podcast di The Pragmatic Engineer, verificata sulla trascrizione originale.