Agenti e ingegneria: come cambiano pianificazione, responsabilità e confini tecnici

Simon Willison fissa un ordine di grandezza: “un migliaio di righe di codice già debugged” in un giorno, se la qualità resta identica. Un ingegnere, prima, produceva tra 50 e 60 righe al giorno. Una giornata “incredibilmente buona” valeva 200 righe. Se i numeri tengono, la quantità torna un segnale per ragionare di produttività, ma solo dentro il perimetro di qualità che Willison rende esplicito: manutenibilità, test, codice pronto per la produzione. Sullo sfondo sta il divario tra prototipi rapidi e software che regge carico, incidenti, audit e convivenza con altri sistemi: la scena descritta su martinfowler.com vede una persona non tecnica portare una demo fatta in fretta e chiedere perché i team non vadano dieci volte più veloci.

1) La tesi in pratica: perché la pianificazione cambia

Matt Pocock pubblica /wayfinder su Latent Space per pianificare quando il traguardo non è ancora visibile. L’obiettivo dichiarato è muoversi nella “fog of war” con passi chiari e progressivi, senza presumere un percorso lineare. Si parte con informazioni incomplete e si affina la rotta man mano che emergono elementi utili. L’idea nasce da pratica quotidiana: Pocock lavorava con agenti “AFK” e predispondeva attività eseguibili mentre lui non era alla tastiera. “Pianificavo un sacco di cose, poi creavo una specifica”, racconta. Il metodo punta ad accumulare lavoro che l’agente può svolgere senza supervisione continua, così da far avanzare il progetto anche in assenza del supervisore umano.

Latent Space inquadra /wayfinder in una serie di skill pronte all’uso. L’annuncio arriva con un’intervista e l’invito a provarla nei propri progetti, primo episodio di una nuova serie dedicata alle skill. L’accento resta sulla gestione dell’incertezza: l’assunzione non è un piano chiuso, ma un percorso che si aggiorna a ogni riscontro utile.

Il richiamo al confine tra demo e prodotto aiuta a leggere questa impostazione. Il saggio “Citizens Build, Agents Execute, Experts Govern” descrive una dinamica degli ultimi mesi: una demo costruita in pochi giorni entusiasma e mostra che “gira”, ma non regge requisiti come sicurezza, affidabilità, integrazioni e governance. Un prototipo mostra una funzionalità. Un prodotto regge incidenti, carico, cambi di requisito, audit, on-call, e convive con altri sistemi. È lo scarto tra “far girare qualcosa” e “fare ingegneria del software”.

2) Output e metriche: le linee di codice tornano rilevanti?

Willison riprende una metrica spesso screditata. Le linee di codice contano solo se il codice resta “della stessa qualità”: manutenibile, testato, di livello produzione. Senza questo perimetro, la metrica non regge. Con questo perimetro, la quantità diventa un segnale utile per ragionare di produttività quando si usano agenti di coding. Il confronto con il passato è concreto: “poche centinaia” di righe pronte per la produzione per un ingegnere, con una media tra 50 e 60 e un picco “incredibilmente buono” di 200. Con agenti, fino a “un migliaio di righe di codice già debugged” in un giorno, a parità di qualità.

Qui si incastra il punto del saggio su martinfowler.com. L’autrice descrive una scena ricorrente negli ultimi sei mesi: una persona non tecnica porta una demo fatta in fretta, collega il risultato al potenziale dell’IA e confronta quel ritmo con quello dei team di ingegneria. Dodici mesi fa quella prova sarebbe stata improbabile; oggi è alla portata. Da qui nasce l’aspettativa che tutto il software si possa costruire con la stessa rapidità. La distinzione tra prototipo e prodotto, rimarcata nel saggio, delimita l’uso sensato delle metriche: ciò che vale in condizioni controllate non equivale a un sistema destinato a durare.

3) Attriti organizzativi: dove gli agenti incontrano l’azienda reale

The Pragmatic Engineer ricostruisce una sequenza netta in Meta: tagli di circa il 10% del personale mentre l’azienda riportava ricavi e profitti ai massimi; riassegnazione tra il 20% e il 30% degli ingegneri software su compiti di etichettatura dati “di fatto senza preavviso”; in molti hanno iniziato a fare colloqui altrove, inclusi dipendenti che non erano stati riassegnati. Le uscite hanno toccato ingegneri e product manager, con profili senior in primo piano.

Due mesi fa l’autore aveva descritto come l’azienda stesse “distruggendo” la propria organizzazione di ingegneria. Oggi definisce quei tagli un errore non forzato. A suo giudizio l’impatto nasce dalla combinazione di licenziamenti e riassegnazioni obbligate, non da un calo di performance. Nuove testimonianze raccolte nelle ultime settimane indicano dimissioni e un’ondata di colloqui esterni in aree chiave dell’ingegneria e del prodotto. Anche chi è rimasto nel proprio ruolo ha esplorato opportunità fuori dall’azienda.

Il quadro, per chi lavora su AI e software, mostra il peso delle scelte organizzative a fronte di cambi di mansione e priorità. Le testimonianze riportate parlano di spostamenti su attività di etichettatura dati e di conseguenti dimissioni o colloqui esterni, con particolare incidenza tra i profili senior dell’ingegneria e del prodotto.

4) Confini tecnici: runtime, policy e limiti di sandboxing

Amazon introduce filtri per dominio e per data di pubblicazione nel connettore web-search 1.2.0 di AgentCore su Bedrock. Il controllo avviene per chiamata: chi sviluppa decide, query per query, quali domini l’agente può consultare e qual è la finestra temporale ammessa. L’enforcement è lato server, senza orchestrazione esterna. Le regole di runtime si combinano con le policy di dominio definite dagli amministratori. Ne esce un filtraggio a più livelli, utile ad esempio per evitare blog non verificati in finanza o prezzi vecchi in risposte su prodotto.

C’è poi il tema dell’esecuzione sicura del codice. Il 19 agosto 2026, Simon Willison ha provato a usare smolmachines/smolvm come sandbox in Claude Code for web per eseguire Python e JavaScript con limiti di RAM e CPU, senza rete e con accesso al filesystem ristretto a file designati. Il test si è scontrato con l’ambiente di esecuzione: le note riportano un guest Firecracker con Linux 6.18.5-fc-v20, 4 vCPU e 15 GB di RAM. Non c’è /dev/kvm, mancano i flag CPU vmx/svm. Le note di Claude registrano “no nested virt”. Il comando per avviare smolvm fallisce con il messaggio “kvm not available”. La diagnosi è esplicita: in quell’ambiente smol machines non può partire.

Il contrasto tra controlli a runtime e limiti dell’ambiente emerge dalle stesse fonti. Da un lato, filtri di dominio e di freschezza server-side per l’accesso al web. Dall’altro, l’impossibilità di avviare una VM leggera in assenza di KVM, come documentato nel test di Willison. Sullo sfondo resta la distinzione tra demo e prodotto: il saggio su martinfowler.com avverte che ciò che funziona in condizioni controllate non equivale a un sistema destinato a durare. E le osservazioni di Willison riportano numeri precisi sulle linee di codice, ma legandoli a un vincolo di qualità dichiarato.

La combinazione di questi fatti, presi dalle fonti, disegna tre piani concreti: pianificare nell’incertezza con passi progressivi; misurare l’output solo dentro confini di qualità espliciti; applicare controlli di runtime e conoscere i limiti dell’ambiente di esecuzione. Il saggio su martinfowler.com ricorda il perché: prototipi e sistemi di produzione rispondono a vincoli diversi.