Quando il codice non è più il problema ma lo diventa tutto il resto

Nel 2001 il manifesto Agile dichiarava che il software funzionante contava più della documentazione esaustiva; nel 2026 il settore sembra aver fatto un ulteriore salto logico, o forse un elegante scivolone epistemologico: il codice non è più il collo di bottiglia, ma il sistema che lo produce sì. L’illusione collettiva, alimentata da demo sempre più spettacolari e da pitch deck che odorano di inevitabilità tecnologica, suggerisce che “scrivere codice” sia ormai un problema risolto. La realtà, come spesso accade, è meno teatrale e più costosa.

Figure come Boris Cherny hanno contribuito a formalizzare questo cambio di paradigma, mentre strumenti come Claude stanno ridefinendo il ruolo dello sviluppatore da artigiano del codice a orchestratore di agenti. Il punto, tuttavia, non è la capacità degli agenti di generare codice, ormai sorprendentemente alta; il punto è ciò che accade dopo. O meglio, ciò che accade mentre accade.

Il 2026 è l’anno in cui le status page sono diventate il vero specchio della maturità AI delle aziende. Non più verdi rassicuranti, ma arancioni persistenti, quasi un nuovo standard cromatico per l’industria. L’arancione è il colore della degradazione controllata, del sistema che non è rotto ma neanche sano, del software che funziona ma non ispira fiducia. È anche il colore della dissonanza cognitiva tra ciò che promettiamo agli investitori e ciò che i team DevOps affrontano quotidianamente.

Il fenomeno che molti chiamano “vibe coding” merita una breve riflessione semantica. L’idea che si possa costruire software complesso partendo da prompt vaghi, affidandosi a una sorta di intuizione sintetica dell’AI, è seducente quanto pericolosa. Non perché non funzioni, ma perché funziona troppo bene nel breve termine. Come ogni leva ad alta potenza, amplifica sia la produttività che l’entropia.

Gli strumenti di nuova generazione, da ambienti come Cursor fino a piattaforme emergenti come Windsurf, permettono a team minuscoli di raggiungere output che fino a pochi anni fa richiedevano interi reparti. Il mito della “half-pizza team” non è mai stato così vicino alla realtà. Due o tre ingegneri, armati di agenti autonomi, possono costruire feature complesse in tempi ridicoli. Il problema è che nessuno ha ancora capito come mantenere queste feature vive, coerenti e sicure nel tempo.

La velocità di generazione del codice ha superato la capacità umana di comprenderlo. Questo non è un dettaglio tecnico, è un cambio di regime cognitivo. Il debito tecnico non è più una conseguenza di cattive decisioni, ma una proprietà emergente del sistema. Si accumula automaticamente, come polvere in una stanza senza finestre.

Il risultato è un aumento esponenziale delle regressioni. Non errori banali, ma bug sottili, effetti collaterali non lineari, interazioni tra componenti che nessuno ha esplicitamente progettato. L’AI non dimentica nulla, ma non capisce davvero nulla; replica pattern, li estende, li combina, e nel farlo introduce complessità che sfugge ai modelli mentali umani.

Qui entra in gioco quello che alcuni iniziano a chiamare ContextOps. Non una buzzword, ma un tentativo disperato di dare ordine al caos. Se DevOps era la risposta alla complessità infrastrutturale e MLOps a quella dei modelli, ContextOps nasce per gestire il contesto degli agenti. Perché il vero problema non è il codice, ma il contesto in cui quel codice viene generato.

Gli agenti non lavorano nel vuoto. Hanno bisogno di specifiche, memoria, vincoli, storia. E soprattutto coerenza. Quando più agenti operano su repository diversi, con contesti parziali o divergenti, il risultato è una deriva sistemica. Decisioni prese ieri vengono dimenticate oggi, pattern stabiliti vengono ignorati domani. Il software diventa un organismo con amnesia selettiva.

Il paradosso è evidente. Più investiamo in autonomia, più aumenta il bisogno di controllo. Più deleghiamo all’AI, più dobbiamo costruire sistemi per verificare ciò che l’AI fa. Il concetto di “output non affidabile” è tornato di moda, ma con una scala completamente diversa. Non si tratta più di controllare una funzione, ma intere architetture generate da agenti.

Le aziende più avanzate stanno già cambiando approccio. Non si fidano più dell’output dell’AI, lo trattano come input non attendibile. Ogni riga di codice generata passa attraverso pipeline di verifica automatica, scansioni di sicurezza, test differenziali. Il codice AI è colpevole fino a prova contraria.

Questo shift culturale è forse più importante della tecnologia stessa. Significa accettare che l’AI non è un sostituto dello sviluppatore, ma un moltiplicatore di rischio oltre che di produttività. Significa riconoscere che la velocità senza governance è solo caos accelerato.

Nel frattempo, i costi nascosti iniziano a emergere. E non parliamo solo di costi computazionali, già significativi quando si orchestrano più agenti complessi. Parliamo di costi organizzativi. Più codice significa più manutenzione, più debugging, più coordinamento. Il ROI dell’AI non è lineare, e sicuramente non è immediato.

Le startup, come sempre, sono le prime a spingersi oltre il limite. Alcune riescono a sfruttare questo paradigma per scalare rapidamente, altre si schiantano contro la realtà operativa. Le grandi aziende, più lente ma più strutturate, stanno adottando un approccio più cauto. Introducono agenti, ma li incapsulano in processi rigidi. Automatizzano, ma verificano. Accelerano, ma con il freno a mano tirato.

Il futuro, se vogliamo essere onesti, non è né completamente ottimistico né apocalittico. È semplicemente più complesso. Il sogno di “risolvere” il software engineering era forse mal posto fin dall’inizio. Il software non è solo codice, è sistema, contesto, interazione, evoluzione.

Una frase che circola sempre più spesso nei corridoi delle aziende tecnologiche suona più o meno così: “We didn’t solve coding, we moved the problem.” Non abbiamo eliminato la complessità, l’abbiamo spostata. Dal codice alla sua gestione. Dallo sviluppatore all’organizzazione. Dalla sintassi al sistema.

In questo senso, il 2026 non è un punto di arrivo, ma una fase di transizione. Un momento in cui l’industria deve decidere se continuare a inseguire la velocità o iniziare a investire seriamente nella stabilità. Perché, alla fine, il software non viene giudicato per quanto velocemente è stato scritto, ma per quanto bene funziona quando nessuno lo guarda.

La vera domanda, quindi, non è se l’AI possa scrivere codice. Può farlo, e lo fa già. La domanda è se siamo pronti a gestire le conseguenze di questa capacità. E, come spesso accade, la risposta non è tecnica, ma organizzativa.

Chi continuerà a trattare l’AI come una scorciatoia scoprirà presto che le scorciatoie hanno un costo. Chi invece la vedrà per quello che è, un acceleratore potente ma instabile, potrà forse costruire sistemi più resilienti. Non perfetti, ma almeno controllabili.

Nel frattempo, le status page resteranno arancioni. Non per errore, ma per design. Perché in un mondo dove il codice è facile, la stabilità diventa il vero vantaggio competitivo. E quello, ironicamente, è un problema molto più umano che artificiale.