Idea principale

Quando un agente come Claude Code implementa una funzionalità, esplora il codice esistente, modifica diverse classi, aggiunge funzioni, scrive test, e consegna un lavoro che compila e i cui test passano. Questi due segnali dicono che l'implementazione è tecnicamente corretta. Non dicono nulla della sua fedeltà al business.

Tre derive passano sotto questi due controlli. L'agente può usare un secondo nome per un concetto che ne aveva già uno — «buono d'ordine» accanto a «ordine» in un ERP. Può reintrodurre una nozione che il team aveva abbandonato. Può creare una regola che ne contraddice un'altra, altrove nel codice: una fattura convalidata che torna modificabile attraverso un nuovo percorso.

Nessuna di queste derive rompe un test, perché i test riguardano il comportamento che l'agente ha appena scritto, non il modello di dominio che avrebbe dovuto rispettare.

Perché è importante

Il rischio cambia scala man mano che gli agenti si fanno carico di una quota crescente delle modifiche: ogni task è un'occasione per l'agente di ricostruire la propria interpretazione del business, e gli scostamenti si sommano senza che nessun controllo esistente li veda. Manca un riferimento comune del business, esterno al codice che l'agente modifica, con cui confrontare il suo lavoro.

Sfumature e limiti

Il fenomeno non è esclusivo degli agenti: uno sviluppatore umano introduce le stesse derive. Ciò che cambia sono il volume e la velocità, e il fatto che un agente non ha alcuna memoria delle discussioni che hanno fissato il vocabolario e le regole.

Domande aperte

• Quale quota delle derive di business introdotte da un agente viene davvero individuata da un revisore umano in code review?