AI-assisted delivery: più output non significa più controllo

Quando un team inizia a usare Claude Code o un altro coding agent, il primo effetto visibile è quasi sempre un aumento dell’output. Arrivano più branch, più pull request, più prototipi e più fix che prima sarebbero rimasti in backlog per settimane. All’inizio è facile leggerlo come un miglioramento lineare: se produciamo di più, stiamo andando più veloci.

La guida Anthropic su come costruire con Claude porta lo stesso ragionamento su un piano pratico: il sistema utile non è solo il modello, ma il workflow intorno, il contesto, gli strumenti e i cicli di valutazione. È lì che l’output diventa delivery, oppure rumore.

In parte è vero. Un PM tecnico può validare un’idea senza aspettare un intero ciclo di sviluppo, un engineer può togliersi di dosso lavoro ripetitivo, un founder può vedere una demo prima di decidere se investire davvero su una direzione. Il problema nasce quando quel volume entra nel flusso reale del team: review, test, responsabilità, decisioni di prodotto.

A quel punto la domanda non è più solo chi ha scritto il codice. Spesso il codice lo ha scritto, almeno in parte, un modello. La domanda diventa più concreta: quali condizioni devono essere vere perché quell’output possa diventare prodotto?

L’AI-assisted delivery cambia dove serve controllo

Una cosa che ho imparato usando Claude Code è che l’AI non crea da sola i problemi di delivery. Di solito li rende più visibili. Se un team ha requisiti vaghi, il coding agent produrrà una soluzione coerente con quella vaghezza; se non esiste una definizione condivisa di done, il modello ne userà una sua; se la review era già debole, verrà attraversata da più materiale, più in fretta.

Non sto dicendo che i coding agent siano un rischio da contenere con burocrazia. Sarebbe una lettura poco utile, soprattutto per team piccoli che hanno bisogno di muoversi. Il punto è diverso: quando produrre diventa più economico, il costo si sposta sulla capacità del team di scegliere cosa accettare, cosa correggere e cosa fermare.

Per questo una review finale più attenta non basta sempre. Se aspetti la pull request per capire se il lavoro era quello giusto, stai chiedendo alla review di controllare troppe cose insieme: intento, qualità tecnica, coerenza col prodotto, edge case, sicurezza, impatto sui dati. Con un coding agent questa pressione aumenta, non perché il codice sia per forza peggiore, ma perché è più facile generarne altro.

Il contesto non può restare nella testa delle persone

I team hanno già strumenti di controllo: test, CI, pull request, ambienti di staging. Il problema è che questi strumenti rispondono bene solo ad alcune domande. I test ti dicono se qualcosa si è rotto rispetto a ciò che avevi previsto; raramente ti dicono se la richiesta iniziale era formulata bene. La CI controlla una parte della qualità tecnica, ma non capisce se il comportamento prodotto è coerente con una decisione di business.

La code review può intercettare molto, ma solo se chi revisiona ha contesto sufficiente e tempo per leggerlo davvero. Qui i coding agent rendono tutto più evidente: il contesto non può vivere solo nella testa di chi ha chiesto il lavoro. Deve entrare nel brief, nel piano, nei criteri di accettazione e nei punti in cui una persona decide se procedere o fermarsi.

Se il modello genera una modifica su permessi, stato utente o flussi di pagamento, la review deve sapere quali invarianti proteggere. Se tocca un funnel, qualcuno deve chiarire quale comportamento non deve peggiorare. Se cambia un workflow interno, serve sapere chi userà quella cosa e cosa succede quando fallisce.

Sono domande di prodotto tanto quanto domande tecniche. Per questo l’AI-assisted delivery non riguarda solo gli engineer: riguarda anche PM, founder e operator che oggi possono costruire di più, ma devono imparare a governare meglio quello che costruiscono.

Lo stesso schema ritorna nei principi su inference, contesto ed eval e nel model routing per l’AI coding: la velocità aiuta solo se il team riesce ancora a spiegare cosa è cambiato e perché è accettabile.

Autonomia non significa delega cieca

Il passaggio da PM a builder mi interessa perché la distanza tra idea e prodotto funzionante si è accorciata. Puoi costruire una dashboard interna in pochi giorni, automatizzare un workflow che prima aspettava un ticket, prototipare un tool operativo senza aprire subito un progetto grande. È una possibilità reale, e per molti team piccoli può fare la differenza.

Questa autonomia, però, ha un costo: bisogna sapere quando fermarsi. Un PM che genera codice deve riconoscere il confine tra prototipo e produzione. Un founder che costruisce una demo con AI deve capire quando quella demo inizia a toccare dati reali, utenti reali e decisioni reali. Un team tecnico che usa agenti ogni giorno deve chiarire dove finisce il supporto alla delivery e dove inizia la delega cieca.

Non serve mettere un comitato davanti a ogni prompt. Serve definire poche regole prima che il volume aumenti: quali cambiamenti sono a basso rischio, quali richiedono review tecnica, quali toccano dati o permessi, quali hanno bisogno anche di una validazione di prodotto. La distinzione è semplice, ma cambia molto perché non tutti gli output hanno lo stesso rischio.

Una governance piccola, ma reale

Quando ho iniziato a lavorare su Tierward, il problema era proprio questo: usare Claude Code senza trasformare ogni sessione in un atto di fiducia. Mi interessava una governance leggera e reviewable, capace di adattarsi al tipo di cambiamento. Un fix piccolo non ha bisogno dello stesso livello di controllo di una modifica su autenticazione, billing o dati sensibili; una spike esplorativa non va trattata come una feature pronta per produzione.

Da qui nasce l’idea dei livelli. Fast lane quando il rischio è basso. Standard quando serve una review più strutturata. Full governance quando l’impatto è alto e il costo di un errore non è trascurabile. Non è burocrazia se aiuta il team a decidere meglio dove mettere attenzione.

La metrica sbagliata, in questa fase, è misurare l’adozione dell’AI solo con il volume: quante PR in più, quanti ticket chiusi, quante ore risparmiate, quanti prototipi generati. Sono segnali utili, ma non bastano. A volte indicano progresso, altre volte mostrano solo che il costo si è spostato dalla scrittura alla review, dal codice al debug, dalla decisione iniziale alla correzione finale.

Una domanda più utile è: quando un coding agent dice done, cosa deve essere vero perché il team possa credergli?

Questa è la parte che mi interessa di più. Non l’AI che scrive al posto delle persone, ma l’AI che costringe il team a scrivere meglio ciò che prima restava implicito: requisiti, vincoli, ownership, test, criteri di accettazione, decisioni di prodotto. Se questi elementi mancano, il modello riempie i vuoti, e spesso produce qualcosa che suona corretto prima ancora di esserlo.

Prima di accelerare

Adottare coding agent oggi è facile. La parte difficile è capire che tipo di organizzazione serve intorno a quella velocità. Non serve partire da un framework enorme: può bastare una domanda pratica, da fare prima di ogni cambiamento non banale.

Che cosa deve essere verificato da una persona prima che questo output diventi prodotto?

Se la risposta è chiara, l’AI-assisted delivery può diventare un vantaggio reale: meno attesa, più autonomia, più capacità di trasformare idee in cose che funzionano. Se la risposta è vaga, l’AI non elimina la build trap. La rende solo più veloce.

E a quel punto il problema non è quanto il team riesce a produrre. È quanto riesce ancora a controllare.