Scritti · Coding agentico

La papera muta

Un tempo la papera di gomma stava zitta, e serviva proprio per quello. Oggi è cambiata: parla, ragiona, decide con te. E il rischio è che quello rimasto muto sia tu.

29 agosto 2026

Tempo fa, prima che esistessero gli strumenti di coding agentico, per chiarirmi le idee usavo il metodo della papera di gomma. Nel mio caso è una zebra di legno, ma poco cambia. Funziona così: hai un problema ingarbugliato in testa, prendi la papera e glielo racconti a voce, punto per punto. Lei non risponde, sta lì muta. Ed è tutto lì il trucco. Per raccontarle la cosa sei costretto a rimettere in fila la confusione, a trasformarla in un filo che si regge da solo, e mentre lo dici a voce certi nodi si sciolgono. La papera non ti dà niente. Sei tu che, parlandole, ti dai una risposta.

All'inizio, con Claude, ho fatto come tanti. Mi mettevo in plan mode, spiegavo cosa mi serviva, e lui mi sfornava un piano dettagliatissimo. Un documentone, e io lì impressionato. Poi però cominciavo a leggerlo e mi perdevo, perché era pieno di dettagli che non conoscevo. E allora cosa facevo? Davo l'ok sulla fiducia. Ne capivo un quinto, non osavo chiedere chiarimenti, e comunque il meccanismo è fatto così: ti dice "bene, procedo?", e le uniche due mosse sono ok e no. Verso l'ok sei spinto molto di più. I chiarimenti me li sono dovuti chiedere dopo, quando, al posto dell'auto che avevo chiesto, mi sono ritrovato una falciatrice a motore. Le specifiche erano pure corrette. L'obiettivo era sbagliato.

Ho provato altri strumenti nel tempo, Superpowers, OpenSpec, e andavo sempre a finire nello stesso posto. Documenti corposi, dettagliati, e io che dopo un po' mi perdevo. Il motivo è che questi strumenti tendono a darti una montagna di dettagli su cosa fare: vai nel file tale, alla riga tale, sostituisci questo con quello. Il punto è che io sono un umano. Il file tale e la riga tale non li conosco, e se mi metto a leggere quel pezzo di codice facciamo notte. Tanto più che non è quello il mio intento. Il mio intento è delegare l'insieme di decisioni che dovrei prendere per implementare quella cosa. Buttare giù il codice è la parte che mi interessa meno. Quello che mi serve è qualcuno che percorra tutto l'albero delle decisioni necessarie a fare una certa cosa, e a ogni bivio lasci scegliere me.

Quando fa il planning, la macchina cosa fa? Si legge tutta la tua codebase, la scompone in tante parti, e ognuna diventa una cosa su cui operare: vai qui, cambia là, aggiungi quest'altro file, e avanti così. Che sappia trovare la riga esatta leggendo il codice che hai già scritto tu è il suo mestiere, e lo fa bene. Quello che di solito non fa è gestire in chiaro le decisioni che quei cambiamenti si portano dietro. O meglio: le prende, ma non le rende esplicite. È qui il problema del grosso dei sistemi di planning di oggi. La decomposizione di cosa fare nasce dal codice; la tua testa ne resta fuori. E il livello file-riga, ormai, lo produce lei: a te dovrebbe restare il livello sopra, quello delle decisioni. Invece resta sepolto.

È un vecchio problema, e c'è chi l'ha già raccontato benissimo: cinque requisiti precisi ti fanno immaginare un'automobile, finché le stesse cose, raccontate dal punto di vista di chi le userà, non fanno saltare fuori un trattorino tagliaerba. Descrivevano un oggetto alla perfezione, e un obiettivo omesso ti lasciava costruire quello sbagliato.

Tre livelli. Al primo ci sono io, che do gli obiettivi: dico a cosa deve servire, che problema risolve, cosa conta per me. Poi la macchina scrive i requisiti, e mentre li scrive tira fuori ogni decisione che può cambiare l'esito, una per una, e accanto a ciascuna appiccica un cartellino: questa l'hai decisa tu, questa è discrezionale e l'ho presa io, questa me la devi dire tu perché io non lo so. Sotto ancora, e solo sotto, le dico "adesso esegui, e se trovi un'ambiguità fermati e chiedimi". Il primo livello è il mio. Il terzo è il suo. In mezzo c'è quello che oggi manca quasi sempre: il punto dove le decisioni affiorano e qualcuno le può prendere. Gli strumenti tendono a saltarlo per puntare dritti alla riga da cambiare. Sono pensati per la macchina, quindi l'umano resta scoperto.

Alla fine della fiera, però, la firma è la mia. La riga tredici del file se la vede la macchina. A quel punto una specifica diventa più leggibile, perché diventa la messa per iscritto delle decisioni che abbiamo preso. Io per la mia parte, la macchina per la sua. Tutto qui. Un elenco di scelte ed attribuzioni di responsabilità anziché un documentone di cui leggi le prime dieci righe poi dici "Sì sì, va bene dai" perché la complicazione ti impigrisce. Di strumenti simili ne vedo pochi, sono quasi tutti ancora pensati solo per la macchina, ma credo dovremo abituarci ad usare di più la nostra di testa, e decidere *insieme a lei* invece di lasciarle decidere tutto.

Qui casca l'asino. O la papera. Oggi a guardar bene i ruoli si sono invertiti. La papera sei tu. Butti fuori il problema e la macchina ti restituisce il suo sproloquio, come facevo io anni fa. Tu stai lì a leggerlo senza metterci niente di tuo. La macchina però non si deve chiarire le idee mentre te lo racconta. In compenso tu le hai più confuse ma non lo sai.

C'è però un vantaggio rispetto ad una volta. Se la macchina torna ad essere la tua papera, non ha bisogno di essere muta. È una papera parlante, che può ragionare assieme a te sulle cose. La versione 2.0, insomma. Allora usiamola questa papera, assieme al nostro cervello, perché le decisioni a volte è meglio prenderle in due.

La mia zebra è ancora lì sulla scrivania, comunque. Lei non dice nulla sul serio, ma continua spesso ad essere la cosa più utile nella stanza.