Per "sviluppo software con l'AI" oggi si intende costruire software di produzione in cui un agente scrive e modifica una parte consistente del codice, dentro un processo che una persona continua a possedere: cosa si costruisce, cosa vuol dire "finito", e chi firma prima che qualcosa vada in produzione. Gran parte del settore tiene il punteggio contando il codice prodotto. È l'unità di misura sbagliata.
Cercando questo termine oggi si trovano due tipi di pagine: quella di un vendor che vende un agente, o un pezzo di opinione che discute se l'AI sostituirà gli sviluppatori. Nessuna delle due risponde alla domanda che ha davvero un delivery owner, cioè cosa cambia nel modo in cui si costruisce software quando un agente scrive una parte del codice, e cosa invece non cambia affatto.
Cosa si intende oggi per "sviluppo software con l'AI"?
Il termine copre in pratica un ventaglio ampio: uno sviluppatore che accetta funzioni scritte da un agente dentro l'IDE, un agente headless che porta a termine un intero ticket durante la notte, e, all'estremo opposto, qualcuno senza background tecnico che pubblica un'app di cui non ha mai letto il codice. Tutti e tre finiscono sotto l'etichetta sviluppo software con l'AI, perché in tutti e tre il codice passa da un modello prima che una persona lo veda. Quello che cambia non è se l'AI ha scritto il codice. È quanto del processo che sta intorno, decidere cosa costruire, controllare cosa è tornato indietro, decidere se è sicuro pubblicarlo, continua ad accadere di proposito.
Costruire software ha sempre richiesto cinque cose: capire cosa costruire (analisi), fornire a chi costruisce i fatti giusti da cui partire (contesto), scrivere il codice vero e proprio, controllare che il risultato faccia quello che era stato chiesto (verifica), e qualcuno che si prenda la responsabilità di pubblicarlo (accettazione). Gli agenti di coding hanno fatto progressi reali e misurabili esattamente su una di queste cinque cose: produrre codice più in fretta. Le altre quattro, decidere cosa costruire, fornire il contesto giusto, verificare il risultato, accettarne la responsabilità, passano ancora per una persona, perché nessuna delle quattro si risolve generando testo più velocemente. Giudicare lo sviluppo software con l'AI solo da quanto codice produce un agente misura il passaggio che era già la risorsa meno scarsa delle cinque, e non dice nulla sui quattro che sono sempre stati il lavoro vero. È l'errore che questo termine continua a ripetere.
Scrivere codice è mai stato il vero collo di bottiglia?
L'ingegneria del software considera la questione chiusa dal 1986, quando il saggio di Fred Brooks "No Silver Bullet" ha diviso la difficoltà di costruire software in due tipi. La complessità essenziale è il problema in sé: la logica, i casi limite, i requisiti che si contraddicono a vicenda. La complessità accidentale è l'attrito di esprimere quel problema in un dato linguaggio e in una data toolchain, sintassi, boilerplate, la meccanica di far entrare un'idea in un file che il computer eseguirà. Ogni progresso da allora, linguaggi di livello più alto, framework, autocomplete, e adesso gli agenti generativi, ha attaccato la complessità accidentale, perché è la parte trattabile da automatizzare. Nessuno di questi progressi ha toccato la complessità essenziale, perché decidere cosa deve fare davvero il software non è mai stato un problema di battitura.
Anche la versione più stretta dell'argomento, cioè che almeno gli agenti hanno reso più veloce la scrittura, non regge fino in fondo. Uno studio controllato randomizzato di METR pubblicato a luglio 2025 ha fatto completare a 16 sviluppatori open source esperti 246 task reali su codebase che conoscevano bene, metà con strumenti AI consentiti e metà senza. Prima di iniziare, prevedevano che l'AI avrebbe tagliato il tempo di completamento di circa il 24%. Il risultato misurato è andato nella direzione opposta: i task con l'AI consentita hanno richiesto circa il 19% in più, e gli sviluppatori restavano comunque convinti di essere stati più veloci di circa il 20%. Se l'unico passaggio che l'AI avrebbe già dovuto risolvere, produrre codice in fretta, non diventa affidabilmente più veloce quando lo si misura invece di stimarlo a sensazione, l'idea che lo sviluppo software con l'AI si riduca a un problema di generazione di codice era sbagliata ancora prima di iniziare il resto del ragionamento.
Dove va davvero il tempo, prima e dopo gli agenti AI?
Il settore ha ormai abbastanza dati di sondaggio per vedere dove è finito il tempo liberato, e non è evaporato. Il Dev Barometer Q3 2026 di BairesDev, un sondaggio su 705 sviluppatori e 41 responsabili di ingegneria pubblicato il 15 settembre 2026, ha trovato che il 79% degli sviluppatori oggi passa meno di metà della settimana lavorativa a scrivere codice nuovo da zero. Sembrerebbe proprio la storia di produttività che lo sviluppo software con l'AI dovrebbe consegnare. Lo stesso sondaggio ha trovato che il 67% di quegli sviluppatori passa più tempo a rivedere codice generato dall'AI rispetto a un anno prima, e il 52% passa più tempo a fare debug di problemi introdotti dall'AI. Le ore non sono sparite. Si sono spostate di un gradino più in basso nella pipeline, dalla scrittura al controllo.
| Prima degli agenti AI | Dopo gli agenti AI | |
|---|---|---|
| Dove vanno le ore | Scrivere e modificare codice a mano | Rivedere, fare debug e verificare cosa ha prodotto l'agente |
| La competenza scarsa | Scrivere codice corretto in fretta | Specificare l'intento con precisione, giudicare l'output in fretta |
| Il collo di bottiglia | Produrre abbastanza codice | Tutto quello che succede una volta che il codice esiste già |
| Chi risponde di una modifica pubblicata | Chi l'ha scritta | Chi l'ha approvata, l'abbia scritta o meno |
Cosa cambia nelle proporzioni, e cosa resta esattamente uguale?
Il DORA report 2025, pubblicato il 23 settembre 2025, ha trovato qualcosa che sembra contraddittorio finché non si separano le due affermazioni: l'adozione dell'AI oggi è correlata positivamente al throughput di consegna del software, un'inversione rispetto al risultato dell'anno precedente, e resta correlata negativamente alla stabilità della consegna. I team spediscono di più, più in fretta, e una quota più grande di quello che spediscono destabilizza qualcosa a valle. La spiegazione di DORA è che l'AI accelera lo sviluppo, ma quell'accelerazione espone debolezze che c'erano già: un team con verifica debole e criteri di accettazione poco chiari non vede quei problemi risolti da un agente più veloce, li vede moltiplicati.
È tutto qui lo spostamento delle proporzioni: il costo di produrre una riga di codice continua a scendere, quindi una quota più grande dello sforzo totale di un team oggi sta nei quattro passaggi che l'AI non ha toccato, decidere cosa costruire, fornire all'agente il contesto giusto, verificare cosa ha fatto, accettarne la responsabilità del risultato. Nessuno di questi quattro passaggi è diventato più facile. Due sono diventati più difficili, in pratica, semplicemente perché ogni settimana ci passa attraverso più codice di quanto ne passasse prima.
Come si gestisce in pratica: contratto, verifica, accettazione
Per un team, la versione pratica di tutto questo è una disciplina, non un atteggiamento. Si comincia trattando il coding agentico come un loop che ha bisogno di un contratto prima di partire: cosa l'agente è autorizzato a toccare, cosa conta come finito, quali prove devono esistere prima che qualcuno dichiari il task concluso. Si continua con una verifica che non prende come prova il resoconto dell'agente su se stesso, una suite di test, una build, un controllo che gira su una macchina, non un riassunto scritto dallo stesso modello che ha scritto il codice. Si chiude con un passaggio di accettazione umana che viene registrato da qualche parte di duraturo, non dato per scontato perché nessuno si è lamentato.
Niente di tutto questo è un motivo per rallentare come un team sceglie il proprio assistente di coding AI: la domanda sullo strumento e la domanda sul processo sono separate, e un agente più veloce dentro un processo disciplinato è sempre meglio dello stesso agente senza nessun processo. Quello che la disciplina compra è la parte che la maggior parte delle classifiche di agenti di coding non si pone: se un team può ancora mostrare, a cose fatte, cosa era stato chiesto, cosa l'agente era autorizzato a fare, cosa ha fatto davvero, e chi lo ha accettato.
Cosa misurare al posto delle righe di codice?
Alcuni numeri si correlano meglio, rispetto a quanto controllo un team ha davvero sulla propria delivery, di quanto abbiano mai fatto le righe di codice scritte a settimana: la quota di modifiche pubblicate con una ragione d'esistere registrata e verificabile; il tempo tra il momento in cui un agente finisce un task e quello in cui una persona lo accetta formalmente, non il tempo per arrivare a una prima bozza; il tasso di incidenti in produzione riconducibili a una modifica che nessuno ha rivisto con attenzione; e, nella versione più diretta di tutte e tre, se un responsabile di delivery potrebbe consegnare a un cliente la storia completa di una modifica specifica, sei mesi dopo, senza doverla ricostruire a memoria o da una chat.
È questo il confine su cui è costruito il livello che manca sopra ogni agente di coding: non scrivere codice migliore, cosa che gli agenti già fanno, ma tenere insieme cosa un team intendeva costruire, cosa ha autorizzato, cosa è successo, e chi ha firmato, in qualcosa che sopravvive alla sessione e a chi l'ha lanciata. Detent, l'impianto di delivery end-to-end (detent-ai.com), è costruito esattamente su quel confine, partendo dal presupposto che l'unità di misura attuale del settore, il codice prodotto, non è mai stata quella che contava davvero.