Il dibattito italiano sugli agenti AI per lo sviluppo software si misura quasi sempre su una sola domanda: quanto codice scrivono, e quanto in fretta. Chi lavora su commessa, per più clienti, con un contratto che parla di accettazione e di collaudo, si trova davanti a una domanda diversa, che quel dibattito non pone: di chi è il codice che l'agente ha scritto, chi ne risponde davanti al cliente, e cosa va consegnato insieme al software perché quella risposta resti possibile anche mesi dopo.
Cosa fa un agente AI, detto senza entusiasmo?
Un agente AI per lo sviluppo software è un programma che, dato un obiettivo scritto in linguaggio naturale, decide da solo quali file leggere, quali modificare, quali comandi eseguire e quando considerare il compito finito, senza che una persona approvi ogni singolo passaggio intermedio.
Per una software house che lavora su commessa, questo cambia il rapporto con il codice scritto per un cliente: non è più solo lo sviluppatore a decidere come arrivare al risultato, lo decide in parte l'agente, dentro i confini che qualcuno in azienda gli ha dato. Il contratto con il cliente, però, non distingue tra riga scritta da una persona e riga scritta da un agente: parla di consegna, di conformità alle specifiche, di responsabilità verso chi ha commissionato il lavoro. Chi introduce un agente nel flusso su commessa aggiunge un livello di autonomia nell'esecuzione senza toccare il livello di responsabilità contrattuale, che resta intero e resta della software house, non dell'agente né del fornitore del modello.
Il codice è del cliente: cosa cambia subito?
Nella maggior parte dei contratti su commessa, la proprietà del codice passa al cliente alla consegna o al pagamento, indipendentemente da chi lo ha scritto: questo non cambia con un agente in mezzo. Le condizioni d'uso dei fornitori di agenti più diffusi assegnano oggi all'azienda che li usa i diritti sull'output generato, quindi la catena di proprietà formale resta intatta.
Quello che cambia davvero è un altro punto, meno formale ma più concreto: chi può spiegare, mesi dopo, perché una parte del codice è scritta in un certo modo. Con uno sviluppatore, la risposta è quasi sempre "chiediamo a chi l'ha scritta". Con un agente lanciato da una persona che nel frattempo ha cambiato progetto, o l'azienda ha cambiato collaboratore, quella persona non basta più: serve un record della sessione, non solo un ricordo.
Cosa cambia in accettazione e collaudo quando il lavoro l'ha fatto un agente?
Il collaudo su un contratto d'appalto di software esiste per verificare, prima del pagamento finale, che il lavoro consegnato corrisponda a quanto pattuito. Storicamente controlla il risultato: i test passano, le funzionalità ci sono, i requisiti sono soddisfatti. Quando parte del codice arriva da un agente, il collaudo dovrebbe controllare anche un livello a monte, e oggi quasi nessuno lo fa: l'agente aveva davvero il permesso di toccare quei file, in quello scope, con quel livello di autonomia?
Fidarsi della sensazione interna che "il lavoro va bene" perché lo si è visto scorrere durante la sessione è più fragile di quanto sembri. Lo studio METR del 2025 (RCT su sviluppatori esperti che lavorano su repository reali) ha misurato che chi usa strumenti AI si percepisce il 20% più veloce a lavoro finito, mentre in realtà è risultato il 19% più lento, pur avendo previsto in anticipo di essere il 24% più rapido. Se la percezione di velocità durante la sessione è così poco affidabile, lo stesso vale per la percezione di correttezza: serve una verifica fatta fuori dalla sessione, non l'impressione di chi l'ha lanciata.
Cosa consegni insieme al software?
| Sviluppo tradizionale | Con un agente nel loop | |
|---|---|---|
| Chi ha scritto la riga | Una persona identificabile, nel commit | Un agente, autorizzato da una persona |
| Cosa prova che era autorizzato | Il ticket o la commessa, di solito | Spesso niente, solo il prompt nella chat |
| Se il cliente chiede conto mesi dopo | Si chiede a chi ha scritto quella riga | Bisogna sapere chi ha lanciato la sessione |
| Cosa serve al collaudo | Test che passano, requisiti coperti | Test che passano più prova dello scope autorizzato |
La riga di destra, oggi, quasi nessuno la scrive. Gli agenti di coding vengono giudicati su quanto codice producono e quanto è buono, non su cosa resta come prova quando la sessione si chiude. Per una commessa, quella prova non è un extra: è la differenza tra poter rispondere a un cliente e dover ricostruire a memoria cosa è successo.
Come si introducono gli agenti senza perdere il controllo della commessa
Qualche punto concreto, prima di lasciare un agente lavorare su codice che poi finisce a un cliente:
- Scrivere per iscritto, per commessa, quali file e quali repository l'agente può toccare, non lasciarlo dedurre dal contesto della chat.
- Tenere un log della sessione collegato al task e alla commessa, non solo alla cronologia dello strumento.
- Far entrare quel log nella fase di collaudo contrattuale, non solo nella revisione tecnica interna.
- Non accettare "i test passano" come unica prova quando lo ha dichiarato lo stesso agente che ha scritto il codice, per lo stesso motivo per cui uno sviluppatore non revisiona da solo il proprio pull request in una commessa seria.
- Firmare la consegna con il nome di chi ha revisionato, non con il nome dell'agente o dello strumento.
Nessuno di questi punti frena l'adozione: lo sviluppo agentico resta una decisione di processo, non un motivo per rallentare. Cambia solo cosa un'azienda deve avere pronto quando un cliente, invece di chiedere una nuova funzionalità, chiede conto di quella già consegnata. È lo stesso criterio che Detent Bench misura sulla linea dal requisito al rilascio: non solo se il codice funziona, ma chi può ancora provarlo dopo che l'agente ha chiuso la sessione. Il posizionamento di Detent, l'impianto di delivery end-to-end (detent-ai.com), parte proprio da questa domanda su una commessa reale, non da una firma finale scollegata dal lavoro che l'ha preceduta.