Programmazione Strategica, Osservabilità e Ruolo del Giardiniere

Riflessione di Matt Pocock e Gergely Orosz su come gli agenti AI ridisegnano il lavoro quotidiano e la carriera dell'ingegnere del software: l'AI assorbe lo strato tattico lasciando agli umani quello strategico, accelera la creazione di debito tecnico anche nei progetti minuscoli e trasforma gli sviluppatori nei "giardinieri" e nel platform team dei propri agenti. ¹

Tactical vs Strategic Programming e la metafora del banco di missaggio

Riprendendo la distinzione di John Ousterhout (A Philosophy of Software Design) tra programmazione tattica (far funzionare la feature immediata) e programmazione strategica (curare la struttura a lungo termine del sistema), Pocock sostiene che l'AI ha ormai mangiato la programmazione tattica, lasciando a noi quella strategica. ¹

Imparare la programmazione strategica è però storicamente difficilissimo perché il ciclo di feedback è estremamente lungo: chi cambiava lavoro ogni sei mesi non vedeva mai le conseguenze dei propri errori strategici, che impiegano circa nove mesi per tornare a colpirti. ¹ Pocock la descrive con la metafora del banco di missaggio (mixing desk): ¹

• Davanti a te hai un enorme banco di missaggio pieno di slider — ad esempio lo slider del numero di unità deployabili: se lo alzi ottieni più microservizi, se lo abbassi ottieni un monolite. ¹
• È come fare il mastering di un brano musicale in cui però non puoi sentire cosa suona storto finché non sono passati nove mesi. ¹

Con gli agenti AI questo ciclo cambia in modo ambivalente: poiché si produce molto più codice molto più in fretta, gli errori strategici tornano a colpirti prima, accorciando il feedback loop; tuttavia, come osserva Orosz, poiché le correzioni sono più rapide e indolori, c'è il rischio che l'apprendimento sia più debole perché vengono a mancare le "cicatrici di battaglia" (battle scars) lasciate dai gravi outage in produzione che formavano i senior e gli staff engineer dopo 5-10 anni di esperienza (vedi Apprendimento e Opzionalità nel Software). ¹ La regola fondamentale resta ricordare che il codice è l'ambiente in cui opera l'agente, e il lavoro strategico consiste nel migliorare costantemente quell'ambiente. ¹

Tech debt nei codebase minuscoli e il problema del reviewer

A un tweet di Jared Friedman (Y Combinator) secondo cui "il debito tecnico era qualcosa con cui dovevi convivere solo in un codebase sufficientemente grande; non più", Pocock ha risposto causticamente: "Sì, ora puoi conviverci anche in un codebase minuscolo". ¹

• Definizione operativa di debito tecnico: tutto ciò che rende il codebase più difficile da modificare nel tempo (al contrario, un buon codebase con una solida test suite permette modifiche senza fallimenti a cascata). ¹
• Incapacità strategica degli agenti: anche i modelli più potenti sono concentrati solo sul task immediato e possono produrre spazzatura persino in una modifica di una sola riga. ¹
• Agente reviewer (e chi controlla il controllore?): un pattern efficace consiste nell'affiancare all'agente di implementazione un agente di code review automatizzata che imponga gli standard del team, cacci i test tautologici e migliori la test suite; ma resta aperta la domanda strategica di secondo livello: come fai a sapere se l'agente di review sta facendo un buon lavoro? ¹

Osservabilità sugli agenti e il 20% del tempo dedicato alla "fabbrica"

Come convincere gli stakeholder non tecnici a investire nei fondamentali e nella riduzione del debito tecnico anziché spremere solo velocità a breve termine? Per Pocock è la stessa conversazione sul tech debt di dieci anni fa, ma oggi abbiamo un vantaggio: possiamo istituire un'osservabilità capillare sugli agenti: ¹

• Metriche per repository: misurare il tasso di successo e di fallimento di ogni singolo agente sarebbe stato invasivo e inaccettabile sugli sviluppatori umani, ma sugli agenti è doveroso perché stiamo pagando un servizio (token) e dobbiamo sapere dove rende. Se alcuni repository dell'organizzazione mostrano tassi di successo più alti di altri, si estraggono le lezioni da quei repo e si propagano al resto dell'azienda (per il contrasto con le metriche di output applicate agli umani, vedi Tirannia delle Metriche, Legge di Goodhart e Leadership). ¹
• Set comune di skill e A/B testing: un'organizzazione deve raccogliersi attorno a un workflow e a un set di skill condiviso a cui tutti contribuiscono, adottando una mentalità sperimentale (es. fare A/B test tra due team con approcci diversi e confrontare i risultati). ¹
• Investire il ~20% del tempo nella fabbrica: Pocock suggerisce di dedicare circa il 20% del tempo non al software in sé, ma alla "fabbrica" che costruisce il software (magari inizialmente sotto traccia finché non porta risultati visibili). Come esempio cita il proprio loop mattutino che esegue automaticamente una skill improve-codebase-architecture, proponendo ogni mattina un miglioramento architetturale che con un clic viene trasformato in ticket e spedito in produzione. ¹

Giardinieri e platform team dei propri agenti

L'ingegnera Lauren ha scritto su X: "Ogni team ha bisogno di un giardiniere: qualcuno che osservi silenziosamente il flusso di PR che entra nel codebase, notando i code smell e le lint suppression che crescono come edera nel giardino curato, con una mano ferma nell'estirpare le erbacce prima che inghiottano tutto". La risposta di Pocock: "Sosterrei che l'unica cosa di cui il tuo team ha bisogno sono giardinieri" (salvo poi concedere che serve anche qualcun altro). ¹

Dietro la battuta c'è una ridefinizione precisa del ruolo dello sviluppatore (vedi anche Agenti per la Potatura): ¹

• "Noi siamo il platform team dei nostri agenti" (Ralph's platform team): il compito dell'umano è costruire l'ambiente in cui gli agenti possano avere successo, diagnosticare l'entropia e le "erbacce" prima che infestino il codebase, e accodare lavoro (queue up work) per i loop di miglioramento continuo (come fa Lars Grammel in Vercel costruendo un'intera software factory per gestire le issue dell'AI SDK). ¹

Hiring, junior developer e il tratto dell'introspezione

Se la programmazione strategica offre una leva così alta mentre il lavoro tattico vale ormai meno del salario minimo in molti paesi, ha ancora senso per un'azienda assumere un junior che non possiede visione strategica? ¹

• L'ipotesi di Uncle Bob: in un'intervista con Pocock, Robert C. Martin (Uncle Bob) ha suggerito di assumere comunque i junior e "trattarli come un agente per un po'", delegando loro compiti tattici finché non iniziano a scontrarsi con i propri errori; ma per Pocock oggi questo rappresenta un enorme spreco di denaro per le aziende, lasciando aperta la questione dal lato datoriale. ¹
• Il consiglio ai junior: dal lato di chi inizia, invece, Pocock vorrebbe trovarsi oggi nei panni di un junior (ripensando a quando nel 2014 scriveva il suo analizzatore di spettrogrammi vocali che scendeva a 10 fps per colpa di sei cicli for annidati, un problema che un agente gli avrebbe fatto notare e capire all'istante). Il consiglio è usare gli agenti il più possibile, usare strumenti come grill-me per simulare il confronto con un senior, mantenere curiosità e adattabilità e concentrarsi non solo sul codice prodotto ma sul processo con cui lo si crea. ¹
• L'introspezione come tratto distintivo: se dovesse riassumere in una sola parola ciò che distingue un grande software engineer oggi, Pocock sceglie introspezione (introspection) — essere un "navel-gazing programmer" capace di osservare ciò che fa, chiedersi come farlo meglio e tradurre il proprio processo in parole perché quello "strano animale" dell'agente possa eseguirlo. ¹

Vedi anche: Tirannia delle Metriche, Legge di Goodhart e Leadership, Matt Pocock, Spec-Driven Development e Dark Factory Agentica, AI Skills e Grill-Me, Leading Words e Fondamentali del Software, Apprendimento e Opzionalità nel Software, Agenti per la Potatura

Fonti e Riferimenti