Cognition mise sur les tests Devin GPT-6 Astra pour remplacer la revue de code par des preuves

Cognition a étendu les tests Devin GPT-6 Astra à trois produits, faisant de la vérification le nouveau terrain de confrontation de l’ingénierie logicielle autonome. Le modèle prend désormais en charge les tests dans Devin Cloud, Devin Desktop et Devin CLI. Il peut utiliser des applications, inspecter les résultats et fournir des preuves visuelles en plus de rapports écrits.

Le changement important n’est pas que Devin puisse générer davantage de code. Les agents de programmation produisent déjà des correctifs, ouvrent des pull requests et exécutent des suites de tests. Cognition veut désormais que Devin présente des preuves que ses modifications fonctionnent, afin de réduire la quantité de code généré que les ingénieurs doivent inspecter manuellement.

Cette promesse met sous pression le développement traditionnel centré d’abord sur la revue. Elle soulève également une question difficile pour Cognition, OpenAI et tous les agents de programmation concurrents. Un agent peut-il évaluer de manière fiable un travail produit par le même système automatisé, ou l’attention humaine se déplace-t-elle simplement de la revue de code vers la revue des preuves ?

Les tests Devin GPT-6 Astra produisent désormais des preuves examinables

Cognition présente les preuves de test, et non la seule génération de code, comme le livrable que les ingénieurs devraient évaluer.

OpenAI a publié son cas de test Devin le 11 septembre 2026. L’entreprise indique que Cognition applique GPT-6 Astra à son agent cloud, à son interface en ligne de commande et à son application de bureau.

Cognition avait déjà ajouté Astra à Devin le 3 septembre. Son déploiement du modèle indique qu’Astra est disponible directement dans Devin Desktop et Devin CLI. Le modèle fait également partie du mélange de modèles utilisé par Devin Cloud.

L’intégration sépare deux tâches que les produits de programmation présentent souvent comme un flux de travail unique et continu. Un modèle peut mettre en œuvre une modification, tandis qu’Astra peut aider à piloter la phase de test. Cette distinction importe, car modifier du code et valider une application exigent des capacités différentes.

Un modèle de programmation raisonne avant tout sur les dépôts, les spécifications et les modifications du code source. Un testeur d’applications doit aussi interpréter les écrans, suivre l’état de l’interface, utiliser le logiciel et déterminer si le comportement observé correspond au résultat attendu.

Cognition affirme qu’Astra est particulièrement performant pour ce second ensemble de tâches. L’entreprise fait état de résultats de pointe sur un benchmark interne de tests. Elle n’a pas publié suffisamment de détails pour que des tiers puissent reproduire ou vérifier indépendamment ce résultat précis.

Les exemples publics précisent ce que Cognition entend par vérification autonome. Dans une démonstration, Devin teste Otter Run, un jeu iPhone, dans un simulateur. Il renvoie un enregistrement du jeu en cours d’exécution et un rapport décrivant les vérifications réussies.

Le rapport identifie aussi les domaines que Devin n’a pas testés. Cette réserve est importante, car une vidéo soignée pourrait autrement laisser entendre une couverture plus large que celle réellement obtenue lors de l’exécution.

L’enregistrement montre un comportement observable, tandis que le rapport définit le périmètre revendiqué. Ensemble, ils donnent à un relecteur un élément plus proche d’un artefact de test que d’un résumé conventionnel d’agent.

Un autre flux de travail commence par une capture d’écran d’un bug fournie par un client. Cognition indique que l’équipe peut envoyer cette image à Devin, qui diagnostique le problème, modifie le code et renvoie une autre capture d’écran montrant le résultat.

La séquence relie un défaut visible à un résultat visible. Elle peut raccourcir la boucle de feedback pour les problèmes d’interface difficiles à expliquer uniquement à l’aide de journaux ou de commentaires de pull request.

Toutefois, une capture d’écran ne prouve que ce qui est apparu à un instant donné. Elle n’établit pas que les parcours associés fonctionnent encore, que l’implémentation sous-jacente est maintenable ou que le défaut reste corrigé dans des conditions différentes.

La fonctionnalité la plus utile est donc le dossier de preuves. Les ingénieurs peuvent comparer le comportement demandé, le plan de test déclaré, les actions enregistrées et les zones non testées avant de décider de fusionner.

Cela modifie l’unité de revue. Au lieu de recevoir seulement un diff et une assurance rédigée par l’agent, l’ingénieur reçoit une affirmation étayée par une trace d’exécution.

Ce changement constitue le pari central de Cognition. Si les relecteurs font confiance à la trace, ils peuvent consacrer moins de temps à reconstituer ce qui s’est passé à partir du code généré. Sinon, les artefacts supplémentaires deviennent une couche de plus à inspecter.

Pourquoi la vérification est devenue le goulot d’étranglement des agents de programmation

Dans le développement agentique, la ressource limitante passe de la production de code à la capacité de revue digne de confiance.

Les agents de programmation peuvent créer des modifications plus rapidement que la plupart des équipes ne peuvent les évaluer. Lorsque plusieurs agents fonctionnent simultanément, chaque session réussie peut générer une nouvelle branche, une pull request, un rapport de test ou une décision de suivi.

Cognition indique que ses propres ingénieurs ont exécuté entre 10 et 20 sessions Devin en parallèle. Chaque session peut faire fonctionner un serveur de développement distinct dans le cloud. Un tel degré de concurrence serait peu pratique sur l’ordinateur portable d’un seul ingénieur.

Davantage de concurrence ne crée pas automatiquement plus de valeur en production. Elle peut au contraire générer une file de modifications plausibles en attente d’une vérification humaine.

Cette file est particulièrement difficile à traiter, car le code généré peut sembler raisonnable avant d’échouer à l’exécution. Un relecteur peut devoir reconstituer l’environnement, lancer l’application, répéter le flux signalé et examiner les comportements voisins.

Cognition a décrit ce défi comme faisant partie d’une évolution plus large vers le développement asynchrone. Davantage de sessions Devin sont désormais déclenchées par des calendriers, des automatisations, des événements et d’autres instances de Devin que par des demandes interactives directes.

Un agent de programmation asynchrone travaille pendant que son propriétaire humain s’occupe d’autre chose. Cette organisation ne permet d’économiser de l’attention que lorsque le résultat renvoyé est compréhensible et suffisamment fiable.

Sans vérification, les ingénieurs reviennent face à une pile de diffs inexpliqués. Ils doivent retrouver le contexte de chaque tâche avant de décider si le travail est utile.

Le précédent récit de Cognition sur la vérification par agent indique que les exécutions quotidiennes de tests approuvées ont plus que doublé en plusieurs mois. Il s’agit d’une activité produit rapportée par l’entreprise, et non d’une mesure indépendante de la fiabilité ou de la valeur client.

La direction prise reste néanmoins logique. À mesure que les agents génèrent davantage de modifications, les équipes ont besoin de preuves compactes leur indiquant quels résultats méritent leur attention.

L’objectif n’est pas d’éliminer immédiatement le jugement humain. Il consiste à rendre ce jugement moins coûteux en rapprochant les observations pertinentes de la tâche achevée.

Un dossier de preuves utile peut répondre à plusieurs questions avant qu’un ingénieur ne lise l’implémentation. L’application a-t-elle démarré correctement ? La fonctionnalité modifiée est-elle apparue ? Quel parcours utilisateur l’agent a-t-il suivi ? Qu’est-ce qui est resté hors du périmètre du test ?

Ces questions ont souvent plus de valeur que l’affirmation d’un agent selon laquelle tous les tests ont réussi. Une suite de tests conventionnelle n’évalue que les assertions que quelqu’un a anticipées et codées.

Les enregistrements d’interface peuvent révéler des changements d’état jamais représentés dans des tests unitaires. Les notes écrites sur le périmètre peuvent aussi exposer les lacunes de couverture au lieu de les enfouir dans un long journal d’exécution.

La pression dépasse Cognition. Codex d’OpenAI, les systèmes de programmation soutenus par Anthropic, les agents développeurs de Google, Cursor et les frameworks open source se disputent tous les charges de travail d’ingénierie.

Chaque produit peut améliorer son score de génération de code. Pourtant, l’adoption en entreprise dépend de ce qui se passe après la génération, lorsqu’une personne responsable doit approuver une modification importante.

C’est pourquoi le principal adversaire n’est pas un modèle concurrent en particulier. C’est le flux de travail centré sur la revue, fondé sur la lecture de chaque ligne significative avant de faire confiance au résultat.

Ce flux de travail existe pour de bonnes raisons. Le code communique l’architecture, les futurs coûts de maintenance, les hypothèses de sécurité et les comportements de défaillance qu’une courte démonstration pourrait ne jamais révéler.

Cognition ne prétend pas que ces préoccupations disparaissent. Son objectif déclaré est d’amener les ingénieurs à examiner moins de code au fil du temps tout en livrant davantage de travail achevé.

Cette formulation laisse place à une revue sélective. Les équipes pourraient examiner étroitement les modules à haut risque tout en acceptant une revue guidée par les preuves pour des correctifs d’interface ciblés, des migrations routinières ou des outils internes bien délimités.

L’effet pratique dépendra de la manière dont les équipes préservent le contexte des tâches. Une base de connaissances d’ingénierie peut aider les relecteurs à relier les preuves d’un agent aux exigences, aux décisions de conception et aux échecs antérieurs.

La vérification devient plus utile lorsqu’elle reflète ces sources. Un enregistrement propre a moins de valeur si l’agent a mal compris l’exigence qui définissait la réussite.

Astra fait du test une compétence distincte pour les agents

La contribution d’Astra repose sur la combinaison, dans une même boucle de test, de l’utilisation d’ordinateurs, du jugement visuel, du raisonnement sur la base de code et d’un reporting concis.

Un modèle d’utilisation d’ordinateur interprète une interface visuelle et effectue des actions telles que cliquer, saisir du texte, faire défiler et naviguer entre les écrans. Les tests ajoutent une autre exigence : ces actions doivent étayer des assertions explicites sur le comportement attendu.

La boucle de test de Cognition commence par un plan ancré dans le dépôt. L’agent examine le code pertinent avant de déclarer ce qu’il testera. Cela réduit le risque qu’il invente des parcours d’interface ou des hypothèses que l’application ne prend pas en charge.

Le plan crée également un point de référence pour le rapport final. Les relecteurs peuvent voir si l’exécution a couvert le comportement prévu, au lieu de juger un enregistrement sans critères énoncés.

Pendant l’exécution, Devin peut annoter la chronologie avec des notes de configuration et des étapes de test nommées. Il peut marquer les assertions comme réussies, échouées ou non testées.

Cognition affirme qu’exiger de l’agent qu’il énonce une attente avant d’agir réduit la rationalisation. L’agent a moins de latitude pour réinterpréter un écran inattendu comme une réussite après avoir vu le résultat.

Cela rappelle le développement piloté par les tests, où le comportement attendu est défini avant l’implémentation. Ici, cet engagement intervient lors de la vérification comportementale plutôt qu’avant chaque modification de code.

L’agent peut ensuite utiliser un navigateur, un simulateur ou une application de bureau. Il capture ce qui s’est passé et renvoie des artefacts qu’un humain peut inspecter de manière asynchrone.

Astra semble adapté à cette étape, car le modèle a été entraîné pour l’utilisation d’ordinateurs et les tâches professionnelles longues, à plusieurs étapes. OpenAI indique qu’il peut installer des logiciels, résoudre des problèmes visibles et effectuer des vérifications de qualité frontend.

Dans les résultats d’utilisation d’ordinateur publiés par OpenAI, Astra a obtenu 72,6 % sur OSWorld 2.0. GPT-5.6 Sol a obtenu 65,7 % dans la comparaison rapportée.

OpenAI indique également qu’Astra a terminé ces tâches simulées en environ 40 minutes en moyenne. Le modèle antérieur nécessitait approximativement 75 minutes. Ces chiffres proviennent du dispositif d’évaluation d’OpenAI et ne doivent pas être considérés comme des mesures universelles de production.

La même publication fait état d’un score de 57,9 % pour Astra sur Terminal-Bench 4.0. GPT-5.6 Sol a obtenu 37,3 %, tandis que Claude Fable 5.1 a obtenu 55,8 %.

Sur FrontierCode 1.1 Extended, Astra a obtenu 64,5 %. Claude Fable 5 a obtenu 64,9 %, plaçant Astra légèrement derrière ce modèle dans le benchmark de Cognition.

Cognition décrit FrontierCode comme une évaluation propriétaire de tâches réelles d’ingénierie. Son évaluation prend en compte la qualité et la capacité à être fusionnée, et les solutions ne satisfaisant pas aux critères bloquants ne reçoivent aucun crédit.

Ces comparaisons suggèrent que l’attrait d’Astra ne réside pas simplement dans de meilleures performances brutes en programmation. La déclaration publique de Cognition met l’accent sur des rapports plus clairs, des tests plus complets et des vidéos plus faciles à suivre.

Ces qualités influencent directement le temps de revue. Une exécution techniquement réussie peut tout de même gaspiller l’attention humaine si ses preuves sont confuses, verbeuses ou déconnectées du changement demandé.

Un rapport concis devrait identifier le comportement testé, l’environnement, le résultat observé et les incertitudes restantes. Un enregistrement utile devrait permettre de repérer facilement les transitions importantes, plutôt que de contraindre un relecteur à parcourir une session non montée.

Cognition a également conçu des scripts déterministes pour les tâches de configuration répétées. Un script déterministe exécute une séquence définie au lieu de demander au modèle d’improviser chaque action.

L’authentification en est un exemple. Piloter un flux de connexion à partir de captures d’écran peut prendre du temps et introduire des échecs sans rapport avec la fonctionnalité testée.

Un script enregistré peut créer rapidement une session de navigateur authentifiée. L’agent peut alors concentrer son raisonnement sur le comportement qui compte.

Cette conception hybride révèle une leçon d’ingénierie importante. Améliorer les tests autonomes ne signifie pas confier chaque opération à un modèle de langage.

Les systèmes fiables réservent les étapes prévisibles à l’automatisation classique. Ils utilisent le modèle là où l’interprétation, la récupération après erreur ou la navigation flexible apportent une valeur ajoutée.

Cognition permet également à Devin de proposer des compétences de test réutilisables après avoir résolu un problème de configuration difficile. L’utilisateur peut examiner cette automatisation avant de l’ajouter au dépôt.

Avec le temps, cela peut transformer des découvertes répétées en infrastructure stable. Le parcours improvisé par le modèle devient un script examiné pour les futures exécutions.

Cette combinaison contrôle aussi la variabilité. Si chaque test commence avec un comportement de configuration différent, comparer les résultats devient difficile et diagnostiquer les échecs coûteux.

Astra fournit une perception et un raisonnement flexibles. Les scripts déterministes encadrent les actions répétitives. Le plan de test définit la réussite, tandis que le rapport de preuves révèle ce que l’exécution a couvert.

Ce mécanisme est plus conséquent qu’une nouvelle avance dans les benchmarks. Il montre comment les agents de programmation peuvent passer de la production de correctifs plausibles à une participation à des flux de travail d’ingénierie contrôlés.

L’agent ne peut toujours pas corriger seul ses propres devoirs

Les preuves peuvent réduire l’effort de revue, mais elles ne peuvent pas rendre l’auto-vérification indépendante, complète ou automatiquement digne de confiance.

Le risque le plus évident est l’échec corrélé. Si un agent comprend mal la tâche lors de sa mise en œuvre, le même système peut reporter cette incompréhension dans son plan de test.

Le code et le test peuvent alors être cohérents entre eux tout en étant tous deux en désaccord avec l’exigence réelle de l’utilisateur. Un rapport propre documenterait la cohérence, non la justesse.

Des tests indépendants réduisent ce problème lorsqu’ils proviennent de spécifications, d’un autre ingénieur ou d’un système d’évaluation distinct. Les suites de régression existantes imposent également des contraintes que l’agent d’implémentation n’a pas inventées pendant la session.

L’approche de Cognition aide en ancrant les plans dans le code source et en énonçant les attentes avant chaque action. Ces mesures peuvent réduire la dérive, mais elles ne créent pas une véritable indépendance.

L’entreprise a décrit ouvertement des échecs antérieurs. Devin testait parfois des zones sans rapport, se retrouvait bloqué dans la configuration de l’environnement ou manquait le comportement qu’une pull request devait modifier.

Ces problèmes expliquent pourquoi le système a besoin de plans, d’annotations et d’outils de configuration déterministes. Ils montrent également que des preuves soignées dépendent d’une orchestration allant au-delà du modèle sous-jacent.

La preuve visuelle a des limites supplémentaires. Une vidéo peut montrer qu’un flux a fonctionné dans un environnement et un état de données donnés. Elle ne peut pas établir une exactitude générale sur l’ensemble des navigateurs, autorisations, conditions de charge ou entrées malveillantes.

Un rapport peut indiquer avec précision que ces lacunes n’ont pas été testées. Les relecteurs doivent toujours décider si les parcours omis sont suffisamment importants pour bloquer le déploiement.

La couverture devient particulièrement importante pour les modifications de backend, d’infrastructure et de sécurité. De nombreuses défaillances graves ne produisent pas de symptôme visuel évident lors d’une courte exécution.

Une migration de base de données peut sembler réussie avant de corrompre un cas limite. Une modification d’autorisation peut fonctionner pour le compte présenté tout en exposant les données d’un autre locataire.

Le code sensible à la sécurité exige une réflexion adversariale, et pas seulement la confirmation que le comportement attendu s’est produit. Les équipes ont besoin de tests conçus pour briser les hypothèses plutôt que pour rejouer le chemin idéal.

OpenAI applique lui-même des restrictions aux capacités avancées d’Astra en cybersécurité. Le modèle peut aider à l’examen sécurisé et à la correction, tandis que certains flux liés aux exploits restent limités ou surveillés.

Des reportages indépendants sur le lancement d’Astra ont également souligné les questions de sécurité non résolues entourant les travaux autonomes complexes. La fiabilité dans le monde réel reste moins certaine que ne le suggèrent les démonstrations contrôlées.

La qualité logicielle pose un défi à plus long terme. Réussir les tests d’aujourd’hui ne montre pas si des modifications répétées par un agent laissent une base de code compréhensible et adaptable.

Une analyse critique des limites des benchmarks de programmation soutient que les tests actuels passent souvent à côté de l’érosion structurelle. Le code peut rester fonctionnel tout en devenant plus difficile à modifier en toute sécurité.

Cette préoccupation limite directement la proposition de « revoir moins de code ». Les ingénieurs lisent le code pour bien plus que sa justesse immédiate. Ils examinent les abstractions, les frontières de responsabilité, la logique dupliquée, l’observabilité et le coût de maintenance futur.

Une vidéo d’exécution ne peut révéler toutes ces qualités. Un rapport centré sur le comportement visible ne le peut pas davantage.

La bonne politique de revue dépendra probablement du risque. Un ajustement visuel dans un tableau de bord interne mérite un niveau d’examen différent de la logique d’authentification, du traitement des paiements ou d’une infrastructure critique pour la sécurité.

Les équipes peuvent définir des critères de fusion combinant plusieurs types de preuves. Une modification à faible risque pourrait exiger une suite de tests réussie, un flux utilisateur enregistré et un rapport de périmètre complet.

Une modification à risque plus élevé pourrait aussi exiger une revue humaine de conception, des tests de sécurité indépendants et une inspection manuelle des fichiers sensibles. Les preuves de l’agent peuvent soutenir ces contrôles sans les remplacer.

Un autre enjeu concerne l’intégrité des preuves. Les relecteurs doivent avoir confiance que les enregistrements correspondent au commit soumis, à l’environnement, à la configuration et aux données de test.

Si les artefacts peuvent être dissociés du code exact en cours de revue, ils peuvent décrire une version antérieure ou configurée différemment. Une provenance robuste devrait relier chaque affirmation à son état d’exécution.

Cognition n’a pas détaillé publiquement chaque contrôle de provenance derrière le flux de travail mis en avant. Son benchmark interne reste également propriétaire, ce qui limite la comparaison entre laboratoires indépendants.

La revendication concernant le benchmark doit donc être lue comme un signal produit, non comme une mesure établie de la qualité des tests autonomes.

Même les résultats publics d’OpenAI mesurent des tâches délimitées. Les dépôts de production contiennent des hypothèses non documentées, des dépendances instables, des services privés et des règles de publication propres à chaque organisation.

Astra peut améliorer la capacité de l’agent à naviguer dans cette complexité. Il n’élimine pas le besoin de jugement d’ingénierie sur le niveau de preuve suffisant.

La distinction essentielle est celle entre preuve et élément de preuve. Dans la pratique logicielle ordinaire, les tests apportent des éléments indiquant que certains comportements ont fonctionné dans des conditions définies.

Ils prouvent rarement une exactitude totale. Le langage public de Cognition emploie parfois « prouver » de façon conversationnelle, mais les équipes devraient conserver l’interprétation d’ingénierie plus étroite.

Cette prudence ne rend pas la fonctionnalité moins importante. Elle définit où la fonctionnalité peut créer de la valeur sans encourager une confiance dangereuse.

Trois signaux montreront si les ingénieurs peuvent revoir moins de code

La prochaine épreuve consistera à voir si Cognition peut transformer des démonstrations plus solides en une adoption mesurable et consciente des risques dans les équipes de production.

Le premier signal est la reproductibilité indépendante. Cognition devrait publier suffisamment de détails sur son benchmark de tests pour que des tiers puissent comprendre la sélection des tâches, la notation, l’acheminement des modèles et le traitement des échecs.

Des résultats reproductibles renforceraient l’affirmation selon laquelle Astra améliore les tests plutôt que de simplement produire des artefacts plus attrayants. Ils montreraient également à quelle fréquence le système signale honnêtement un échec ou une couverture incomplète.

La qualité des preuves doit être évaluée séparément de l’accomplissement de la tâche. Un agent de test peut atteindre le bon résultat tout en fournissant un rapport inutilisable, ou créer une documentation persuasive pour un test incomplet.

Les mesures utiles pourraient inclure l’exactitude des assertions, les défauts manqués, les faux succès, l’étalonnage de la couverture et le temps de revue. Elles devraient également suivre si les relecteurs prennent la bonne décision de fusion.

Si des évaluations indépendantes confirment des améliorations sur ces dimensions, le flux de travail de Cognition nécessitant moins de revue gagnera en crédibilité. Si les résultats varient fortement selon les dépôts, les équipes auront besoin de règles de déploiement plus limitées.

Le deuxième signal est le comportement en production. Cognition affirme que les exécutions quotidiennes de tests approuvées ont augmenté, mais le seul volume d’approbations n’établit ni une meilleure qualité logicielle ni un coût de revue inférieur.

Les indicateurs les plus solides sont les modifications fusionnées, les taux de défauts échappés, la fréquence des retours en arrière et le temps consacré à la revue de chaque contribution acceptée. Les équipes devraient comparer ces résultats à ceux de modifications similaires gérées par une revue classique.

Cognition a déjà étudié les « heures d’ingénierie productives » comme indicateur commercial. Son évaluation a utilisé 233 sessions retenues et a indiqué qu’environ la moitié se situaient dans un facteur deux des estimations humaines.

L’entreprise a également reconnu que les estimations individuelles restent imprécises. Selon son analyse publiée, des erreurs d’un facteur deux ou trois dans un sens ou dans l’autre sont courantes.

Cette franchise compte, car les affirmations de productivité peuvent se détacher des résultats logiciels. Une estimation des heures économisées ne capture pas le coût d’un défaut découvert après le déploiement.

Les preuves les plus convaincantes relieraient une réduction du temps de revue à une qualité stable ou en amélioration. Si les équipes inspectent moins de code mais connaissent davantage de régressions, le flux de travail ne fait que transférer les coûts en aval.

Si le temps de revue diminue sans aggraver les défauts, les retours en arrière ou la maintenance, la thèse centrale de Cognition devient beaucoup plus solide.

Le troisième signal est la façon dont les concurrents repensent la vérification. Les fournisseurs de modèles et les entreprises d’agents de programmation peuvent répondre avec des agents de revue indépendants, des traces d’exécution plus robustes ou des formats de preuves standardisés.

Une réponse concurrentielle significative confirmerait que la vérification est devenue la principale couche produit. Elle offrirait également aux acheteurs des alternatives pour éviter qu’un agent évalue sa propre production.

Des modèles distincts pour l’implémentation et la revue peuvent introduire une diversité utile. Des fournisseurs, prompts ou systèmes de génération de tests différents ont moins de chances de reproduire exactement la même incompréhension.

Toutefois, la diversité des modèles ne garantit pas à elle seule l’indépendance. Deux agents peuvent toujours s’appuyer sur la même spécification incomplète ou la même suite de tests existante.

Les meilleurs systèmes combineront une conception de tests indépendante, des contrôles déterministes, la provenance des artefacts et des politiques de risque explicites. La revue humaine pourra alors se concentrer sur les décisions que l’automatisation ne peut pas compresser en toute sécurité.

Les responsables d’ingénierie devraient commencer par sélectionner des tâches délimitées où le comportement observable reflète fortement la réussite. Les corrections de bugs d’interface, les flux internes courants et les régressions bien spécifiées sont des candidats pertinents.

Ils devraient exiger que Devin indique ce qu’il n’a pas testé. Ils devraient également comparer ses preuves au commit soumis et conserver les contrôles habituels pour les modifications sensibles.

Les développeurs peuvent utiliser le nouveau flux de travail comme filtre d’attention plutôt que comme autorité. Le rapport indique où regarder, l’enregistrement montre ce qui s’est passé et le code reste disponible lorsque le risque exige une inspection.

Le résultat recherché par Cognition est plausible, mais pas automatique. De meilleurs tests peuvent réduire l’effort de revue uniquement lorsque les preuves restent ancrées dans les faits, bien délimitées et reliées aux résultats en production.

La question la plus importante pour les équipes est donc pratique : quelles modifications pouvez-vous approuver sur la base de preuves d’exécution, et lesquelles exigent encore de lire chaque ligne ayant des conséquences ? Testez délibérément cette frontière avant d’intégrer les tests de Devin GPT-6 Astra à votre processus de fusion par défaut.