Pi, il software che si modifica da solo

Dalla frustrazione al primo agente

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 qualità paga il prezzo

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

Pi come strumento malleabile

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

Open source sotto assedio

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 arriverà tardi

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.