Ecco ciò che abbiamo imparato realizzando funzionalità di test end-to-end nella macchina virtuale di Devin.
3 mesi fa, sono entrato in Cognition per contribuire a costruire il futuro dell'ingegneria del software. Devin ha fatto molta strada dal suo lancio come primo ingegnere software AI, e sono rimasto stupito nel vedere il team dietro usare Devin ogni giorno.
Una cosa che mi ha colpito è stato come Devin usa il suo computer per verificare il lavoro in autonomia nel cloud. Dal convalidare la nostra integrazione Slack al testare funzionalità complesse di Windsurf, il team ha sempre un esercito di Devin in modalità test. In questo articolo, condividerò perché siamo così concentrati sulla verifica end-to-end tramite agenti cloud e come stiamo affrontando la sua realizzazione.
Il passaggio all'ingegneria del software asincrona
In Cognition, abbiamo recentemente raggiunto un nuovo traguardo. Per la prima volta, più Devin vengono attivati in modo asincrono, tramite eventi, automazioni, pianificazioni e altri Devin. Prevediamo che questo trend acceleri ulteriormente con il nostro recente lancio di Auto-Triage.
Mentre transitiamo verso questo mondo asincrono, è fondamentale che gli sviluppatori possano tornare a risultati verificati e pronti per essere integrati. All'inizio di quest'anno abbiamo lanciato Devin Review, uno strumento di revisione del codice che amplia la comprensione umana di diff di codice complessi. Non si limita a segnalare bug - Devin chiude il cerchio correggendo ogni riscontro finché il diff non risulta pulito. Ma una sola revisione pulita spesso non basta: gli ingegneri vogliono vedere la modifica testata end-to-end, esattamente come la testerebbero loro stessi.
È una bella sensazione quando Devin apre una PR che corregge una segnalazione utente prima ancora che tu abbia avuto la possibilità di vedere il messaggio nel canale dei bug. Ciò che lo rende magico è quando quella PR arriva con la prova che la correzione funziona davvero. E questa magia potrebbe presto diventare una necessità: con l'aumento delle PR generate da agenti proattivi, le modifiche non verificate diventerebbero rapidamente ingestibili.
Dall'inizio
Fin dal suo lancio, Devin è sempre stato in grado di dimostrare il suo lavoro su una macchina virtuale nel cloud. Circa 6 mesi fa, abbiamo ampliato le capacità di utilizzo del computer di Devin. In pratica, ciò significa che abbiamo aggiunto strumenti all'harness di Devin per fare screenshot, muovere il mouse, cliccare, trascinare, digitare, premere tasti, scorrere, attendere, zoomare e avviare/fermare la registrazione. L'uso del computer esiste da un po', ma abbiamo percepito che l'ultima generazione di modelli dei laboratori all'avanguardia ha iniziato a diventare davvero brava nell'utilizzare questi strumenti.
L'uso del computer ha sbloccato nuove e divertenti capacità per Devin, come creare e giocare a un gioco da scrivania o usare il browser per ordinare prodotti su Amazon. Ma la vera svolta che abbiamo notato è stata la capacità di Devin di testare il proprio lavoro. Devin avvia l'app, la naviga cliccando e conferma che le sue modifiche funzionano effettivamente, esattamente come farebbe un ingegnere. Tutto viene eseguito nel cloud e può essere scalato in parallelo. Questo mi ha davvero colpito quando ho visto ingegneri eseguire da 10 a 20 Devin in parallelo, ognuno con il proprio server di sviluppo, lavorando sulle modifiche – una cosa semplicemente impossibile da fare su un singolo laptop. Il test automatico nel cloud ha iniziato a farci risparmiare un'enorme quantità di tempo, dato che non dobbiamo più eseguire e verificare il codice localmente.
A dirla tutta, arrivare a questo punto non è stato semplice. Abbiamo incontrato molti scenari di fallimento lungo il percorso, e ognuno ci ha insegnato qualcosa su cosa serve per rendere questo sistema più affidabile.
Aumentare l'affidabilità
Nelle prime versioni, era molto comune che Devin perdesse la rotta durante i test. Succedeva in vari modi: testare parti del prodotto non pertinenti, perdersi nella configurazione prima di raggiungere la funzionalità, o semplicemente non cogliere il comportamento centrale che la PR doveva modificare.
Per affrontare questo problema, quando Devin entra in modalità test, gli facciamo prima scrivere un piano di test che dettagli un obiettivo chiaro su cosa testare. Questo piano deve basarsi sul codice sorgente, non su supposizioni. Senza un ancoraggio nel codice, abbiamo scoperto che i modelli tendono a supporre di poter seguire percorsi nell'app che non esistono. Inoltre, il piano di test aumenta notevolmente la complessità delle modifiche che Devin può testare con successo. Alcune delle nostre richieste più ambiziose includevano funzionalità che richiedevano l'esecuzione di più servizi, configurazioni amministrative specifiche e flag corretti abilitati prima ancora che il comportamento fosse raggiungibile. Leggendo il codice in anticipo, Devin è molto più propenso a configurare l'ambiente correttamente, invece di scoprire che manca qualcosa a metà del test. Il piano di test agisce come una forma di pre-allineamento e rende Devin meno incline a deviare durante il test attivo.
Mentre Devin esegue il piano, aggiunge le proprie annotazioni nella cronologia. Queste includono note di configurazione, l'inizio di ogni test nominato e asserzioni contrassegnate come superate, fallite o non testate. Abbiamo scoperto che Devin mente meno sui suoi risultati se annota il comportamento previsto subito prima di eseguire un'azione – molto simile allo sviluppo guidato dai test: se ti impegni sull'aspettativa in anticipo, diventa molto più difficile razionalizzare un risultato inaspettato come un successo.
Alcune parti del flusso di test si ripetono in quasi ogni esecuzione. L'accesso è l'esempio classico: gestire un modulo di login tramite l'uso del computer significa spesso digitare un'email, completare l'SSO, cliccare attraverso i reindirizzamenti e attendere ogni caricamento della pagina, screenshot dopo screenshot. Questo può essere costoso sia in termini di tempo che di token. Per migliorare l'affidabilità e il costo di queste azioni, Devin ha estratto il lavoro in uno script deterministico che risiede in una skill di test nel nostro repository. In questo modo, Devin può eseguire lo script e ottenere una sessione browser autenticata in pochi secondi, e passare direttamente alla parte centrale del test. La natura deterministica di questi script ha aiutato a ridurre drasticamente l'instabilità. Abbiamo aggiornato Devin in modo che possa chiudere questo ciclo da solo. Quando scopre un passaggio di configurazione con fatica, Devin può suggerire di salvare quella conoscenza come una skill di test nel repository e proporre la correzione all'utente come una PR con un solo clic.
Stiamo anche sperimentando il routing della fase di test verso modelli diversi. Poiché il test si basa su punti di forza diversi rispetto alla scrittura del codice, come la lettura degli screenshot, il monitoraggio dello stato dell'interfaccia utente e la decisione della successiva azione del browser, alcuni modelli sono semplicemente più bravi in questo rispetto a quello che sceglieresti tipicamente per modificare il codice.
Utilizzare il test autonomo in Devin oggi
Devin attualmente entra in modalità test in due modi: su richiesta esplicita di testare una modifica, oppure, dopo che Devin ha creato una PR, offrirà di testare la modifica se applicabile. Da lì, creerà il piano di test e inizierà a lavorare.
Spesso, quando inizi a usare le capacità di test di Devin, avrà bisogno del tuo aiuto. Un buon esempio è se richiede segreti quando esegue la tua app localmente. Per rendere questo processo più fluido, Devin è in grado di chiederti nella sessione eventuali credenziali o altre informazioni mancanti. Per i casi più complessi, puoi prendere il controllo del computer di Devin e inserire cose come i codici OTP. La buona notizia è che, una volta che Devin ha terminato la configurazione del tuo repository, è in grado di salvare una configurazione dichiarativa sotto forma di blueprint YAML che produce uno snapshot da cui ogni sessione futura potrà avviarsi.
Cosa ottieni in cambio
Quando Devin termina il test, non si limita a dirti se l'app ha funzionato. Una registrazione video grezza è utile, ma abbiamo ritenuto che non fosse sufficiente da sola: devi capire cosa stai guardando, perché Devin ha eseguito ogni azione e quali parti del test sono state superate o fallite.
Per una revisione rapida, Devin restituisce un report di test con screenshot etichettati tratti dai momenti chiave dell'esecuzione, così puoi vedere rapidamente cosa ha testato Devin e che aspetto aveva l'app lungo il percorso.
Se desideri una revisione più approfondita, Devin produce anche un video del test con una ricca interfaccia utente del player che include capitoli per saltare tra le sezioni di test, scorrere l'intera esecuzione e ispezionare le asserzioni superate o fallite in una vista elenco cronologico. Nella post-elaborazione, il tempo morto tra le azioni viene compresso, mentre i momenti intorno alle azioni vengono riprodotti a velocità normale. Questo permette di condensare un'esecuzione lunga in una registrazione che puoi effettivamente guardare. Questi artefatti sono disponibili nella nostra interfaccia web e vengono anche distribuiti su Slack se Devin è stato avviato da lì.
Aspetti critici
L'uso del computer ha ancora aspetti critici. Un esempio è la tempistica: se Devin sta testando una notifica toast, uno screenshot scattato troppo presto o troppo tardi può mancare completamente la notifica e i modelli possono confondersi sul fatto che il comportamento previsto sia effettivamente avvenuto.
Un'altra modalità di fallimento è l'imbroglio. Lasciati a sé stessi, i modelli a volte tendono ad affidarsi troppo all'esecuzione di JavaScript nel browser per attivare stati a livello di codice invece di cliccare nell'interfaccia utente. Questo può essere utile per testare la funzionalità, ma gli utenti spesso vorranno vedere Devin utilizzare l'app come farebbe un utente reale.
Stiamo lavorando attivamente su questi problemi tramite valutazioni migliorate, barriere di protezione più strette nell'harness e ogni nuova generazione di modelli che migliora nell'uso del computer.
Il futuro dello sviluppo asincrono è verificato
Negli ultimi due mesi, il numero di esecuzioni di test approvate al giorno su Devin è più che raddoppiato. Questa crescita riflette qualcosa di semplice: gli agenti asincroni sono utili solo se gli sviluppatori possono fidarsi di ciò che riportano. Spesso quella fiducia non può venire solo dal codice: per molte modifiche, vuoi sapere che l'app è stata effettivamente eseguita, che i flussi importanti sono stati testati e che il risultato è stato catturato in un modo che puoi ispezionare facilmente.
Questo è ciò che il test autonomo in Devin è progettato per fornire. Devin pianifica il test, opera l'app, registra e annota ciò che è successo e infine restituisce artefatti che rendono il risultato revisionabile. C'è ancora molto da migliorare, ma pensiamo che questa sia la giusta forma del futuro: agenti che non si limitano a completare il lavoro in modo asincrono, ma tornano con le prove.
Siamo costantemente sorpresi da quanto tempo Devin ci faccia risparmiare testando il proprio lavoro, e riteniamo che molti clienti stiano ancora sottoutilizzando la funzionalità di test automatico di Devin. Per supportare la sperimentazione, attualmente fatturiamo 1/5 del costo di utilizzo normale durante la modalità test.
Prova il nostro lavoro su devin.ai o windsurf.com. E se lavorare su problemi come questi ti sembra divertente, contattami a ido [at] cognition.ai
