Le competenze degli sviluppatori AI su GitHub passano dalla scrittura del codice alla sua direzione

Il 2 ottobre GitHub ha aggiornato i propri consigli di carriera per gli sviluppatori, indicando tre competenze degli sviluppatori AI su GitHub che contano mentre gli agenti assumono una quota maggiore del lavoro di implementazione. Secondo l'azienda, gli sviluppatori dovrebbero imparare a dirigere gli agenti, mettere in discussione le loro prime risposte e riservare l'attenzione umana al giudizio tecnico. Il contrasto è immediato: produrre codice sta diventando più facile, mentre dimostrare che quel codice merita di essere rilasciato resta difficile.

Il consiglio riflette un cambiamento più profondo nel modo in cui GitHub descrive un'esecuzione efficace. Un tempo uno sviluppatore dimostrava i progressi scrivendo, testando e inviando un'implementazione. GitHub presenta ora un flusso di lavoro in cui diversi agenti preparano codice, test e documentazione, mentre lo sviluppatore definisce il problema e revisiona il risultato complessivo.

Questo modello non elimina la responsabilità ingegneristica. La concentra nei punti in cui l'AI resta meno affidabile. Gli sviluppatori devono fornire contesto, far emergere vincoli nascosti, confrontare alternative e riconoscere risultati plausibili ma incompleti.

L'argomento arriva inoltre in un contesto di evidenze contrastanti sulla produttività dell'AI. Gli sviluppatori riportano spesso guadagni di efficienza personali, ma la ricerca controllata e i dati di delivery mostrano che una generazione più rapida non garantisce una consegna del software più veloce o più sicura. GitHub sta quindi avanzando un'affermazione professionale, non limitandosi a offrire un tutorial su uno strumento: la competenza scarsa sta passando dalla produzione del codice alla direzione e alla validazione di un sistema produttivo più ampio.

Le competenze degli sviluppatori AI su GitHub iniziano ora dalla direzione degli agenti

L'affermazione centrale di GitHub è che l'esecuzione significa sempre più definire e coordinare il lavoro, non implementare personalmente ogni componente.

Le linee guida di carriera di GitHub descrivono un'attività convenzionale di autenticazione come una sequenza lineare. Uno sviluppatore crea un branch, scrive il codice, esegue i test e apre una pull request. Ogni passaggio resta visibile e attribuibile a una sola persona.

La sua alternativa basata sugli agenti appare diversa. Un agente prepara l'implementazione dell'autenticazione, un altro redige la documentazione e un terzo crea la suite di test. Lo sviluppatore resta responsabile del risultato, ma si sposta a monte, dove vengono stabiliti requisiti e confini, e a valle, dove gli output sono integrati e approvati.

Questo va oltre il prompting. Un agente AI è un software in grado di perseguire un obiettivo attraverso molteplici azioni con una supervisione limitata. Dirigerne uno richiede allo sviluppatore di descrivere il risultato desiderato, fornire il contesto del repository, stabilire vincoli e definire le prove di completamento.

Dirigere più agenti aggiunge un ulteriore livello di complessità. I loro compiti devono essere separabili, le loro ipotesi devono restare compatibili e i loro output devono convergere sulla stessa architettura. La generazione parallela fa risparmiare poco tempo se un agente modifica un'interfaccia che un altro si aspetta rimanga stabile.

Una specifica solida diventa quindi coordinamento eseguibile. Per una funzionalità di autenticazione, potrebbe identificare i provider di identità supportati, il comportamento delle sessioni, i requisiti di migrazione, le ipotesi sulle minacce, le esigenze di accessibilità e la gestione degli errori. Dovrebbe anche definire quali test devono superare prima che inizi la revisione.

Lo sviluppatore deve decidere quanto contesto riceve ciascun agente. Un contesto insufficiente favorisce codice generico in conflitto con le convenzioni del repository. Troppo contesto non filtrato può oscurare i requisiti rilevanti e aumentare la probabilità che un agente segua documentazione obsoleta.

Questo rende la conoscenza del repository più preziosa, non meno. Un ingegnere che comprende i confini di responsabilità, le pratiche di deployment e la storia architetturale può suddividere il lavoro in sicurezza. Chi non possiede questa comprensione può comunque generare codice, ma non può prevedere in modo affidabile dove la modifica si romperà.

Le nuove competenze di coding AI su GitHub includono anche la gestione delle dipendenze tra artefatti generati. I test devono esaminare l'implementazione che verrà effettivamente rilasciata. La documentazione deve descrivere il comportamento reale anziché il progetto previsto. Le modifiche al database devono allinearsi alle procedure di deployment e rollback.

La direzione degli agenti dovrebbe quindi iniziare dalla scomposizione. Gli sviluppatori devono separare le attività che possono procedere in modo indipendente dalle decisioni che richiedono un giudizio condiviso. Hanno inoltre bisogno di punti di controllo espliciti prima che un agente ampli l'ambito di una modifica.

Un modello operativo utile consiste nell'assegnare risultati circoscritti anziché ambizioni generiche. “Implementa il rinnovo del token con questi sei vincoli” è revisionabile. “Migliora l'autenticazione” invita un agente a prendere decisioni di prodotto, sicurezza e architettura senza un'autorità adeguata.

La stessa disciplina vale per i criteri di completamento. Una suite di test verde è una prova, ma non rappresenta l'intera definizione di completamento. Lo sviluppatore potrebbe comunque dover valutare latenza, esposizione dei dati, compatibilità all'indietro, osservabilità e impatto sugli utenti.

La prima raccomandazione di GitHub sposta quindi l'unità visibile dell'esperienza. La velocità di digitazione e la familiarità con i framework restano utili, ma non distinguono più gli sviluppatori quando un agente può generare rapidamente pattern comuni. Il fattore distintivo diventa la capacità di trasformare una richiesta ambigua in lavoro delimitato e verificabile.

Questo cambiamento mette sotto pressione sia gli ingegneri junior sia quelli senior. Tradizionalmente, gli sviluppatori junior hanno rafforzato il proprio giudizio implementando molti piccoli cambiamenti. Gli sviluppatori senior devono ora preservare queste opportunità di apprendimento, adottando al contempo flussi di lavoro che delegano l'implementazione di routine.

Le organizzazioni dovranno decidere se la direzione degli agenti diventerà un mestiere individuale o una pratica ingegneristica condivisa. Se ogni sviluppatore inventa prompt, regole di revisione e formati di passaggio di consegne separati, i team potrebbero ottenere velocità locale accumulando però processi incoerenti.

Una base di conoscenza ingegneristica ricercabile può aiutare agenti e sviluppatori a lavorare a partire dalle stesse decisioni. Tuttavia, la documentazione aiuta solo quando i team la mantengono e distinguono le regole attuali da quelle obsolete.

I consigli di GitHub sono più efficaci se letti come una richiesta di migliore definizione dei problemi. Gli agenti possono moltiplicare la capacità di implementazione. Moltiplicano anche le conseguenze di requisiti poco chiari, contesto mancante e confini deboli.

La generazione più rapida del codice mette sotto pressione i revisori

Il collo di bottiglia immediato si sposta dalla produzione del codice alla sua verifica, dove l'attenzione umana resta limitata.

La seconda raccomandazione di GitHub è diretta: non fidarsi della prima risposta di un sistema AI. L'azienda illustra il punto con una query SQL che appare corretta finché un secondo modello non identifica timestamp duplicati, una raccomandazione mancante sull'indice e prestazioni scarse su larga scala.

Quell'esempio coglie il problema centrale della revisione. Il codice generato spesso sembra completo perché è sintatticamente rifinito e segue pattern familiari. I suoi difetti possono risiedere in ipotesi non dichiarate anziché in evidenti errori di sintassi.

La survey sugli sviluppatori del 2025 di Stack Overflow quantifica questa tensione. Il quarantasei percento degli intervistati non si fidava dell'accuratezza dell'output dell'AI, mentre il 33% si fidava. Solo il 3% ha riportato un elevato livello di fiducia.

La stessa survey ha rilevato che il 66% degli sviluppatori aveva incontrato soluzioni AI quasi corrette, ma non del tutto. Il quarantacinque percento ha affermato che il debugging del codice generato richiedeva più tempo. Non si tratta di lamentele isolate su interfacce scomode. Descrivono un onere di verifica creato da output plausibili.

Gli sviluppatori devono revisionare il comportamento, non la presentazione. Un diff pulito può comunque gestire male la concorrenza, i confini di autorizzazione, gli input malformati o gli errori parziali. I test generati dall'AI possono ripetere la stessa ipotesi errata incorporata nell'implementazione.

GitHub propone la critica di un secondo modello come difesa. Secondo quanto riportato, il suo agente Copilot Rubber Duck usa un altro modello per criticare piani, codice e test. L'approccio può far emergere problemi trascurati dal modello originale.

Un secondo modello è utile, ma non costituisce una prova indipendente. I modelli possono condividere pattern di addestramento, ripetere errori convenzionali o accettare la stessa premessa fuorviante. Se la richiesta iniziale omette un vincolo di sicurezza, entrambi i modelli potrebbero produrre risposte sicure di sé che lo ignorano.

Il revisore umano deve quindi esaminare la premessa prima di confrontare le risposte. La prima domanda non è quale modello abbia scritto il codice più pulito. È se la definizione dell'attività includa gli effettivi requisiti del cliente, del sistema e delle operazioni.

Anche la revisione richiede una profondità proporzionata. Un errore di battitura nella documentazione non richiede gli stessi controlli di una modifica all'autorizzazione. I team dovrebbero collegare i requisiti di revisione al rischio, alla sensibilità dei dati, alla reversibilità e al potenziale raggio d'impatto.

Per modifiche a basso rischio, test automatizzati e una revisione umana mirata possono essere sufficienti. Per codice ad alto rischio, i team possono richiedere threat modeling, load testing, deployment graduale, logging di audit e l'approvazione di un responsabile di dominio.

La pressione aumenta quando gli agenti generano simultaneamente più modifiche. La capacità di revisione umana non scala automaticamente con il volume dell'output. Uno sviluppatore che riceve tre branch completati può affrontare un carico cognitivo maggiore di chi ha scritto una singola implementazione in sequenza.

I grandi lotti peggiorano la situazione. I revisori devono ricostruire più contesto, seguire più ipotesi interagenti e distinguere le modifiche intenzionali da quelle incidentali. L'apparente velocità della generazione può nascondere una coda di lavoro di verifica irrisolto.

La ricerca di DORA sull'AI generativa ha documentato un divario correlato. I risultati del 2024 associavano un aumento del 25% nell'adozione dell'AI a una riduzione dell'1,5% nel throughput di delivery e a una riduzione del 7,2% nella stabilità del delivery. DORA ha suggerito che una generazione più rapida del codice possa produrre modifiche più ampie, che richiedono più tempo per essere revisionate e destabilizzano i sistemi.

Queste cifre descrivono associazioni, non un esito universale per ogni team. Mettono comunque in discussione l'idea che una maggiore quantità di codice generato si traduca automaticamente in più valore consegnato. Il sistema di delivery deve assorbire, valutare e rilasciare quel codice in sicurezza.

Le competenze degli sviluppatori AI su GitHub devono quindi includere la progettazione delle evidenze. Prima che un agente inizi, lo sviluppatore dovrebbe stabilire cosa dimostrerà la correttezza. Queste evidenze potrebbero includere test basati sulle proprietà, soglie di prestazione, controlli di sicurezza o telemetria prevista dopo il deployment.

Gli sviluppatori devono inoltre preservare la tracciabilità. I revisori dovrebbero sapere quali requisiti hanno modellato una modifica, cosa è stato chiesto a un agente di fare, quali strumenti ha utilizzato e dove un essere umano ha modificato l'output. Senza questa storia, il diff finale può essere difficile da interpretare.

L'implicazione professionale è significativa. La revisione del codice era già una responsabilità ingegneristica importante. In un flusso di lavoro ricco di agenti, la revisione diventa un'attività produttiva primaria anziché un controllo finale dopo il lavoro “reale”.

Ciò significa che le organizzazioni devono premiarla di conseguenza. Se i sistemi di valutazione conteggiano le funzionalità rilasciate ma ignorano i difetti evitati, gli sviluppatori sentiranno pressione ad approvare rapidamente il lavoro generato. La struttura degli incentivi entrerà in conflitto con il giudizio di cui, secondo GitHub, i team hanno bisogno.

La scala professionale si sta spostando verso il giudizio tecnico

Quando l'implementazione diventa meno costosa, decidere cosa debba essere costruito e quali compromessi siano accettabili acquista maggior valore.

La terza raccomandazione di GitHub invita gli sviluppatori a usare l'AI per problemi più ampi. L'azienda sostiene che il risparmio nell'implementazione possa liberare tempo per comprendere i clienti, progettare sistemi, valutare compromessi e scegliere metriche di successo.

Il suo esempio sulla modalità scura divide chiaramente il lavoro. L'AI realizza la funzionalità, genera i test e aggiorna la documentazione. Lo sviluppatore convalida il problema del cliente, esamina i compromessi architetturali, verifica l'accessibilità, definisce il successo e approva la soluzione.

Questa divisione mette in luce il principale antagonista di questa trasformazione: l'output di codice visibile contro il giudizio ingegneristico responsabile. Il codice è facile da contare. Il giudizio emerge negli errori evitati, nell'ambito ristretto, nei progetti più sicuri e nelle decisioni di non realizzare la funzionalità sbagliata.

Il giudizio tecnico combina conoscenza del dominio e consapevolezza delle conseguenze. Include il riconoscimento dei casi in cui un modello familiare non è adatto, in cui un requisito entra in conflitto con un altro obiettivo e in cui l'incertezza giustifica un esperimento più limitato.

La comunicazione diventa parte della stessa competenza. Gli sviluppatori devono spiegare perché un progetto privilegi l'affidabilità rispetto alla velocità o perché una scorciatoia crei futuri costi di migrazione. L'AI può abbozzare alternative, ma l'ingegnere responsabile deve collegarle alla realtà aziendale e operativa.

Questo cambia ciò su cui dovrebbe concentrarsi la crescita all'inizio della carriera. Memorizzare la sintassi conta meno quando l'assistenza è sempre disponibile. Comprendere il flusso dei dati, le modalità di guasto, le interfacce, i confini di sicurezza e il comportamento dei sistemi conta di più, perché questi concetti favoriscono una valutazione affidabile.

Esiste però un problema di formazione. Storicamente, gli sviluppatori hanno costruito il proprio giudizio scrivendo codice, risolvendo bug e convivendo con le precedenti scelte progettuali. Se gli agenti assorbono troppo presto una quota eccessiva dell'implementazione, i nuovi arrivati potrebbero perdere la ripetizione che sviluppa l'intuizione.

I team non dovrebbero confondere la delega con l'apprendimento. Un ingegnere junior può usare un agente e comunque esaminare ogni ipotesi, prevedere il comportamento prima di eseguire i test e spiegare il progetto finale. Un flusso di lavoro che accetta codice generato senza ricostruirlo offre un valore formativo inferiore.

Gli ingegneri senior affrontano una sfida diversa. La loro esperienza dà loro istinti di revisione più forti, ma l'elevata familiarità può anche far sembrare un agente più lento. Potrebbero già sapere dove collocare una modifica e come funzionano le convenzioni del repository.

Uno studio randomizzato sulla produttività degli sviluppatori di METR ha esaminato questo scenario nel 2025. Sedici sviluppatori open source esperti hanno completato 246 attività reali in progetti maturi che conoscevano bene, con l'accesso all'AI consentito o negato in modo casuale.

Prima dello studio, gli sviluppatori si aspettavano che l'AI riducesse il tempo di completamento del 24%. In seguito, ritenevano che avesse ridotto il tempo del 20%. I risultati misurati hanno mostrato il contrario: l'accesso agli strumenti dei primi mesi del 2025 ha aumentato il tempo di completamento del 19%.

Lo studio presenta limiti importanti. Ha coinvolto un piccolo gruppo, strumenti specifici, repository maturi e sviluppatori con una profonda conoscenza dei progetti. Gli autori non hanno sostenuto che ogni sviluppatore o attività avrebbe sperimentato lo stesso rallentamento.

Ciononostante, il divario di percezione è importante. Gli sviluppatori possono sentirsi più veloci perché la generazione riduce lo sforzo o produce progressi visibili, anche quando prompting, attese, correzioni e revisioni allungano il tempo complessivo di completamento. Lo slancio soggettivo non coincide con la consegna misurata.

Per questo l'impatto di GitHub sulla carriera degli sviluppatori non può ridursi a «imparare il prompting». Un prompt intelligente può migliorare una risposta. Un vantaggio duraturo deriva dalla scelta di attività appropriate, dalla costruzione di cicli di feedback affidabili e dal riconoscimento dei casi in cui l'uso degli strumenti aggiunge sovraccarico.

Gli sviluppatori più forti probabilmente alterneranno le modalità anziché seguire un'unica dottrina. Delegheranno il lavoro ripetitivo e ben specificato; collaboreranno con un agente su implementazioni incerte; e lavoreranno direttamente quando la conoscenza del repository rende inefficiente l'assistenza.

Anche i manager hanno bisogno di criteri di valutazione migliori. Le righe di codice e il numero di pull request diventano ancora meno significativi quando gli agenti possono gonfiare entrambi. Tempo di ciclo, difetti sfuggiti, risultati per i clienti, manutenibilità e capacità di ripristino forniscono segnali più utili.

I percorsi di carriera dovrebbero riconoscere la qualità delle specifiche, l'efficacia delle revisioni, la prevenzione degli incidenti e le decisioni tecniche tra team. Altrimenti, gli sviluppatori potrebbero ottimizzare l'attività generata mentre l'organizzazione dipende da un giudizio non riconosciuto.

Le indicazioni di GitHub puntano verso quel futuro senza definirlo completamente. L'azienda identifica le competenze che gli sviluppatori dovrebbero rafforzare, ma i datori di lavoro devono decidere se i sistemi di promozione e l'assegnazione dei progetti valorizzeranno davvero tali competenze.

Le prove sulla produttività resistono ancora a una narrazione semplice

L'AI può migliorare le singole attività lasciando però la consegna del team più lenta, meno stabile o più difficile da comprendere.

GitHub dispone di prove sostanziali dell'entusiasmo degli sviluppatori. Un sondaggio del 2024 tra sviluppatori aziendali commissionato dall'azienda ha coinvolto 2.000 intervistati non manageriali negli Stati Uniti, in Brasile, India e Germania.

Oltre il 97% ha dichiarato di aver usato strumenti di coding AI al lavoro almeno una volta. A seconda del Paese, tra il 59% e l'88% ha riferito che le rispettive organizzazioni incoraggiavano o consentivano tali strumenti.

Gli intervistati hanno inoltre descritto vantaggi significativi. Tra il 60% e il 71% ha affermato che gli strumenti AI rendevano più semplice adottare un nuovo linguaggio o comprendere una codebase esistente. Negli Stati Uniti e in Germania, il 47% ha dichiarato di usare il tempo risparmiato per la collaborazione e la progettazione dei sistemi.

Questi risultati sostengono l'argomento di GitHub secondo cui l'AI può liberare attenzione per un lavoro più ampio. Tuttavia, misurano l'esperienza dichiarata anziché la consegna end-to-end in condizioni controllate. Inoltre, provengono da grandi imprese, dove governance e accesso agli strumenti differiscono dalle organizzazioni più piccole.

I dati successivi di Stack Overflow offrono un quadro misto. Il cinquantadue percento degli sviluppatori concordava sul fatto che strumenti o agenti AI avessero influenzato positivamente la produttività. Tra gli utenti di agenti, circa il 70% ha affermato che gli agenti riducevano il tempo dedicato a compiti specifici, mentre il 69% ha riportato un aumento della produttività.

Gli effetti sui team erano molto più deboli. Solo il 17% degli utenti di agenti ha affermato che gli agenti miglioravano la collaborazione, l'impatto con la valutazione più bassa nel sondaggio. Questo divario suggerisce che le organizzazioni non possono presumere che l'accelerazione individuale migliori automaticamente il coordinamento.

Anche l'adozione rimane disomogenea. Stack Overflow ha rilevato che il 52% degli sviluppatori non usava agenti oppure si affidava a strumenti AI più semplici. Un ulteriore 38% non aveva piani di adozione degli agenti.

Il contrasto è importante perché il flusso di lavoro proposto da GitHub presume che gli agenti siano capaci, disponibili e integrati con i sistemi di ingegneria. Molti sviluppatori lavorano ancora in ambienti in cui policy, requisiti di privacy, strumenti legacy o affidabilità dei modelli limitano questa configurazione.

Le preoccupazioni per sicurezza e privacy restano rilevanti. Stack Overflow ha riportato che l'87% degli intervistati era preoccupato dell'accuratezza degli agenti, mentre l'81% ha espresso preoccupazione per sicurezza e privacy dei dati.

Queste preoccupazioni riguardano più del codice generato. Un agente può ricevere file sorgente, documentazione interna, log di produzione, dettagli dei clienti o credenziali durante lo svolgimento di un'attività. Dirigere responsabilmente gli agenti richiede di controllare a quali dati possano accedere e quali azioni possano eseguire.

Anche gli strumenti di base cambiano rapidamente. Il risultato METR del 2025 è un'istantanea dei sistemi dei primi mesi del 2025, non un limite permanente. Modelli più recenti, indicizzazione migliore dei repository, interfacce per agenti migliorate e maggiore esperienza degli sviluppatori possono modificare l'equilibrio.

Questa incertezza opera in entrambe le direzioni. I team non dovrebbero scartare l'AI perché uno studio ha rilevato un rallentamento. Né dovrebbero dichiarare il successo perché gli sviluppatori riferiscono di sentirsi più produttivi.

La domanda giusta è se un flusso di lavoro specifico migliori un risultato specifico sotto vincoli reali. I team possono confrontare attività simili, monitorare il tempo di revisione, ispezionare i tassi di difetto e misurare l'intervallo dal lavoro accettato a una distribuzione stabile.

Dovrebbero inoltre separare il tempo di generazione dal tempo totale dell'attività. Una bozza di funzionalità creata in pochi minuti può richiedere ore di chiarimenti, pulizia e revisione. Al contrario, un agente che non produce codice può comunque far risparmiare tempo individuando una dipendenza nascosta o riassumendo moduli poco familiari.

La misurazione deve includere le rilavorazioni. Se l'AI aumenta l'output iniziale ma aumenta anche commit correttivi, cicli di revisione o incidenti, il guadagno lordo della generazione sovrastima il beneficio.

La qualità del sistema circostante conta quanto la capacità del modello. Documentazione chiara, piccole modifiche, test affidabili, architettura modulare e distribuzioni osservabili rendono più semplice valutare l'output dell'AI. Fondamenta ingegneristiche deboli offrono agli agenti maggiore spazio per amplificare la confusione.

Questo è il nucleo scettico del consiglio di GitHub sulla carriera. Le tre competenze raccomandate sono plausibili perché gli agenti restano imperfetti, non perché l'implementazione sia diventata completamente autonoma. Dirigere, revisionare e giudicare sono salvaguardie attorno a uno strumento il cui effetto netto dipende ancora fortemente dal contesto.

Gli sviluppatori dovrebbero quindi resistere a due estremi. Trattare gli agenti come completamento automatico inaffidabile ignora i guadagni reali. Trattarli come ingegneri indipendenti trasferisce le decisioni senza trasferire la responsabilità.

Cosa dimostrerà che il modello per sviluppatori di GitHub funziona

Il prossimo test sarà se i flussi di lavoro guidati dagli agenti migliorano il software completato, non se generano più codice.

Il primo segnale da osservare è una performance di consegna misurabile. Le organizzazioni che adottano agenti dovrebbero riferire se tempo di ciclo, tassi di fallimento delle modifiche, tempi di ripristino e risultati per i clienti migliorano insieme. Bozze più rapide con revisioni più lente indebolirebbero il modello proposto da GitHub.

Un risultato più solido mostrerebbe che i team distribuiscono modifiche più piccole e sicure mentre gli agenti gestiscono compiti di implementazione circoscritti. Ciò suggerirebbe che gli sviluppatori stanno dirigendo con successo la capacità invece di limitarsi ad aumentare la dimensione dei lotti.

Il secondo segnale riguarda il modo in cui le organizzazioni di ingegneria rivedono i percorsi di carriera. L'argomentazione di GitHub acquista peso se i datori di lavoro iniziano a riconoscere qualità delle specifiche, revisione AI, ragionamento architetturale e gestione del rischio come criteri espliciti di promozione.

Un semplice cambio di titolo dimostrerebbe poco. Le prove significative emergerebbero nelle esercitazioni di selezione, nelle valutazioni delle prestazioni, nei programmi di mentorship e nella titolarità dei progetti. Le aziende dovrebbero premiare gli sviluppatori per aver prevenuto lavoro debole, non soltanto per aver prodotto artefatti visibili.

Il terzo segnale è se i sistemi di revisione tengono il passo con la generazione. Agenti migliori possono creare più codice candidato, ma i team necessitano di test più forti, provenienza più chiara e controlli di approvazione basati sul rischio. Altrimenti, la coda di verifica diventerà il fattore limitante.

Le critiche di un secondo modello sono un meccanismo utile. Analisi statica, scansione della sicurezza, test delle proprietà, esecuzione isolata e rollout graduali forniscono tipi diversi di evidenza. Nessun singolo modello dovrebbe fungere sia da autore sia da autorità finale.

Gli sviluppatori possono agire prima che arrivino questi cambiamenti organizzativi. Iniziate selezionando un'attività circoscritta con criteri di accettazione chiari. Registrate tutto il tempo dedicato a specificare, generare, revisionare, correggere, testare e distribuire il risultato.

Confrontate il risultato con lavori simili completati senza un agente. Esaminate qualità e impegno, non soltanto il tempo di generazione trascorso. L'obiettivo è identificare dove l'assistenza crea leva e dove introduce un costo di revisione.

Successivamente, esercitatevi a spiegare ogni modifica generata. Se non riuscite a descriverne ipotesi, modalità di guasto e compromessi, non siete pronti ad approvarla. Chiedere a un altro modello una critica può ampliare la ricerca, ma il vostro giudizio tecnico deve concluderla.

Infine, proteggete il ciclo di apprendimento. Scrivete codice quando l'implementazione vi insegnerà qualcosa di essenziale. Delegate quando l'attività è compresa, circoscritta e facile da verificare. Usate gli agenti per estendere il giudizio ingegneristico, non per evitare di svilupparlo.

Le competenze degli sviluppatori AI su GitHub stanno evolvendo verso il coordinamento, la revisione critica e un processo decisionale responsabile. Quale parte del tuo attuale flusso di lavoro ti fornisce prove sufficienti per fidarti di un agente, e quale dipende ancora da conoscenze che solo il tuo team possiede?