L'AI software engineering e' la versione della disciplina in cui un agente scrive la maggior parte del codice mentre una persona resta responsabile delle decisioni che non hanno mai riguardato la digitazione: cosa costruire, cosa significa "corretto" per quella specifica codebase, e chi ne risponde una volta rilasciato. E' l'ingegneria del software con una nuova struttura dei costi, non una disciplina nuova, ed e' la lettura a livello di intera disciplina di un cambiamento che sta gia' ridisegnando la delivery del software.
Cercando il termine oggi si trova un'etichetta piu' istituzionale, il modo in cui un dipartimento universitario o una societa' di analisi chiamerebbero questo cambiamento, che il vocabolario quotidiano di chi lo pratica ogni giorno, che tende a usare piuttosto "agentic engineering". Stesso cambiamento di fondo, stesso volume di ricerca, pubblico diverso, e lo stesso punto cieco in entrambi i casi: quasi tutto quello che si scrive sotto l'uno o l'altro nome continua a contare il codice prodotto, non cosa succede alle pratiche costruite quando produrre codice era il passaggio scarso e costoso.
Quali pratiche esistono perche' scrivere codice costava caro?
L'ingegneria del software ha costruito diverse pratiche fondamentali attorno al costo di scrivere codice, non al suo rischio. Il riuso esiste perche' una funzione si scrive una volta e si richiama molte volte, invece di riscriverla. L'astrazione e i design pattern esistono perche' una modifica avvenga in un punto solo, non in dozzine. Le stime in punti storia o in ore esistono per pianificare in base a quanto tempo richiedono scrivere codice e correggere gli errori. Tutte e tre danno per scontato che produrre una riga di codice sia il passaggio scarso e costoso: un'assunzione valida per quattro decenni, dalle librerie di subroutine ai framework, perche' fino a poco tempo fa era vera, il tempo di uno sviluppatore era il vero limite a quanto software un team poteva rilasciare. Un agente che produce codice funzionante in pochi minuti non elimina il bisogno di riuso o di stime. Elimina il motivo per cui quelle pratiche erano state costruite in quel modo.
Cosa succede a riuso e astrazione quando scrivere costa quasi zero?
Non spariscono, si ricalibrano attorno a una scarsita' diversa. Il riuso serviva a risparmiare tempo di digitazione; ora il tempo di digitazione costa quasi niente, quindi il riuso vale in base a quanta superficie di verifica riduce: una funzione riusata e controllata batte cinque copie scritte dall'agente non perche' scriverne cinque costi di piu', ma perche' rivederne cinque costa di piu'. L'astrazione serviva a nascondere la complessita' di scrittura; ora vale in base a quanto nasconde decisioni che un agente potrebbe altrimenti prendere in modo incoerente in punti diversi di una codebase che non tiene in memoria come farebbe una persona. Le stime sono quelle che cambiano di piu': un punto storia era sempre un proxy per quanto tempo una persona avrebbe impiegato a scrivere e correggere qualcosa, e quel proxy si rompe nel momento in cui un agente scrive la bozza in pochi minuti. Quello che continua a richiedere tempo umano, e quello che un team dovrebbe davvero stimare, e' quanto tempo servira' per verificare e accettare il risultato, che il randomized controlled trial di METR del 2025 ha misurato in circa il 19% in piu' rispetto a lavorare senza AI, su task reali, nonostante gli sviluppatori avessero previsto in anticipo il 24% in meno.
Quali pratiche esistono per gestire il rischio, non il costo?
Un secondo gruppo di pratiche non ha mai riguardato il costo della digitazione: i test, la revisione del codice, una tracciabilita' di chi ha deciso cosa, e una persona nominata che si assume la responsabilita' prima del rilascio. Esistono per gestire il rischio che una modifica sbagliata o insicura arrivi in produzione, e quel rischio non si riduce quando il codice costa meno da produrre: cresce, perche' ogni settimana passa piu' codice dentro lo stesso processo di revisione e rilascio rispetto a prima. Il report DORA del 2025 ha misurato esattamente questa frattura a livello di settore: l'adozione dell'AI e' ora correlata positivamente con il throughput delle release, un'inversione rispetto all'anno precedente, e resta correlata negativamente con la stabilita' delle release. I team rilasciano piu' in fretta e una quota piu' grande di quello che rilasciano destabilizza qualcosa a valle, che e' esattamente il lato della disciplina che gestisce il rischio mentre non tiene il passo del lato che gestisce il costo.
Come si ricalibrano stime, riuso e astrazione?
| Pratica | Nata per gestire | Cosa ne decide il valore oggi | | --- | --- | --- | | Riuso del codice | Il costo di riscrivere la logica | Quanta superficie di revisione elimina | | Astrazione | Il costo di esprimere la complessita' | La coerenza tra sessioni diverse dell'agente | | Stime | Il tempo di scrittura e correzione | Il tempo di verifica e accettazione | | Test | (gia' orientati al rischio) | Copertura anche sui modi in cui fallisce un agente, non solo una persona | | Code review | (gia' orientata al rischio) | Volume di modifiche per revisore, ora molto piu' alto |
Le prime tre righe sono le pratiche che si stanno ricostruendo attorno a una scarsita' nuova. Le ultime due erano gia' gestione del rischio, e lo stesso Stack Overflow Developer Survey 2025 che registra il 69% degli sviluppatori che usano agenti di coding dichiarare una produttivita' individuale piu' alta trova anche solo il 17% dichiarare una collaborazione di team migliorata, che e' esattamente il divario tra scrivere piu' in fretta e un team che si fida davvero del risultato. Le pratiche sul lato costo sono diventate piu' facili da soddisfare. Quelle sul lato rischio sono diventate piu' difficili, semplicemente perche' oggi c'e' piu' codice per ogni revisore, non perche' il modo di rivedere sia cambiato.
A cosa serve un ingegnere senior, adesso?
Non a scrivere codice piu' in fretta di un junior, e sempre meno a scriverlo del tutto. Quello che non passa all'agente e' definire cosa significa "finito" prima che una sessione parta, giudicare se il risultato rispetta davvero quel criterio, e decidere, in modo tracciabile, che una determinata modifica e' sicura da rilasciare. Niente di tutto questo diventa automaticamente una prova una volta chiusa la sessione dell'agente: resta nella testa di una persona, a meno che qualcosa di duraturo non lo registri. Scegliere uno strumento da una qualunque lista dei migliori AI per programmare nel 2026 non risponde a questa domanda, perche' la capacita' dello strumento non e' mai stata il punto in cui vivevano le pratiche della disciplina legate al rischio.
Detent, l'impianto di delivery end-to-end (detent-ai.com), e' costruito per tenere quella prova al posto della memoria di una persona: cosa era stato definito, cosa un agente era autorizzato a toccare, cosa ha fatto, e chi lo ha accettato, collegati insieme dopo la fine della sessione. E' il livello che manca sopra ogni agente di codice, misurato lungo tutta la linea da Detent Bench, dalla richiesta al production-ready.