Cognition punta sul fatto che i test di Devin GPT-6 Astra possano sostituire la code review con prove concrete
Cognition ha esteso i test di Devin GPT-6 Astra a tre prodotti, trasformando la verifica nell’ultimo terreno di scontro dell’ingegneria del software autonoma. Il modello ora supporta i test all’interno di Devin Cloud, Devin Desktop e Devin CLI. Può utilizzare le applicazioni, ispezionare i risultati e restituire prove visive insieme a report scritti.
Il cambiamento importante non è che Devin possa generare più codice. Gli agenti di coding producono già patch, aprono pull request ed eseguono suite di test. Cognition ora vuole che Devin presenti prove del corretto funzionamento delle sue modifiche, riducendo la quantità di codice generato che gli ingegneri devono ispezionare manualmente.
Questa promessa mette sotto pressione lo sviluppo tradizionale basato prima di tutto sulla revisione. Solleva inoltre una domanda difficile per Cognition, OpenAI e ogni agente di coding concorrente. Un agente può valutare in modo affidabile il lavoro prodotto dallo stesso sistema automatizzato, oppure l’attenzione umana si sposta semplicemente dalla revisione del codice alla revisione delle prove?
I test di Devin GPT-6 Astra ora producono prove revisionabili
Cognition sta proponendo le prove dei test, non la sola generazione di codice, come il risultato che gli ingegneri dovrebbero valutare.
OpenAI ha pubblicato il suo caso di test di Devin l’11 settembre 2026. L’azienda afferma che Cognition sta applicando GPT-6 Astra al suo agente cloud, all’interfaccia a riga di comando e all’applicazione desktop.
Cognition aveva già aggiunto Astra a Devin il 3 settembre. Il suo rollout del modello afferma che Astra è disponibile direttamente in Devin Desktop e Devin CLI. Il modello fa anche parte della combinazione di modelli usata da Devin Cloud.
L’integrazione separa due compiti che i prodotti di coding presentano spesso come un unico flusso di lavoro continuo. Un modello può implementare una modifica, mentre Astra può contribuire a guidare la fase di test. Questa distinzione conta perché modificare il codice e convalidare un’applicazione richiedono capacità diverse.
Un modello di coding ragiona principalmente su repository, specifiche e modifiche al codice sorgente. Un tester di applicazioni deve anche interpretare le schermate, seguire lo stato dell’interfaccia, utilizzare il software e riconoscere se il comportamento osservato corrisponde al risultato previsto.
Cognition afferma che Astra ottiene risultati particolarmente buoni in questo secondo gruppo di compiti. L’azienda riporta risultati allo stato dell’arte su un benchmark interno di test. Non ha pubblicato dettagli sufficienti perché soggetti esterni possano riprodurre o verificare indipendentemente quel risultato specifico.
Gli esempi pubblici chiariscono cosa intenda Cognition per verifica autonoma. In una dimostrazione, Devin testa Otter Run, un gioco per iPhone, all’interno di un simulatore. Restituisce una registrazione del gioco in esecuzione e un report che descrive quali verifiche hanno avuto esito positivo.
Il report identifica anche aree che Devin non ha testato. Questa precisazione è importante, perché un video ben rifinito potrebbe altrimenti suggerire una copertura più ampia di quella effettivamente ottenuta dall’esecuzione.
La registrazione mostra il comportamento osservabile, mentre il report definisce l’ambito dichiarato. Insieme, offrono a chi revisiona qualcosa di più vicino a un artefatto di test che a un riepilogo convenzionale dell’agente.
Un altro flusso di lavoro parte da uno screenshot di un bug fornito dal cliente. Cognition afferma che il team può inviare quell’immagine a Devin, che diagnostica il problema, modifica il codice e restituisce un altro screenshot che mostra il risultato.
La sequenza collega un difetto visibile a un esito visibile. Può accorciare il ciclo di feedback per problemi dell’interfaccia difficili da spiegare solo tramite log o commenti nelle pull request.
Tuttavia, uno screenshot dimostra soltanto ciò che è apparso in un determinato momento. Non stabilisce che i percorsi correlati funzionino ancora, che l’implementazione sottostante sia manutenibile o che il difetto resti risolto in condizioni diverse.
La funzionalità più utile è quindi il pacchetto di prove. Gli ingegneri possono confrontare il comportamento richiesto, il piano di test dichiarato, le azioni registrate e le eventuali aree non testate prima di decidere se effettuare il merge.
Questo cambia l’unità della revisione. Invece di ricevere soltanto un diff e un’attestazione scritta dall’agente, l’ingegnere riceve un’affermazione supportata da una traccia di esecuzione.
Questo cambiamento rappresenta la scommessa centrale di Cognition. Se chi revisiona si fida della traccia, può dedicare meno tempo a ricostruire ciò che è accaduto a partire dal codice generato. Se non se ne fida, gli artefatti aggiuntivi diventano un ulteriore livello da ispezionare.
Perché la verifica è diventata il collo di bottiglia degli agenti di coding
Nello sviluppo con agenti, la risorsa limitante si sta spostando dalla produzione di codice alla capacità di revisione affidabile.
Gli agenti di coding possono creare modifiche più velocemente di quanto la maggior parte dei team riesca a valutarle. Quando più agenti operano contemporaneamente, ogni sessione riuscita può produrre un altro branch, una pull request, un report di test o una decisione successiva.
Cognition afferma che i suoi stessi ingegneri hanno eseguito tra 10 e 20 sessioni Devin in parallelo. Ogni sessione può gestire un server di sviluppo separato nel cloud. Un tale livello di concorrenza sarebbe scomodo sul laptop di un singolo ingegnere.
Una maggiore concorrenza non crea automaticamente più valore in produzione. Può invece generare una coda di modifiche plausibili in attesa di verifica umana.
Quella coda è particolarmente difficile perché il codice generato può sembrare ragionevole prima di fallire in esecuzione. Chi revisiona potrebbe dover ricostruire l’ambiente, eseguire l’applicazione, ripetere il flusso riportato ed esaminare i comportamenti circostanti.
Cognition ha descritto questa sfida come parte di un più ampio passaggio verso lo sviluppo asincrono. Oggi vengono avviate più sessioni Devin tramite pianificazioni, automazioni, eventi e altre istanze di Devin che tramite richieste interattive dirette.
Un agente di coding asincrono lavora mentre il suo responsabile umano si occupa di altro. Questa organizzazione fa risparmiare attenzione solo quando il risultato restituito è comprensibile e sufficientemente affidabile.
Senza verifica, gli ingegneri tornano davanti a una pila di diff non spiegati. Devono recuperare il contesto di ogni attività prima di decidere se il lavoro sia utile.
Il precedente resoconto di Cognition sulla verifica degli agenti afferma che le esecuzioni giornaliere di test approvate sono più che raddoppiate nell’arco di diversi mesi. Si tratta di attività di prodotto riportate dall’azienda, non di una misura indipendente di affidabilità o valore per i clienti.
Ciononostante, la direzione ha senso. Man mano che gli agenti generano più modifiche, i team hanno bisogno di prove sintetiche che indichino quali risultati meritino attenzione.
L’obiettivo non è eliminare immediatamente il giudizio umano. È rendere tale giudizio meno oneroso, avvicinando le osservazioni rilevanti al compito completato.
Un pacchetto di prove utile può rispondere a diverse domande prima che un ingegnere legga l’implementazione. L’applicazione si è avviata correttamente? La funzionalità modificata è comparsa? Quale percorso utente ha esercitato l’agente? Cosa è rimasto fuori dal test?
Queste domande spesso hanno più valore dell’affermazione di un agente secondo cui tutti i test sono passati. Una suite di test convenzionale valuta solo le asserzioni che qualcuno ha previsto e codificato.
Le registrazioni dell’interfaccia possono rivelare cambiamenti di stato che non sono mai stati rappresentati nei test unitari. Le note scritte sull’ambito possono inoltre esporre la copertura mancante, invece di nasconderla in un lungo log di esecuzione.
La pressione si estende oltre Cognition. Codex di OpenAI, i sistemi di coding sostenuti da Anthropic, gli agenti per sviluppatori di Google, Cursor e i framework open source competono tutti per i carichi di lavoro ingegneristici.
Ogni prodotto può migliorare il proprio punteggio nella generazione di codice. Tuttavia, l’adozione aziendale dipende da ciò che accade dopo la generazione, quando una persona responsabile deve approvare una modifica con conseguenze rilevanti.
Ecco perché il principale avversario non è un singolo modello rivale. È il flusso di lavoro basato prima sulla revisione, costruito attorno alla lettura di ogni riga significativa prima di fidarsi del risultato.
Quel flusso di lavoro esiste per buone ragioni. Il codice comunica architettura, costi futuri di manutenzione, ipotesi di sicurezza e comportamenti in caso di errore che una breve dimostrazione potrebbe non rivelare mai.
Cognition non afferma che queste preoccupazioni scompaiano. Il suo obiettivo dichiarato è far sì che gli ingegneri esaminino meno codice nel tempo, distribuendo al contempo più lavoro completato.
Questa formulazione lascia spazio a una revisione selettiva. I team potrebbero ispezionare attentamente i moduli ad alto rischio, accettando invece una revisione guidata dalle prove per correzioni circoscritte dell’interfaccia, migrazioni di routine o strumenti interni ben delimitati.
L’effetto pratico dipenderà da quanto bene i team conserveranno il contesto delle attività. Una base di conoscenza ingegneristica può aiutare chi revisiona a collegare le prove dell’agente a requisiti, decisioni progettuali e fallimenti precedenti.
La verifica diventa più preziosa quando riflette tali fonti. Una registrazione pulita vale meno se l’agente ha frainteso il requisito che definiva il successo.
Astra trasforma il test in una competenza separata dell’agente
Il contributo di Astra deriva dalla combinazione, in un unico ciclo di test, di utilizzo del computer, giudizio visivo, ragionamento sulla codebase e reportistica concisa.
Un modello per l’utilizzo del computer interpreta un’interfaccia visiva ed esegue azioni come fare clic, digitare, scorrere e navigare tra schermate. Il test aggiunge un altro requisito: tali azioni devono supportare asserzioni esplicite sul comportamento previsto.
Il ciclo di test di Cognition inizia con un piano fondato sul repository. L’agente esamina il codice rilevante prima di dichiarare cosa testerà. Questo riduce la possibilità che inventi percorsi dell’interfaccia o ipotesi non supportate dall’applicazione.
Il piano crea inoltre un punto di riferimento per il report finale. Chi revisiona può vedere se l’esecuzione ha coperto il comportamento previsto, invece di giudicare una registrazione senza criteri dichiarati.
Durante l’esecuzione, Devin può annotare la timeline con note di configurazione e fasi di test denominate. Può contrassegnare le asserzioni come superate, fallite o non testate.
Cognition afferma che richiedere all’agente di dichiarare un’aspettativa prima di agire riduce la razionalizzazione. L’agente ha meno libertà di reinterpretare una schermata inattesa come un successo dopo aver visto il risultato.
Ciò ricorda lo sviluppo guidato dai test, in cui il comportamento previsto viene definito prima dell’implementazione. Qui, l’impegno avviene durante la verifica comportamentale, anziché prima di ogni modifica al codice.
L’agente può quindi utilizzare un browser, un simulatore o un’applicazione desktop. Cattura ciò che è accaduto e restituisce artefatti che un essere umano può ispezionare in modo asincrono.
Astra sembra adatto a questa fase perché il modello è stato addestrato per l’utilizzo del computer e per compiti professionali lunghi e articolati. OpenAI afferma che può installare software, risolvere problemi visibili ed eseguire controlli di qualità del frontend.
Nei risultati sull’utilizzo del computer pubblicati da OpenAI, Astra ha ottenuto il 72,6% su OSWorld 2.0. GPT-5.6 Sol ha ottenuto il 65,7% nel confronto riportato.
OpenAI afferma inoltre che Astra ha completato quei compiti simulati in circa 40 minuti di media. Il modello precedente ha richiesto approssimativamente 75 minuti. Queste cifre provengono dall’impostazione di valutazione di OpenAI e non dovrebbero essere considerate misurazioni universali in produzione.
La stessa pubblicazione riporta per Astra un punteggio del 57,9% su Terminal-Bench 4.0. GPT-5.6 Sol ha ottenuto il 37,3%, mentre Claude Fable 5.1 ha ottenuto il 55,8%.
Su FrontierCode 1.1 Extended, Astra ha ottenuto il 64,5%. Claude Fable 5 ha ottenuto il 64,9%, lasciando Astra leggermente indietro rispetto a quel modello nel benchmark di Cognition.
Cognition descrive FrontierCode come una valutazione proprietaria di attività ingegneristiche reali. Il suo punteggio considera qualità e idoneità al merge, e le soluzioni che non superano i criteri bloccanti non ricevono alcun credito.
Questi confronti suggeriscono che l’attrattiva di Astra non risieda semplicemente in prestazioni di coding grezze superiori. La dichiarazione pubblica di Cognition enfatizza report più chiari, test più completi e video più facili da seguire.
Queste qualità incidono direttamente sui tempi di revisione. Un’esecuzione tecnicamente riuscita può comunque sprecare attenzione umana se le sue prove sono confuse, prolisse o scollegate dalla modifica richiesta.
Un report conciso dovrebbe identificare il comportamento testato, l’ambiente, il risultato osservato e l’incertezza residua. Una registrazione utile dovrebbe rendere facili da individuare le transizioni importanti, anziché costringere il revisore a esaminare una sessione non modificata.
Cognition ha inoltre creato script deterministici per le attività di configurazione ripetute. Uno script deterministico esegue una sequenza definita invece di chiedere al modello di improvvisare ogni azione.
L’autenticazione è un esempio. Gestire un flusso di login attraverso screenshot può richiedere tempo e introdurre errori non legati alla funzionalità testata.
Uno script salvato può creare rapidamente una sessione browser autenticata. L’agente può quindi concentrare il proprio ragionamento sul comportamento che conta.
Questo design ibrido rivela un’importante lezione ingegneristica. Un testing autonomo migliore non significa assegnare ogni operazione a un modello linguistico.
I sistemi affidabili riservano i passaggi prevedibili all’automazione convenzionale. Usano il modello dove interpretazione, ripristino o navigazione flessibile aggiungono valore.
Cognition consente inoltre a Devin di proporre competenze di testing riutilizzabili dopo aver risolto un difficile problema di configurazione. L’utente può esaminare quell’automazione prima di aggiungerla al repository.
Nel tempo, questo può trasformare scoperte ripetute in infrastruttura stabile. Il percorso improvvisato dal modello diventa uno script esaminato per le esecuzioni future.
La combinazione controlla anche la variabilità. Se ogni test parte con un comportamento di configurazione diverso, confrontare i risultati diventa difficile e diagnosticare i guasti costoso.
Astra offre percezione e ragionamento flessibili. Gli script deterministici vincolano le azioni ripetitive. Il piano di test definisce il successo, mentre il report delle prove mostra ciò che l’esecuzione ha coperto.
Questo meccanismo è più rilevante di un ulteriore primato nei benchmark. Delinea come gli agenti di coding possano passare dal produrre patch plausibili al partecipare a flussi di lavoro ingegneristici controllati.
L’Agente Non Può Ancora Correggere da Solo i Propri Compiti
Le prove possono ridurre lo sforzo di revisione, ma non possono rendere l’autoverifica indipendente, completa o automaticamente affidabile.
Il rischio più evidente è il fallimento correlato. Se un agente fraintende il compito durante l’implementazione, lo stesso sistema può trasferire quel fraintendimento nel proprio piano di test.
Il codice e il test possono quindi concordare tra loro pur essendo entrambi in disaccordo con il requisito effettivo dell’utente. Un report impeccabile documenterebbe coerenza, non correttezza.
I test indipendenti riducono questo problema quando derivano da specifiche, da un altro ingegnere o da un sistema di valutazione separato. Le suite di regressione esistenti forniscono inoltre vincoli che l’agente di implementazione non ha inventato durante la sessione.
L’approccio di Cognition aiuta ancorando i piani al codice sorgente e dichiarando le aspettative prima di ogni azione. Queste misure possono ridurre la deriva, ma non creano una vera indipendenza.
L’azienda ha descritto apertamente fallimenti precedenti. Talvolta Devin testava aree non correlate, rimaneva bloccato nella configurazione dell’ambiente o non individuava il comportamento che una pull request intendeva modificare.
Questi problemi spiegano perché il sistema necessita di piani, annotazioni e strumenti di configurazione deterministici. Mostrano anche che prove curate dipendono da un’orchestrazione che va oltre il modello sottostante.
Le prove visive hanno ulteriori limiti. Un video può mostrare che un flusso ha funzionato in un ambiente e con uno stato dei dati. Non può stabilire una correttezza ampia tra browser, autorizzazioni, condizioni di carico o input malevoli.
Un report può etichettare accuratamente tali lacune come non testate. I revisori devono comunque decidere se i percorsi omessi siano abbastanza importanti da bloccare il deployment.
La copertura diventa particolarmente importante per modifiche al backend, all’infrastruttura e alla sicurezza. Molti guasti gravi non producono un sintomo visivo evidente durante una breve esecuzione.
Una migrazione del database potrebbe sembrare riuscita prima di corrompere un caso limite. Una modifica alle autorizzazioni potrebbe funzionare per l’account mostrato, esponendo però i dati di un altro tenant.
Il codice sensibile alla sicurezza richiede un pensiero avversariale, non soltanto la conferma che si sia verificato il comportamento previsto. I team hanno bisogno di test progettati per mettere in discussione le ipotesi, anziché riprodurre il percorso ideale.
OpenAI stessa applica restrizioni alle capacità avanzate di cybersecurity di Astra. Il modello può assistere nella revisione e nel patching sicuri, mentre alcuni flussi di lavoro legati agli exploit restano limitati o monitorati.
Una copertura indipendente del lancio di Astra ha inoltre evidenziato questioni di sicurezza irrisolte attorno al lavoro autonomo complesso. L’affidabilità nel mondo reale resta meno certa di quanto suggeriscano le dimostrazioni controllate.
La qualità del software presenta una sfida di più lungo periodo. Superare i test di oggi non dimostra che modifiche ripetute degli agenti lascino una codebase comprensibile e adattabile.
Un’analisi critica dei limiti dei benchmark di coding sostiene che i test attuali spesso non rilevano l’erosione strutturale. Il codice può restare funzionale pur diventando più difficile da modificare in sicurezza.
Questa preoccupazione limita direttamente la proposta di “rivedere meno codice”. Gli ingegneri leggono il codice per più della correttezza immediata. Esaminano astrazioni, confini di responsabilità, logica duplicata, osservabilità e costo di manutenzione futuro.
Un video di esecuzione non può rivelare tutte queste qualità. Nemmeno un report incentrato sul comportamento visibile può farlo.
La giusta politica di revisione dipenderà probabilmente dal rischio. Un aggiustamento visivo in una dashboard interna merita un controllo diverso dalla logica di autenticazione, dall’elaborazione dei pagamenti o da infrastrutture critiche per la sicurezza.
I team possono definire criteri di merge che combinano tipi di prova. Una modifica a basso rischio potrebbe richiedere una suite superata, un flusso utente registrato e un report completo sull’ambito.
Una modifica a rischio più elevato potrebbe richiedere anche una revisione umana del design, test di sicurezza indipendenti e un’ispezione manuale dei file sensibili. Le prove dell’agente possono supportare questi controlli senza sostituirli.
Un altro problema è l’integrità delle prove. I revisori devono avere fiducia che le registrazioni corrispondano al commit inviato, all’ambiente, alla configurazione e ai dati di test.
Se gli artefatti possono separarsi dal codice esatto in esame, potrebbero descrivere una build precedente o configurata diversamente. Una solida provenienza dovrebbe collegare ogni affermazione al suo stato di esecuzione.
Cognition non ha dettagliato pubblicamente ogni controllo di provenienza alla base del flusso di lavoro evidenziato. Anche il suo benchmark interno resta proprietario, limitando il confronto tra laboratori indipendenti.
La dichiarazione sul benchmark dovrebbe quindi essere letta come un segnale di prodotto, non come una misura consolidata della qualità del testing autonomo.
Persino i risultati pubblici di OpenAI misurano compiti delimitati. I repository di produzione contengono ipotesi non documentate, dipendenze instabili, servizi privati e regole di rilascio specifiche dell’organizzazione.
Astra può migliorare la capacità dell’agente di orientarsi in questa complessità. Non elimina la necessità di giudizio ingegneristico su quali prove siano sufficienti.
La distinzione fondamentale è tra dimostrazione e prova. Nella pratica ordinaria dello sviluppo software, il testing fornisce prove che comportamenti selezionati hanno funzionato in condizioni definite.
Raramente dimostra la correttezza totale. Il linguaggio pubblico di Cognition usa talvolta “dimostrare” in senso colloquiale, ma i team dovrebbero mantenere l’interpretazione ingegneristica più circoscritta.
Questa cautela non rende la funzionalità poco importante. Definisce dove possa creare valore senza incoraggiare una fiducia non sicura.
Tre Segnali Mostreranno Se gli Ingegneri Potranno Rivedere Meno Codice
Il prossimo test consiste nel verificare se Cognition possa trasformare dimostrazioni più forti in un’adozione misurabile e consapevole dei rischi tra i team di produzione.
Il primo segnale è la riproducibilità indipendente. Cognition dovrebbe pubblicare dettagli sufficienti sul proprio benchmark di testing affinché soggetti esterni possano comprendere la selezione dei compiti, il punteggio, l’instradamento del modello e la gestione dei fallimenti.
Risultati riproducibili rafforzerebbero l’affermazione che Astra migliori il testing anziché limitarsi a produrre artefatti dall’aspetto migliore. Mostrerebbero inoltre con quale frequenza il sistema segnali onestamente un fallimento o una copertura incompleta.
La qualità delle prove deve essere valutata separatamente dal completamento del compito. Un agente di testing può raggiungere il risultato corretto fornendo al contempo un report inutilizzabile, oppure creare documentazione convincente per un test incompleto.
Misurazioni utili potrebbero includere accuratezza delle asserzioni, difetti mancati, falsi superamenti, calibrazione della copertura e tempo del revisore. Dovrebbero anche rilevare se i revisori raggiungano la decisione di merge corretta.
Se valutazioni indipendenti confermeranno miglioramenti in queste dimensioni, il flusso di lavoro di Cognition che alleggerisce la revisione guadagnerà credibilità. Se i risultati varieranno nettamente tra repository, i team avranno bisogno di regole di impiego più ristrette.
Il secondo segnale è il comportamento in produzione. Cognition afferma che le esecuzioni di test approvate quotidianamente siano aumentate, ma il solo volume di approvazioni non dimostra software migliore o costi di revisione inferiori.
Gli indicatori più solidi sono le modifiche integrate, i tassi di difetti sfuggiti, la frequenza dei rollback e il tempo impiegato per rivedere ogni contributo accettato. I team dovrebbero confrontare questi risultati con modifiche simili gestite attraverso la revisione convenzionale.
Cognition ha già esplorato le “ore di ingegneria produttiva” come metrica aziendale. La sua valutazione ha utilizzato 233 sessioni escluse dal training e ha riportato che circa la metà rientrava in un fattore due rispetto alle stime umane.
L’azienda ha anche riconosciuto che le stime individuali restano rumorose. Errori di due o tre volte in entrambe le direzioni sono comuni, secondo la sua analisi pubblicata.
Questa franchezza conta perché le affermazioni sulla produttività possono separarsi dai risultati del software. Una stima delle ore risparmiate non coglie il costo di un difetto scoperto dopo il deployment.
Le prove più convincenti collegherebbero tempi di revisione ridotti a una qualità stabile o in miglioramento. Se i team ispezionano meno codice ma riscontrano più regressioni, il flusso di lavoro trasferisce semplicemente il costo a valle.
Se il tempo di revisione diminuisce senza peggiorare difetti, rollback o manutenzione, la tesi centrale di Cognition diventa molto più forte.
Il terzo segnale è il modo in cui i concorrenti riprogettano la verifica. I fornitori di modelli e le aziende di agenti di coding possono rispondere con agenti revisori indipendenti, tracce di esecuzione più solide o formati standardizzati per le prove.
Una risposta competitiva significativa confermerebbe che la verifica è diventata il principale livello di prodotto. Offrirebbe inoltre agli acquirenti alternative per evitare che un singolo agente valuti il proprio output.
Modelli distinti per implementazione e revisione possono introdurre una diversità utile. Fornitori, prompt o sistemi di generazione dei test differenti hanno meno probabilità di riprodurre esattamente lo stesso fraintendimento.
Tuttavia, la sola diversità dei modelli non garantisce l’indipendenza. Due agenti possono comunque fare affidamento sulla stessa specifica incompleta o sulla stessa suite di test esistente.
I sistemi migliori combineranno progettazione indipendente dei test, controlli deterministici, provenienza degli artefatti e politiche di rischio esplicite. La revisione umana potrà quindi concentrarsi sulle decisioni che l’automazione non può comprimere in sicurezza.
I responsabili dell’ingegneria dovrebbero iniziare selezionando compiti delimitati in cui il comportamento osservabile rifletta con forza il successo. Correzioni di bug nell’interfaccia, flussi di lavoro interni di routine e regressioni ben specificate sono candidati sensati.
Dovrebbero richiedere a Devin di dichiarare ciò che non ha testato. Dovrebbero inoltre confrontare le sue prove con il commit inviato e mantenere i normali controlli per le modifiche sensibili.
Gli sviluppatori possono utilizzare il nuovo flusso di lavoro come filtro dell’attenzione anziché come autorità. Il report indica dove guardare, la registrazione mostra cosa è accaduto e il codice resta disponibile quando il rischio richiede un’ispezione.
L’obiettivo di Cognition è plausibile, ma non automatico. Test migliori possono ridurre il lavoro di revisione solo quando le evidenze restano fondate, circoscritte e collegate ai risultati in produzione.
La domanda più importante per i team è quindi pratica: quali modifiche potete approvare sulla base delle evidenze di esecuzione e quali richiedono ancora la lettura di ogni riga significativa? Verificate deliberatamente questo confine prima di rendere i test di Devin GPT-6 Astra parte predefinita del vostro processo di merge.
