Se l’AI fosse esistita fin dall’inizio: il codice più economico non ha reso più facile decidere cosa costruire

Per la maggior parte della storia del software, la parte costosa era la costruzione. I team trascorrevano mesi trasformando idee in codice funzionante e quella scarsità ha plasmato tutto il modo in cui il lavoro veniva organizzato.

I road map venivano sequenziati intorno alla capacità di ingegneria disponibile; gli architetti guadagnavano il loro posto a tavola perché capivano sistemi che nessun altro conosceva; i product manager trascorrevano le loro settimane traducendo richieste aziendali vaghe in qualcosa che uno sviluppatore poteva eseguire. Scrivere software era il collo di bottiglia e, naturalmente, scriverlo era dove si trovava la leva.

Questo non è più vero e il cambiamento è avvenuto più velocemente di quanto la maggior parte dei leader di ingegneria abbia avuto il tempo di metabolizzare.

Gli strumenti di codifica AI hanno ridotto i costi di implementazione. Quindi, il lavoro che richiedeva settimane a un team di ingegneri ora richiede solo un paio d’ore a un agente. E l’assunzione ovvia era che una costruzione più veloce si sarebbe tradotta direttamente in un valore più veloce.

Cosa è successo, tuttavia, è più complicato: i team possono ora produrre più software di quanto sappiano cosa farne e la cosa che li rallenta ha silenziosamente spostato da un’altra parte.

“Non puoi applicare l’AI a un processo rotto”, ha detto Pablo Gamba, capo della tecnologia Americas presso la startup globale di software e soluzioni AI intive. “È come dare una pala più veloce a un lavoratore. Lavorerà più velocemente, ma solo nella direzione sbagliata.”

Esecuzione più veloce, stesso vecchio vincolo

Ogni grande inflessione nella tecnologia – internet, cloud e outsourcing – ha seguito una forma identica. Qualcosa che era costoso è diventato economico quasi da un giorno all’altro e tutto ciò che un’azienda aveva costruito sull’assunzione di quel costo è dovuto essere demolito e ricostruito.

Questa volta, la cosa che sta diventando economica è l’intelligenza tecnica applicata, che si rivela essere esattamente ciò per cui le società di servizi e i team di ingegneria hanno speso decenni a fare pagare, afferma Gamba.

L’esecuzione più economica non fa scomparire il vincolo, però. Si sposta solo in un posto meno visibile. Il collo di bottiglia della codifica, ad esempio, migrando a monte, ha accelerato l’implementazione, ma l’ostacolo è ora nella revisione del codice. Automatizzare la revisione del codice e si presenta nel testing e nella distribuzione; automatizzare anche questo e alla fine si ritrova sugli esseri umani che scrivono le specifiche che gli agenti stanno utilizzando.

Perché un agente può costruire solo ciò che è stato descritto con precisione sufficiente per agire senza indovinare.

È la trappola in cui molti team stanno cadendo ora, spesso senza accorgersene. Se puoi costruire quasi tutto in una frazione del tempo che ci voleva prima, il costo di costruire la cosa sbagliata aumenta, non diminuisce, perché scopriresti che eri sbagliato più velocemente e con più già spedito.

Un’assunzione che un tempo emergeva lentamente, nel corso di settimane di codifica manuale, può ora diventare infrastruttura portante prima che qualcuno pensi di metterla in discussione. La priorità, non la produzione grezza, finisce per decidere se l’investimento in AI si ripaga effettivamente.

In questo paradigma, Gamba ritiene che le aziende dovrebbero monitorare non la velocità di sviluppo, ma il ciclo completo dall’intenzione alla produzione. “Se migliori la velocità di sviluppo ma la QA è il tuo collo di bottiglia, hai solo raggiunto la QA più velocemente. Poi risolvi la QA e il collo di bottiglia si sposta alle richieste”, ha detto.

I numeri lo sostengono anche. Le imprese Fortune 50 che utilizzano lo sviluppo assistito da AI stanno spedendo commit 3-4 volte più velocemente dei loro pari, secondo ricerche della Cloud Security Alliance, ma introducendo nuove scoperte di sicurezza a un tasso di circa dieci volte superiore.

La velocità senza una destinazione chiara, in questo senso, non solo spreca sforzi; aumenta il rischio più velocemente di quanto la maggior parte dei team di sicurezza possa tenere il passo.

Introdurre le richieste in un linguaggio che l’AI possa effettivamente sfruttare

Se la definizione è dove si trova il vero vincolo ora, la soluzione non è più documentazione. È una documentazione diversa, scritta in una forma che un sistema AI possa eseguire senza riempire lacune di sua iniziativa.

Ciò significa ritirare il documento di richiesta scritto per un essere umano da interpretare con giudizio e sostituirlo con criteri di accettazione strutturati, modelli di dominio espliciti e test di contratto che specificano cosa una funzionalità non dovrebbe fare in modo altrettanto chiaro rispetto a ciò che dovrebbe.

Gli agenti, infatti, riempiono l’ambiguità allo stesso modo di un giovane ingegnere, con un’ipotesi coraggiosa. La differenza è che l’ipotesi di quest’ultimo arriva avvolta in un po’ di esitazione, un segnale a un collega senior, un senso che qualcosa potrebbe essere sbagliato.

L’ipotesi di un agente non assomiglia a nulla di tutto ciò. Si presenta come codice pulito, fluido e completamente formato e non c’è alcun margine in esso, anche quando è sbagliato.

Scrivere una specifica precisa abbastanza per sopravvivere a quel gap inizia a sentirsi meno come redigere un breve di prodotto e più come redigere un contratto. Si nomina ogni attore, si mappa ogni transizione di stato che il sistema è autorizzato a fare e si tiene conto dei casi limite invece di lasciarli silenziosamente al percorso felice, come fanno ancora la maggior parte dei documenti di richiesta.

I team che trattano questo come un compito di documentazione imparano a sue spese che un’intento vago produce solo software vago alla velocità della macchina.

I team che catturano effettivamente i guadagni di produttività sono quelli che trattano la scrittura di tali specifiche come una disciplina di ingegneria in proprio, con lo stesso controllo di versione, cicli di revisione e rigore di testing che un tempo erano riservati al codice stesso.

In parole di Gamba, AI-nativo non è il permesso di saltare il processo, ma la richiesta di ridisegnare da zero. “Molte organizzazioni stanno cercando di applicare l’AI ai vecchi processi. Questo non è trasformazione. Le organizzazioni AI-nativo iniziano con una domanda diversa: se l’AI fosse esistita fin dall’inizio, come designeremmo questo processo oggi?”

Manager di backlog, curatori di intento

Il prodotto, l’architettura e l’ingegneria un tempo funzionavano come tre funzioni separate con passaggi puliti tra loro: il prodotto decideva cosa costruire, l’architettura stabiliva come, l’ingegneria lo spediva.

Una volta che l’implementazione diventa economica e veloce, quei passaggi si trasformano nella parte più lenta della catena. Ciò che conta qui è chiunque possa tenere l’intero quadro a mente, tradurre l’intento in qualcosa che un agente possa eseguire e cogliere un’ipotesi sbagliata prima che si trasformi in codice spedito che nessuno voleva.

Quel ridisegno sta silenziosamente plasmando chi fa la definizione e cosa sia il lavoro stesso.

“Pensate a cosa sta succedendo al ruolo dell’ingegnere del software. Non stanno più solo scrivendo codice. Stanno supervisionando l’output degli agenti, definendo specifiche, preparando test, convalidando risultati. Ciò sta fondendo ciò che un tempo erano tre ruoli separati in uno”, ha detto Gamba.

In altre parole, ciò che è prezioso ora non è sapere come scrivere un biglietto o eseguire uno sprint. È sapere cosa significhi “grande” prima che il lavoro inizi, essere in grado di distinguere cosa sia intellettualmente interessante e cosa i clienti abbiano effettivamente bisogno e avere il coraggio di uccidere un’idea velocemente quando non supera chiaramente la barra.

Queste sono chiamate di giudizio che un tempo venivano distribuite su un product manager, un architetto e un tech lead che confrontavano appunti. Sta aumentando il numero di coloro che atterrano su chiunque sia più vicino a definire il lavoro per primo.

E vale anche la pena ricordare: nessuno di questo fa scomparire i titoli. Ma le linee tra loro stanno diventando più difficili da difendere, mentre le persone che prosperano in quella confusione sono quelle che agiscono come curatori di intento.

Esecuzione veloce senza guardrail non è una vittoria

C’è un rischio che è facile perdere di vista una volta che l’intento è chiaro e la pipeline AI sta effettivamente ronzando: l’esecuzione veloce e ben definita può ancora introdurre fallimenti che un processo più lento e più umano-mediatizzato avrebbe catturato quasi per caso.

I numeri qui non sono nemmeno vicini. I test di primavera 2026 di Veracode su modelli leader hanno trovato che solo il 55% dei compiti di generazione di codice produceva output sicuro quando non era fornita alcuna guida di sicurezza esplicita, un numero che è appena cambiato in due anni anche se l’accuratezza funzionale è saltata considerevolmente.

È chiaro che ottenere la sintassi giusta ha smesso di essere la parte difficile da un po’ di tempo. Le chiamate di giudizio che un ingegnere umano un tempo faceva istintivamente mentre digitava, intorno alla sicurezza, alla conformità e ai dati che dovrebbero e non dovrebbero toccare il sistema, sono le parti che è difficile sostituire.

Ciò significa che la stessa rigore applicata alla definizione di cosa costruire deve estendersi alla definizione di cosa è fuori limite, come ad esempio i confini di conformità, le regole di gestione dei dati e le costrizioni etiche espresse con la stessa cura delle richieste funzionali.

Lasciare queste implicite e sperare che un agente le inferisca correttamente è lo stesso errore che lasciare le richieste di prodotto vaghe e sperare che la costruzione si riveli comunque fine.

Cosa significa leadership

Nessuno di questo argomenta contro lo sviluppo accelerato da AI; la costruzione non è mai stata più veloce o più economica e non c’è modo di rimettere il genio nella bottiglia.

Ma ciò che non è diventato più facile, e probabilmente più difficile, è decidere con precisione reale cosa vale la pena costruire, descriverlo abbastanza bene perché una macchina possa eseguirlo fedelmente e tracciare le linee che non è autorizzato a superare mentre lo fa.

A livello aziendale, i team che stanno avanzando non sono quelli con gli agenti di codifica più veloci, quella parte è chiara. Sono quelli che hanno capito, prima dei loro concorrenti, che la definizione sarebbe sempre stata il problema più difficile – e hanno iniziato a trattarla come tale.