Ce que nous avons appris en développant les capacités de test de bout en bout dans la machine virtuelle de Devin.
Il y a 3 mois, j'ai rejoint Cognition pour contribuer à construire l'avenir du génie logiciel. Devin a parcouru un long chemin depuis son lancement en tant que premier ingénieur logiciel IA, et j'ai été époustouflé de voir l'équipe derrière l'utiliser réellement chaque jour.
Ce qui m'a particulièrement frappé, c'est la façon dont Devin utilise son ordinateur pour vérifier son travail de manière autonome dans le cloud. De la validation de notre intégration Slack au test de fonctionnalités complexes de Windsurf, l'équipe dispose toujours d'une armée de Devins en mode test. Dans cet article, je vais expliquer pourquoi nous sommes si concentrés sur la vérification de bout en bout des agents cloud et comment nous abordons sa construction.
Le passage à l'ingénierie logicielle asynchrone
Chez Cognition, nous avons récemment franchi une nouvelle étape. Pour la première fois, davantage de Devins sont déclenchés de manière asynchrone, via des événements, des automatismes, des plannings et d'autres Devins. Nous nous attendons à ce que cela continue de s'accélérer avec notre récent lancement d'Auto-Triage.
Alors que nous passons à ce monde asynchrone, il est crucial que les développeurs puissent revenir à des résultats vérifiés et prêts à être fusionnés. Plus tôt cette année, nous avons lancé Devin Review, un outil de révision de code qui amplifie la compréhension humaine des différences de code complexes. Il ne se contente pas de signaler des bugs - Devin ferme la boucle en corrigeant chaque constat jusqu'à ce que la diff soit propre. Mais une simple révision propre ne suffit souvent pas - les ingénieurs veulent voir la modification testée de bout en bout, de la même manière qu'ils la testeraient eux-mêmes.
C'est une sensation formidable lorsque Devin soumet une PR corrigeant une plainte d'utilisateur avant même que vous n'ayez eu la chance de voir le message dans le canal des bugs. Ce qui rend cela magique, c'est que cette PR est accompagnée d'une preuve que la correction fonctionne réellement. Et cette magie pourrait bientôt devenir une nécessité - à mesure que de plus en plus de PRs proviennent de l'essor des agents proactifs, les changements non vérifiés deviendront rapidement ingérables.
Depuis le début
Depuis le lancement de Devin, il a toujours été capable de démontrer son travail sur une machine virtuelle cloud. Il y a environ 6 mois, nous avons étendu les capacités d'utilisation de l'ordinateur par Devin. Concrètement, nous avons ajouté des outils au harnais de Devin pour prendre des captures d'écran, déplacer la souris, cliquer, faire glisser, taper, appuyer sur des touches, faire défiler, attendre, zoomer, et démarrer/arrêter l'enregistrement. L'utilisation de l'ordinateur existe depuis un certain temps maintenant, mais nous avons constaté que la dernière cohorte de modèles des laboratoires de pointe commence vraiment à bien utiliser ces outils.
L'utilisation de l'ordinateur a débloqué de nouvelles capacités amusantes pour Devin, comme créer et jouer à un jeu de bureau, ou utiliser son navigateur pour commander des produits sur Amazon. Mais le véritable déblocage que nous avons remarqué est la capacité de Devin à tester son propre travail. Devin lance l'application, navigue dedans, et confirme que ses modifications fonctionnent réellement, de la même manière qu'un ingénieur le ferait. Tout s'exécute dans le cloud et peut être mis à l'échelle en parallèle. Cela m'a vraiment frappé quand j'ai vu des ingénieurs exécuter 10 à 20 Devins en parallèle, chacun avec son propre serveur de développement, travaillant sur des modifications - c'est quelque chose que vous ne pouvez tout simplement pas faire sur un seul ordinateur portable. Les tests cloud automatisés ont commencé à nous faire gagner un temps considérable, car nous n'avons plus besoin d'exécuter et de vérifier le code localement.
Pour être honnête, y parvenir n'a pas été facile. Nous avons rencontré de nombreux modes de défaillance en cours de route, qui nous ont chacun appris quelque chose sur ce qu'il faut pour rendre ce système plus fiable.
Améliorer la fiabilité
Dans les premières versions, il était très courant que Devin se trompe de voie pendant les tests. Cela se produisait de toutes sortes de façons : tester trop de parties non liées du produit, se perdre dans la configuration avant d'atteindre la fonctionnalité, ou simplement manquer le comportement central que la PR était censée modifier.
Pour y remédier, lorsque Devin entre en mode test, nous lui faisons d'abord rédiger un plan de test détaillant un objectif clair sur ce qu'il faut tester. Ce plan doit être ancré dans le code source, pas dans des hypothèses. Sans ancrage dans le code, nous avons constaté que les modèles ont tendance à supposer qu'ils peuvent emprunter des chemins dans l'application qui n'existent pas. De plus, le plan de test augmente considérablement la complexité des modifications que Devin peut tester avec succès. Certaines de nos demandes les plus ambitieuses incluaient des fonctionnalités nécessitant plusieurs services en cours d'exécution, des paramètres d'administration spécifiques configurés et les bons indicateurs activés avant même que le comportement ne soit accessible. En lisant le code en amont, Devin est beaucoup plus susceptible de configurer l'environnement correctement plutôt que de découvrir quelque chose manquant au milieu du test. Le plan de test agit comme une forme de pré-alignement et rend Devin moins susceptible de dériver lors des tests actifs.
Pendant que Devin exécute le plan, il ajoute ses propres annotations dans la chronologie. Celles-ci incluent des notes de configuration, le début de chaque test nommé, et des assertions marquées comme réussies, échouées ou non testées. Nous avons constaté que Devin ment moins sur ses résultats s'il annote son comportement attendu juste avant d'effectuer une action - un peu comme le développement piloté par les tests, si vous vous engagez sur l'attente en amont, il devient beaucoup plus difficile de rationaliser un résultat inattendu comme un succès.
Certaines parties du flux de test se répètent dans presque chaque exécution. La connexion en est l'exemple classique : piloter un formulaire de connexion via l'utilisation de l'ordinateur implique souvent de saisir un email, de compléter l'SSO, de cliquer sur des redirections, et d'attendre chaque chargement de page, capture d'écran par capture d'écran. Cela peut être coûteux à la fois en temps et en jetons. Pour améliorer la fiabilité et le coût de ces actions, Devin a extrait le travail dans un script déterministe qui réside dans une compétence de test dans notre dépôt. Ainsi, Devin peut exécuter le script et obtenir une session de navigateur authentifiée en quelques secondes et passer à la partie centrale du test. La nature déterministe de ces scripts a permis de réduire considérablement l'instabilité. Nous avons mis à jour Devin pour qu'il ferme également cette boucle lui-même. Lorsqu'il découvre une étape de configuration difficile, Devin peut suggérer de sauvegarder cette connaissance en tant que compétence de test dans le dépôt et proposer la correction à l'utilisateur sous forme de PR en un clic.
Nous expérimentons également le routage de la phase de test vers différents modèles. Étant donné que les tests reposent sur des forces différentes de l'écriture de code, comme la lecture de captures d'écran, le suivi de l'état de l'interface utilisateur, et la décision de la prochaine action dans le navigateur, certains modèles sont tout simplement meilleurs que celui que vous choisiriez habituellement pour éditer du code.
Utiliser les tests autonomes dans Devin aujourd'hui
Devin entre actuellement en mode test de deux manières : une demande explicite de tester une modification, ou, après que Devin a créé une PR, il proposera de tester la modification si applicable. Ensuite, il créera le plan de test et commencera à travailler.
Souvent, lorsque vous commencez à utiliser les capacités de test de Devin, il aura besoin de votre aide. Un bon exemple est lorsqu'il a besoin de secrets pour exécuter votre application localement. Pour faciliter ce processus, Devin peut vous demander des identifiants dans la session ou d'autres informations qui pourraient manquer. Pour les cas plus difficiles, vous pouvez prendre le contrôle de l'ordinateur de Devin et entrer des choses comme des codes OTP. La bonne nouvelle est qu'une fois que Devin a fini de configurer votre dépôt, il peut sauvegarder une configuration déclarative sous la forme d'un plan YAML qui produit un instantané pour chaque future session à partir duquel démarrer.
Ce que vous obtenez en retour
Lorsque Devin termine les tests, il ne se contente pas de vous dire si l'application a fonctionné. Un enregistrement d'écran brut est utile, mais nous avons estimé que cela ne suffisait pas en soi - vous devez comprendre ce que vous regardez, pourquoi Devin a effectué chaque action, et quelles parties du test ont réussi ou échoué.
Pour une révision rapide, Devin renverra un rapport de test avec des captures d'écran annotées provenant des moments clés de l'exécution, afin que vous puissiez voir rapidement ce que Devin a testé et à quoi ressemblait l'application au fil du processus.
Si vous souhaitez une révision plus approfondie, Devin produit également une vidéo de test avec une interface de lecture riche qui comporte des chapitres pour vous permettre de sauter entre les sections de test, de parcourir l'intégralité de l'exécution, et d'inspecter les assertions qui ont réussi ou échoué dans une vue de liste chronologique. En post-traitement, le temps mort entre les actions est compressé tandis que les moments autour des actions sont lus à vitesse normale. Ainsi, une longue exécution se condense en un enregistrement que vous pouvez réellement regarder. Ces artefacts sont disponibles dans notre interface web et également distribués sur Slack si Devin a été démarré à partir de là.
Angles difficiles
L'utilisation de l'ordinateur a encore des angles difficiles. Un exemple est le timing - si Devin teste une notification toast, une capture d'écran prise trop tôt ou trop tard peut manquer complètement le toast et les modèles peuvent être confus quant à savoir si le comportement attendu s'est réellement produit.
Un autre mode de défaillance est la tricherie. Livrés à eux-mêmes, les modèles peuvent parfois s'appuyer trop lourdement sur l'exécution de JavaScript dans le navigateur pour déclencher des états par programmation au lieu de cliquer dans l'interface utilisateur. Cela peut être utile pour tester la fonctionnalité, mais les utilisateurs voudront souvent voir Devin utiliser l'application comme le ferait un véritable utilisateur.
Nous travaillons activement sur ces problèmes grâce à des évaluations améliorées, des garde-fous plus stricts dans le harnais, et chaque nouvelle génération de modèles qui s'améliore dans l'utilisation de l'ordinateur.
L'avenir du développement asynchrone est vérifié
Au cours des derniers mois, le nombre de séries de tests approuvées par jour sur Devin a plus que doublé. Cette croissance reflète quelque chose de simple : les agents asynchrones ne sont utiles que si les développeurs peuvent faire confiance à ce qu'ils rapportent. Souvent, cette confiance ne peut pas venir uniquement du code : pour de nombreuses modifications, vous voulez savoir que l'application a réellement été exécutée, que les flux importants ont été testés, et que le résultat a été capturé d'une manière que vous pouvez facilement inspecter.
C'est ce que les tests autonomes dans Devin sont conçus pour fournir. Devin planifie le test, opère l'application, enregistre et annote ce qui s'est passé, et renvoie finalement des artefacts qui rendent le résultat vérifiable. Il reste encore beaucoup à améliorer, mais nous pensons que c'est la bonne forme du futur : des agents qui non seulement accomplissent le travail de manière asynchrone, mais reviennent avec des preuves.
Nous sommes constamment surpris de voir à quel point Devin nous fait gagner du temps en testant son propre travail, et nous pensons que de nombreux clients sous-utilisent encore la fonction de test automatisé de Devin. Pour soutenir l'expérimentation, nous facturons actuellement 1/5e du coût d'utilisation normal pendant le mode test.
Essayez notre travail sur devin.ai ou windsurf.com. Et si travailler sur ce genre de problèmes vous semble amusant, contactez ido [at] cognition.ai
