Junior Developer nell’era dell’AI

L’avvento dell’AI generativa ha reso una verità storica dell’ingegneria del software ancor più evidente e ineludibile: scrivere codice non equivale a produrre software. L’AI accelera potentemente la generazione di output, ma non riduce, anzi amplifica, la complessità di ciò che rende il software affidabile nel tempo: qualità, sicurezza, manutenibilità, comprensione del contesto e responsabilità sulle conseguenze operative. 

In questo scenario, il Junior Developer diventa un indicatore anticipatore dello stato di salute dell’intero sistema socio-tecnico in cui si colloca il processo di realizzazione di un software. Non perché sia il “punto debole”, ma perché è il punto in cui il sistema si rivela. Dove esistono feedback reali, criteri di qualità espliciti, sicurezza psicologica e capacità organizzative mature, l’AI può accelerare l’apprendimento. Dove questi elementi mancano, l’AI accelera solo la produzione di fragilità, mascherandola da produttività. 

L’articolo mostra, sulla base di evidenze empiriche solide, come l’AI stia spostando il baricentro del valore lungo la value stream del software: l’output costa sempre meno, il giudizio costa sempre di più. Studi recenti indicano aumenti di produttività misurati in termini di task completati, soprattutto per i profili meno esperti, ma segnalano anche una crescente divergenza tra velocità percepita e performance reale. Il rischio economico-organizzativo è che il throughput venga scambiato per valore, mentre la verifica (qualità, sicurezza, affidabilità) diventa il collo di bottiglia e il costo si sposta a valle. 

In questo contesto, l’università gioca un ruolo essenziale ma delimitato: può fornire agli studenti di Computer Science fondamenta concettuali robuste, non replicare l’esperienza socio-tecnica aziendale. L’apprendistato ingegneristico inizia davvero solo nei sistemi di lavoro reali, e la sua qualità dipende dal modo in cui le organizzazioni progettano guardrail tecnici, guardrail sociali e cicli completi di apprendimento che trasformano il lavoro quotidiano in capacità trasferibile, non in semplice accumulo di task. 

L’articolo sostiene che il vero tema non sia “se usare l’AI”, ma come assorbirla in sistemi organizzativi capaci di apprendere. In questo senso, l’Agile non viene proposto come metodologia o liturgia, ma come epistemologia operativa: un insieme di meccanismi, quali  feedback rapidi, trasparenza sui trade-off, responsabilità condivisa, che riallineano produzione e verifica in sistemi complessi. Nell’era dell’AI, dove la produzione accelera molto più rapidamente della capacità di valutare le conseguenze, questi meccanismi diventano infrastruttura cognitiva, non optional organizzativi. 

Infine, l’articolo propone una lettura non ideologica dell’AI come amplificatore: amplifica la qualità quando il sistema è progettato per apprendere, amplifica il debito quando il sistema è progettato solo per produrre output. Da qui una tesi netta: nell’era dell’AI non formiamo Junior per scrivere codice più velocemente, ma per distinguere ciò che funziona da ciò che reggerà. Le organizzazioni che sapranno progettare sistemi di apprendistato reale non otterranno solo maggiore produttività di breve periodo, ma software più affidabile, meno rischio nascosto in debito tecnico e una capacità superiore di adattarsi ai cambiamenti tecnologici futuri.

C’è una verità che l’industria del software ha sempre conosciuto, ma che l’avvento dell’AI generativa rende ormai impossibile ignorare: scrivere codice non è equivalente a produrre software. La prima attività può essere fortemente accelerata, la seconda richiede un sistema socio-tecnico fatto di architetture, qualità, disciplina operativa, decisioni condivise, teamwork e, soprattutto, apprendistato. 

E l’apprendistato, per definizione, non è facilmente comprimibile: è tempo + contesto + feedback. Non si acquista “a pacchetto”, non si risolve con uno strumento, non si elimina imboccando scorciatoie tecnologiche. 

Il Junior Developer di oggi si affaccia sul mercato del lavoro immerso in un paradosso strutturale. Da un lato, il suo potenziale di output appare esplosivo: grazie all’AI, può generare rapidamente codice plausibile, prototipi, refactoring e documentazione tecnica. Tuttavia, le evidenze empiriche più solide misurano ancora soprattutto l’output (per esempio velocità di esecuzione dei task), mentre catturano meno l’outcome di lungo periodo: affidabilità, sicurezza e manutenibilità. Per un profilo junior, il rischio concreto è confondere la velocità di esecuzione con la competenza reale: si chiudono più task, ma non è detto che aumenti la capacità di prevenire difetti, gestire regressioni e ragionare sui trade-off. [3] 

Dall’altro lato, cresce il pericolo di non sviluppare mai quel giudizio ingegneristico che distingue chi si limita a scrivere codice da chi è capace di governare sistemi software nel tempo. Per “giudizio” non intendo un talento generico né una “sensazione da senior”: intendo la capacità di rendere espliciti i trade-off, falsificare una soluzione con test/monitoraggio (non solo “farla funzionare”), anticipare impatti sistemici (integrazione, dati, failure modes), imparare dal comportamento in produzione e incorporare quell’apprendimento nel design. L’AI semplifica la produzione di codice proprio nella fase in cui la difficoltà dovrebbe essere un alleato dell’apprendimento: è attraverso lo sforzo cognitivo che si impara a decodificare il contesto e a interpretare segnali deboli che l’automazione tende a mascherare. [5] 

Questo tema non riguarda solo i neolaureati. Riguarda l’intero ecosistema del software, perché la qualità della crescita degli Junior è uno dei principali determinanti della qualità del software nel medio-lungo periodo e quindi del rischio operativo, della resilienza e della competitività delle organizzazioni che quel software lo utilizzano.

È importante riconoscere che le università non sono ferme. Le linee guida internazionali più autorevoli, come il Computer Science Curricula 2023 (CS2023), consolidano l’idea che la formazione in Computer Science debba includere, accanto ai fondamenti teorici, anche dimensioni professionali: lavoro in team, qualità del software, sicurezza, responsabilità e impatti sistemici. [1] 

Tuttavia, è importante evitare una lettura ingenua o strumentale di questa evoluzione. Una parte significativa della comunità accademica sostiene, con buone ragioni, che il compito primario dell’università non sia replicare l’ecosistema enterprise né inseguire tool contingenti, ma costruire fondamenta concettuali robuste e durature: capacità di astrazione, modelli formali, pensiero algoritmico, comprensione dei sistemi complessi. In questa prospettiva, una “professionalizzazione precoce” rischia di ridurre l’università a un centro di addestramento su tool contingenti, indebolendo proprio le competenze che consentono di adattarsi nel tempo (astrazione, modelli, ragionamento sui sistemi). [1] 

Questa posizione non è in contraddizione con quanto osserviamo nell’industria, al contrario, ne chiarisce il confine. L’università può insegnare principi e metodi, ma non può, né dovrebbe, riprodurre in modo sistematico l’esperienza socio-tecnica in cui il software vive realmente: codebase legacy, pipeline CI/CD con vincoli storici, incidenti in produzione, trade-off quotidiani tra stabilità, velocità, compliance e sicurezza. 

Per questo, l’esperienza resta un capitale che si accumula solo attraversando cicli completi di lavoro in contesti reali. Il punto, allora, non è chiedere all’università di “fare meglio il mestiere delle aziende”, ma riconoscere che l’uscita dall’università non segna la fine della formazione, bensì l’inizio dell’apprendistato ingegneristico.

L’AI generativa abbassa drasticamente il costo marginale di produrre codice. Questo dato, isolato, alimenta una narrazione semplicistica: se l’AI scrive codice, allora il lavoro vale meno. La contro-tesi più diffusa è che basterà “più AI” per compensare, ma le evidenze disponibili sono coerenti con l’ipotesi che senza capability di verifica e feedback il sistema accelera soprattutto l’accumulo di fragilità. 

In realtà, l’AI sposta il baricentro del costo e del valore lungo l’intero ciclo di sviluppo: il costo non scompare, si redistribuisce. Qui riprendo una posizione autoriale che ho articolato in modo esteso nel mio contributo “AI e sviluppo software: lo specchio della maturità organizzativa”: l’AI tende ad amplificare punti di forza e debolezza della value stream end-to-end, rendendo più evidenti (e più rapidi) sia i benefici sia le fratture del sistema. [9] 

E ciò che diventa più costoso è proprio ciò che per un Junior è più difficile da padroneggiare: comprendere il contesto architetturale, valutare impatti sistemici, progettare test robusti, interpretare segnali in produzione, leggere log e tracing, ragionare su affidabilità, sicurezza e performance. 

Qui è importante tenere insieme due famiglie di evidenze che descrivono lo stesso fenomeno: eterogeneità degli effetti e capability organizzative. 

Da un lato, i report DORA mostrano da anni che la performance non dipende dalla velocità del singolo, ma da capability organizzative: pratiche, piattaforme, cultura, feedback loop. L’introduzione dell’AI non garantisce automaticamente miglioramenti, in diversi contesti emergono segnali di trade-off e fragilità se le capability non reggono l’aumento di throughput. In altre parole, l’AI non sostituisce le capability, le stress-testa: se i feedback loop e i criteri di qualità non scalano, l’aumento di throughput tende a trasformarsi in rework, incidenti e debito tecnico. [2] 

Dall’altro, tre esperimenti sul campo in aziende reali (Microsoft, Accenture e una Fortune 100 anonima) mostrano che l’accesso a un assistant di coding è associato a un aumento dei task completati, con guadagni più marcati per chi ha meno esperienza. Il punto, quindi, è semplice: l’AI è ormai un passaggio necessario per sostenere produttività e competitività, ma i benefici dipendono da capability (qualità verificabile, feedback loop rapidi, criteri di done espliciti) e da una governance che impedisca che la velocità sostituisca il giudizio. [3] 

È proprio questa non linearità che spiega anche risultati controintuitivi. Uno studio controllato randomizzato di METR su sviluppatori esperti che lavoravano su repository open source noti segnala che, con tool AI di inizio 2025, il tempo medio di completamento dei task aumenta, mentre gli sviluppatori percepiscono soggettivamente di essere stati più veloci. È importante esplicitare il contesto: sviluppatori senior, repository OSS già familiari; la trasferibilità diretta all’enterprise non è automatica. Ma il segnale sulla divergenza tra percezione e performance è rilevante perché colpisce un meccanismo generale: più output “plausibile” può aumentare il carico di controllo e coordinamento. [4] 

A questo si aggiunge un ulteriore elemento, che va interpretato con attenzione. Studi provenienti dalla comunità scientifica di Human–Computer Interaction, condotti su knowledge workers e basati su misure auto-riportate, mostrano che una maggiore fiducia nella GenAI è associata a una riduzione dello sforzo cognitivo percepito e del pensiero critico dichiarato. È evidenza osservazionale, non una prova causale né uno studio specifico su sviluppatori enterprise; ma il meccanismo è utile per identificare una zona di rischio plausibile per gli Junior: una delega cognitiva precoce favorita da risposte rapide e plausibili. [5] 

Detto questo, è importante evitare una lettura caricaturale. L’AI può creare valore reale anche per gli Junior, e in molti contesti è già una adozione di fatto. I benefici, però, non sono automatici: dipendono da condizioni verificabili, tra cui definizione condivisa di qualità, feedback loop rapidi, cross-check sistematico, guardrail che impediscano che la velocità sostituisca il giudizio. [2]

Quando un Junior entra in un contesto di sviluppo, la sua crescita non dipende dalla “bravura iniziale”, ma dalla qualità del sistema socio-tecnico in cui viene immerso. Code review, pairing, criteri di done, test, osservabilità, gestione degli incidenti: questi elementi costituiscono il circuito di feedback che trasforma il lavoro quotidiano in esperienza accumulata (e non solo in task chiusi). [2][7] 

Oggi questo non è più solo un tema interno ai team. Sul mercato del lavoro emergono segnali quantitativi coerenti con una riduzione relativa delle opportunità early-career nelle occupazioni più esposte alla GenAI: analisi su dati amministrativi su larga scala mostrano dinamiche in cui l’occupazione degli early-career cresce meno (o cala di più) rispetto ai profili più esperti. È evidenza osservazionale, non causale, ma il segnale è coerente e non isolato, e merita attenzione come possibile indicatore anticipatore di riallocazione del lavoro lungo la filiera (produzione vs verifica). [10] 

Qui vale esplicitare un possibile meccanismo (come ipotesi, non come prova): se l’AI abbassa il costo di produrre output plausibile, molte organizzazioni tendono a spostare l’attenzione su ruoli in grado di garantire verifica, accountability e gestione del rischio, irrigidendo di conseguenza lo “spazio protetto” in cui l’entry-level può imparare assumendo responsabilità progressive. È un’ipotesi coerente con i dati, ma non direttamente dimostrata da [10]. 

Se il circuito di feedback è debole, l’AI non aiuta: accelera l’erosione della qualità. Ed è qui che spesso nasce un corto circuito economico: l’aumento di output viene scambiato per aumento di valore e si conclude che “il costo deve scendere”. In realtà, ciò che può crescere è soprattutto il volume di codice che richiederà più revisione, più manutenzione, più interventi correttivi. Il costo reale riemerge nel tempo sotto forma di debito tecnico e fragilità operativa.

Sarebbe un errore pensare che questi meccanismi restino confinati ai team tecnici. La cultura delle organizzazioni in cui il software viene deciso, governato e utilizzato, incluse quelle che si affidano a software factory esterne, incide direttamente sulla qualità della crescita degli Junior. 

Qui il concetto chiave è la libertà di espressione senza timore di ritorsioni: portare dubbi, ambiguità, segnali deboli e rischi tecnici in modo tempestivo. La letteratura specifica sul tema mostra che l’organizzazione perde informazioni critiche non perché manchino, ma perché non diventano input legittimi nel processo decisionale. [12] 

Questo si lega direttamente alla sicurezza psicologica, intesa come convinzione condivisa che il team sia sicuro per il rischio interpersonale: si può parlare senza timore di umiliazione o punizione. Senza sicurezza psicologica, frasi come “questa richiesta è ambigua” o “qui stiamo accumulando rischio” tendono a non emergere. Con l’AI, il problema si amplifica: l’output plausibile rende ancora più facile “andare avanti” senza trasformare l’informazione in azione. [6] 

E qui entra un fattore spesso sottovalutato: l’apertura manageriale. Evidenze empiriche mostrano che comportamenti di leadership orientati all’ascolto e all’apertura aumentano la probabilità che le persone parlino quando vedono problemi o opportunità di miglioramento; in contesti punitivi, invece, cresce l’incentivo a tacere, e oggi esiste una scorciatoia perfetta: produrre rapidamente una risposta plausibile con l’AI e procedere. [11]

Qui arriviamo al punto decisivo. Definire l’Agile una chiave di volta non è un’affermazione di metodo né un’etichetta organizzativa: è una tesi di epistemologia operativa. I principi resi popolari dall’Agile, quali cicli brevi, feedback reali, apprendimento continuo, trasparenza sui trade-off, non nascono per “fare più veloce”, ma per trasformare l’incertezza in conoscenza e la conoscenza in software capace di generare valore di business. 

Per questo Agile non va inteso come l’unico modello possibile, né come un insieme di rituali da applicare indistintamente. È, piuttosto, una famiglia di meccanismi di apprendimento che può essere implementata anche in assetti organizzativi diversi, a condizione di preservare una proprietà fondamentale: nei sistemi complessi la verità non è disponibile ex ante, ma emerge dall’interazione continua tra ipotesi, implementazione e realtà operativa. È questa capacità di rendere l’apprendimento sistematico, e non episodico, che rende tali meccanismi particolarmente rilevanti nell’era dell’AI, in cui la produzione di output accelera molto più rapidamente della capacità di verificarne significato e conseguenze. 

Nell’era dell’AI, infatti, la funzione dell’Agile diventa ancora più critica. L’AI amplifica l’asimmetria tra produzione e verifica: produrre codice, test o configurazioni diventa sempre più economico e immediato; valutare se ciò che è stato prodotto sia corretto, sicuro, manutenibile e coerente con il contesto resta invece un’attività cognitiva e sociale ad alta intensità. Se la produzione accelera e la verifica non tiene il passo, il sistema accumula debito più velocemente di quanto riesca a riconoscerlo. In questo senso, Agile è soprattutto un meccanismo per riallineare produzione e apprendimento. 

In questa prospettiva, tre proprietà strutturali dell’Agile restano centrali. La prima è il feedback rapido e frequente. Incrementi piccoli, validazione continua e apprendimento iterativo non sono un vezzo organizzativo, ma l’antidoto principale al “codice che funziona in isolamento”: soluzioni plausibili che sembrano corrette finché non incontrano il sistema reale. Nell’era dell’AI, in cui l’output può essere semanticamente convincente ma fragilmente fondato, ridurre il tempo che intercorre tra decisione e verifica è essenziale per evitare che l’errore si propaghi e diventi sistemico. 

La seconda è la trasparenza sui trade-off. Un Agile praticato seriamente costringe a rendere esplicito cosa significhi “done”. E nell’era dell’AI, “done” non può più essere “compila e passa”: deve includere criteri verificabili di qualità, quali ad esempio test significativi, sicurezza, osservabilità minima, comprensione degli impatti operativi. Qui la lezione di DORA è particolarmente rilevante: la performance sostenibile non è il risultato di eroismi individuali, ma di capability organizzative che rendono la qualità ripetibile [2]. L’AI non elimina la necessità di queste capability; al contrario, ne aumenta l’urgenza. 

La terza è la responsabilità condivisa. Nel suo nucleo, Agile non è una tecnica di accelerazione, ma una forma di collaborazione continua tra chi costruisce e chi decide. È uno dei pochi assetti organizzativi che, se ben implementato, riduce la “distanza di potere” disfunzionale perché crea spazi istituzionalizzati in cui è legittimo discutere rischi, incertezze e limiti prima che diventino problemi in produzione. In questo senso, Agile agisce anche come “sistema operativo sociale”: retrospettive orientate all’apprendimento, review come confronto sul giudizio e non come tribunale, gestione degli incidenti senza caccia al colpevole. Sono tutti elementi che rafforzano la sicurezza psicologica, condizione necessaria per intercettare segnali deboli in sistemi complessi [6]. 

È però importante affrontare apertamente una critica emergente: l’aumento di velocità introdotto dall’AI rischia di trasformare alcuni rituali Agile tradizionali in colli di bottiglia. Se il codice viene prodotto a una velocità superiore alla capacità umana di review e comprensione, il rischio è duplice: da un lato, si tende a saltare i momenti di confronto, trattandoli come frizioni; dall’altro, si invoca una “AI-driven governance” che automatizzi controlli e decisioni, spostando ulteriormente il giudizio fuori dal circuito umano. 

Il rischio più profondo di una AI-driven governance non è tecnico, ma cognitivo: delegare integralmente la verifica interrompe il ciclo di apprendimento, soprattutto per gli Junior, perché separa l’azione dalla comprensione delle sue conseguenze. Un sistema che “verifica senza capire” può anche funzionare nel breve periodo, ma diventa fragile nel tempo: non sviluppa giudizio sul perché qualcosa funzioni, né su quando smetterà di farlo. 

Il punto, tuttavia, non è negare questi rischi, ma interpretarli correttamente. Il problema non è Agile, bensì una sua lettura ritualistica. Se Agile viene ridotto a un insieme di cerimonie sincronizzate su una velocità umana pre-AI, allora sì: diventa un freno. Se invece lo si riconosce per ciò che è, vale a dire un sistema adattivo di feedback e apprendimento, Agile può e deve evolvere. Questo significa ripensare i meccanismi di review, integrare controlli automatici senza delegare loro il giudizio finale e, soprattutto, preservare spazi in cui il senso delle decisioni venga discusso, non solo verificato. 

A questo punto il collegamento con la governance responsabile della GenAI diventa evidente. Governare l’AI non significa idolatrarla né demonizzarla, ma costruire regole, metriche e comportamenti che rendano il suo uso controllabile e falsificabile. Agile offre l’ossatura pratica di questa governance: inspect & adapt, continuous improvement, feedback loops. Non come liturgia, ma come infrastruttura cognitiva e organizzativa che impedisce alla velocità di sostituire il giudizio. 

In definitiva, Agile resta una chiave di volta non perché “funziona sempre”, ma perché è uno dei framework più efficaci per rendere misurabile l’apprendimento mentre costruiamo, a condizione che non venga ridotto a rituali e che i guardrail tecnici scalino con il throughput. Nell’era dell’AI, dove l’output abbonda e il significato rischia di rarefarsi, questa capacità di apprendere sistematicamente diventa il vero vantaggio competitivo per i team, per le organizzazioni e, soprattutto, per gli Junior Developer che in questi sistemi stanno costruendo il loro mestiere.

Se l’AI riduce drasticamente l’attrito della scrittura, la crescita degli Junior non può più essere affidata alla semplice esposizione al lavoro quotidiano. Nell’era dell’AI, l’esperienza non emerge automaticamente dall’accumulo di task completati: diventa una proprietà emergente del sistema di lavoro. 

Il punto cruciale è questo: non è il volume di attività a generare apprendimento, ma la qualità dei cicli di feedback che collegano decisioni, azioni e conseguenze nel tempo. Quando l’AI accelera la produzione di output senza rafforzare questi cicli, l’effetto netto può essere una compressione dell’apprendistato, non una sua accelerazione. 

L’obiettivo della crescita di un Junior non è massimizzare l’output individuale nel breve periodo, ma trasformare il lavoro quotidiano in capacità di giudizio trasferibile, cioè competenze che restano valide quando cambiano tool, linguaggi e framework. Questo apprendimento richiede un sistema socio-tecnico progettato intenzionalmente. 

In termini strutturali, questo sistema poggia su tre leve inseparabili: guardrail tecnici, guardrail sociali e cicli di apprendimento completi. 

Guardrail tecnici: qualità verificabile I guardrail tecnici non servono a “controllare” gli Junior, ma a rendere osservabile la qualità. In contesti complessi, la qualità non è auto-evidente: va resa esplicita, misurabile e discutibile. Per questo l’on-boarding non può ridursi a un trasferimento di tool, ma deve essere un’esposizione progressiva ai criteri con cui il sistema definisce “buon software”. [2] Code review strutturate, criteri di done espliciti, test significativi e osservabilità minima sono meccanismi di apprendimento incorporati nel flusso di lavoro: rendono visibile il ragionamento dietro alle decisioni tecniche e permettono di collegare una scelta locale a un impatto sistemico. La letteratura mostra che la review è un meccanismo centrale sia di qualità sia di apprendimento professionale. [7]

Qui è necessaria una precisazione importante. L’AI non è solo una scorciatoia. Una parte della ricerca in ambito EdTech mostra che, se progettata come “tutor socratico”, l’AI può accelerare l’apprendimento profondo. Sintesi robuste indicano che forme di tutoring “intelligente” possono produrre benefici comparabili, seppur mediamente inferiori, al tutoring umano, soprattutto quando forniscono feedback immediato e scaffolding strutturato [8]. Questo punto è particolarmente rilevante in contesti in cui la disponibilità di Senior per spiegazioni continue è un vincolo reale. 

Trasposto nel software, questo significa che l’AI può offrire scaffolding continuo: spiegazioni, contro-esempi, suggerimenti di test, “domande guida” per falsificare una soluzione. Ma non sostituisce il Senior. Al contrario, può rendere più efficace il suo ruolo, spostandolo dalla ripetizione di spiegazioni di base alla costruzione di giudizio situato. 

La disciplina, però, resta non negoziabile: l’AI può proporre, ma il Junior Developer deve dimostrare di aver verificato. L’AI deve aprire domande, non chiuderle. In questo modo, diventa una palestra di giudizio, non una stampante di codice.

Per evitare che “formazione” resti un’etichetta, servono metriche: Change Failure Rate e MTTR come termometro della stabilità; review load (tempo medio di review, % rework) come segnale di saturazione; defect escape rate e flakiness dei test come segnale di qualità; tempo alla prima ownership end-to-end come metrica di crescita; percentuale di incidenti con postmortem e azioni chiuse come indicatore di apprendimento reale. Questi indicatori sono coerenti con l’idea che la performance sostenibile sia una proprietà di capability organizzative, non di eroismi individuali. [2] 

In assenza di questi segnali, è facile confondere output con capacità. Ed è proprio qui che l’evidenza positiva sulla produttività può diventare un boomerang: se l’AI aumenta i task completati, ma la qualità del feedback loop non scala, un guadagno reale di produttività può trasformarsi in fragilità differita. [3]

L’AI generativa ha spostato il problema, non lo ha risolto. Ha reso abbondante l’output e scarso il giudizio. Ha ridotto il costo della scrittura del codice, ma ha aumentato il valore, e la difficoltà, di tutto ciò che consente a quel codice di reggere nel tempo: comprensione del contesto, valutazione dei trade-off, verifica empirica, responsabilità sulle conseguenze operative. 

In questo scenario, il tema degli Junior Developer diventa un indicatore anticipatore dello stato di salute dell’intero sistema. Non perché i Junior siano “il punto debole”, ma perché sono il punto in cui il sistema si rivela. Dove esistono feedback reali, criteri di qualità espliciti, sicurezza psicologica e responsabilità condivisa, l’AI può accelerare l’apprendimento. Dove questi elementi mancano, l’AI accelera solo la produzione di fragilità, mascherandola da produttività. 

La crescita di un Junior, nell’era dell’AI, non è più una conseguenza naturale dell’accumulo di task completati. È una proprietà emergente del sistema di lavoro. Dipende dalla qualità dei guardrail tecnici e sociali, dalla presenza di cicli completi di apprendimento, dalla capacità dell’organizzazione di trasformare errori, incidenti e ambiguità in conoscenza condivisa. Senza questi elementi, l’esperienza non si accumula: si diluisce. 

Per questo l’AI non è né una scorciatoia né una minaccia in sé. È un amplificatore. Amplifica la qualità quando il sistema è progettato per apprendere, amplifica il debito quando il sistema è progettato solo per produrre output. La differenza non la fa lo strumento, ma l’architettura socio-tecnica in cui viene inserito. 

In questo quadro, l’Agile resta una chiave di volta non per ragioni ideologiche o metodologiche, ma epistemologiche. In un contesto in cui la produzione accelera molto più rapidamente della verifica, servono meccanismi che riallineino decisione, azione e realtà. Feedback frequente, trasparenza sui trade-off, responsabilità condivisa e apprendimento sistematico non sono rituali organizzativi: sono dispositivi di conoscenza. 

In definitiva, nell’era dell’AI non formiamo Junior per scrivere codice più velocemente, ma per distinguere ciò che funziona da ciò che reggerà. Le organizzazioni che sapranno progettare sistemi di apprendistato reale, e non solo di output accelerato, non avranno semplicemente sviluppatori più produttivi. Avranno software più affidabile, meno rischio nascosto e una capacità superiore di adattarsi quando l’AI, inevitabilmente, cambierà ancora.

Sussiste un passaggio cruciale dell’evoluzione dell’AI: la transizione dai tool reattivi (Copilot, Cursor) a sistemi agentici capaci di eseguire task end-to-end. Il senso del suo contributo è chiaro e corretto: se i sistemi iniziano ad agire per obiettivi, il ruolo umano cambia profondamente. L’umano formula obiettivi invece di istruzioni passo-passo, verifica e valida più di quanto produca, interviene quando il sistema fallisce e non in ogni micro-decisione. In questo senso, affermare che il core skill si sposti dal “saper scrivere” al “saper verificare, indirizzare e correggere” non è ideologico, ma coerente con la traiettoria tecnologica in atto. 

Il punto su cui intendo insistere non è quindi la destinazione, ma come attraversiamo il transitorio. Perché oggi gli agenti non sono ancora sistemi affidabili nel senso ingegneristico del termine. Non per mancanza di ambizione, ma per limiti strutturali ben noti a chi li usa quotidianamente. Gli agenti soffrono di deriva del contesto, ignorano istruzioni esplicite, mostrano comportamenti goal-seeking superficiali e, per ora, non possiedono giudizio architetturale. Sono ottimi nel far “sparire un errore”, molto meno nel capire se la soluzione riduce o aumenta l’entropia del sistema. Invece di risolvere davvero i problemi, possono eliminare i controlli che segnalano gli errori, aggirare i meccanismi di sicurezza del codice, nascondere le parti difettose invece di correggerle e aggiungere complessità dove servirebbe semplificare. 

A questo si aggiunge un limite spesso sottovalutato: non esistono oggi agenti realmente competenti in modo uniforme su più linguaggi, stack e contesti enterprise, semplicemente perché non esiste materiale di addestramento sufficiente o coerente. Il risultato è un comportamento stocastico**: lo stesso prompt produce risultati diversi**, rendendo difficile costruire flussi di lavoro stabili e affidabili. È la “tassa dell’early adopter”: tempo speso a litigare con il modello, a inventare incantesimi, a compensare limiti che cambieranno di nuovo nel giro di pochi mesi. 

Qui emerge il punto che per me è decisivo. Orchestrare sistemi agentici richiede giudizio, ma quel giudizio non nasce automaticamente dal ruolo di orchestratore. Nasce dall’aver costruito, rotto, osservato fallimenti reali e affrontato conseguenze operative. Se anticipiamo troppo la figura dell’orchestratore, rischiamo di creare profili molto efficaci finché tutto funziona, ma inermi quando il sistema devia. Il problema non è che gli agenti producano codice: è che producono molto codice, spesso più di quanto un umano possa revisionare in modo significativo. Oltre una certa soglia, la review diventa superficiale e la comprensione della “forma dei dati” si perde. L’output cresce, la comprensione no. 

Per questo la mia posizione non è né nostalgica né difensiva. Non sto difendendo il “developer che scrive codice a mano” come figura del passato, né negando che il lavoro si stia spostando verso l’orchestrazione. Sto sostenendo che la costruzione del giudizio non può essere saltata, soprattutto ora che la delega cognitiva è facile, silenziosa e apparentemente efficace. Senza un apprendistato progettato intenzionalmente, il rischio è di trasformare le persone in supervisori di output mediocri, perdendo sia la gioia del controllo sia la capacità di intervento profondo. 

Se governiamo bene questo transitorio, il cambio di categoria avverrà quasi naturalmente. Se lo saltiamo, rischiamo di non formare né developer né orchestratori solidi e, cosa forse più grave, di illudere una generazione di giovani che vogliono entrare nello sviluppo professionale del software, promettendo ruoli e competenze che non reggono quando la complessità reale si manifesta. È su questo equilibrio, più che sull’etichetta dei ruoli, che ho cercato di concentrare l’articolo.

[1] ACM/IEEE/AAAI Joint Task Force. (2023). Computer Science Curricula 2023 (CS2023): Curriculum Guidelines for Undergraduate Degree Programs in Computer Science. ACM Press. 

[2] Forsgren, N., Humble, J., Kim, G., & Storey, M.-A. (2024). DORA / State of DevOps Report 2024. Google Cloud. 

[3] Cui, K. Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Working paper. 

[4] Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089. 

[5] Lee, H., Chen, J., Zhang, Y., & Klemmer, S. R. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects. CHI 2025. 

[6] Edmondson, A. C. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383. 

[7] Rigby, P. C., & Bird, C. (2013). Convergent Contemporary Software Peer Review Practices. ACM TOSEM, 22(2). 

[8] VanLehn, K. (2011). The Relative Effectiveness of Human Tutoring, Intelligent Tutoring Systems, and Other Tutoring Systems. Educational Psychologist, 46(4), 197–221. 

[9] Mainetti, S. (2025). AI e sviluppo software: lo specchio della maturità organizzativa. Articolo LinedIn disponibile al link: https://www.linkedin.com/pulse/ai-e-sviluppo-software-lo-specchio-della-maturit%C3%A0-stefano-mainetti-vsuzf. 

[10] Brynjolfsson, E., Chandar, N., & Chen, R. (2025). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of AI. Stanford Digital Economy Lab (Working Paper). 

[11] Detert, J. R., & Burris, E. R. (2007). Leadership Behavior and Employee Voice: Is the Door Really Open? Academy of Management Journal, 50(4), 869–884. 

[12] Morrison, E. W. (2023). Employee Voice and Silence: Taking Stock a Decade Later. Annual Review of Organizational Psychology and Organizational Behavior, 10.