Vérifier le travail d’un agent : les artifacts d’Antigravity

La vraie question, avec un agent autonome, n’est pas « sait-il coder ? » mais « comment je vérifie ce qu’il a fait sans tout relire ? » Antigravity répond par les artifacts : des livrables structurés que l’agent produit au fil de l’eau — plan, liste de tâches, différences de code, récapitulatif, captures d’écran, et même enregistrements vidéo de ses tests dans un navigateur. Ce tutoriel vous apprend à lire ces livrables et à corriger le tir par des commentaires ciblés, sans jamais interrompre l’agent.

🎯 Ce que vous allez apprendre

• Reconnaître les différents types d’artifacts et savoir lequel lire en premier.
• Valider une fonctionnalité à partir du récapitulatif et des captures plutôt qu’en relisant tout le code.
• Laisser des commentaires ciblés sur un livrable pour faire corriger l’agent.
• Comprendre comment l’agent teste dans un navigateur et relire la vidéo de son test.

🛠️ Ce que vous allez construire

Nous enrichissons l’application Suivi d’une fonctionnalité concrète : marquer une tâche comme terminée. Mais l’enjeu du jour n’est pas le code lui-même — c’est la vérification. Vous allez confier la fonctionnalité à un agent, puis jouer pleinement votre rôle de relecteur : lire le plan, inspecter la différence de code, regarder la capture de l’interface, et demander un ajustement par un commentaire. À la fin, vous saurez juger le travail d’un agent avec méthode.

Prérequis

• L’application Suivi avec son API et sa page web — voir Orchestrer plusieurs agents avec l’Agent Manager.
• Antigravity connecté, niveau d’autonomie « supervisé ».
• Niveau : débutant ayant déjà lancé et suivi un agent.
• ⏱️ Temps estimé : ~30 minutes.

Étape 1 — Comprendre ce qu’est un artifact

Il faut d’abord changer un réflexe hérité de la programmation manuelle. Quand on écrit soi-même chaque ligne, la confiance vient du geste : on sait ce qu’on a tapé. Avec un agent, la confiance doit venir d’ailleurs — de la preuve. C’est tout le sens des artifacts : transformer un travail invisible en éléments examinables. Un agent qui dit « c’est fait » ne vaut rien sans trace ; un agent qui joint un plan, une diff et une vidéo de test vous donne de quoi juger. Adopter cette posture de « faire confiance, mais vérifier » est sans doute la compétence la plus importante de tout ce parcours, car elle conditionne votre capacité à déléguer sereinement des tâches de plus en plus larges.

Avant de cliquer, posons le vocabulaire, car c’est lui qui structure toute la relecture. Un artifact est un livrable produit par l’agent pour communiquer son travail. Là où un humain dirait « j’ai fait ci, regarde ça », l’agent matérialise chaque chose sous une forme consultable. On distingue plusieurs types complémentaires :

• La liste de tâches : le découpage de l’objectif en étapes, cochées au fur et à mesure.
• Le plan d’implémentation : l’architecture envisagée, les fichiers touchés, les choix techniques et leurs justifications.
• Les différences de code (diffs) : exactement ce qui a changé, en vert et rouge, prêt pour la revue.
• Le récapitulatif (walkthrough) : un résumé en clair de ce qui a été fait, accompagné des résultats de test.
• Les captures d’écran : l’état de l’interface avant et après.
• Les enregistrements de navigateur : une vidéo de l’agent en train de tester l’application dans un vrai navigateur.

On accède à ces livrables depuis l’Agent Manager (bouton en haut à droite) ou depuis l’éditeur (bouton « Artifacts » en bas à droite). Retenez l’ordre de lecture utile : liste de tâches d’abord, pour vérifier le périmètre ; plan ensuite, pour comprendre l’approche ; diff et récapitulatif enfin, pour valider l’exécution.

Étape 2 — Lancer la fonctionnalité et lire le plan

Confiez la tâche à un agent, en mode Planning pour qu’il produise un plan détaillé :

Dans le projet suivi, ajoute la possibilite de marquer une tache comme
terminee. Cote API, ajoute une route PATCH /tasks/:id qui passe le champ
"terminee" a true. Cote interface, ajoute une case a cocher devant chaque
tache qui appelle cette route. Mets a jour l'affichage en consequence.

Dès que l’agent a réfléchi, ouvrez le plan d’implémentation. C’est votre première occasion de corriger une trajectoire avant qu’une seule ligne ne soit écrite. Vérifiez les fichiers qu’il compte modifier (server.js et public/index.html attendus), la forme de la route, et la logique d’affichage. Lire le plan coûte une minute ; laisser l’agent coder dans la mauvaise direction coûte bien plus. Si le plan vous convient, laissez-le exécuter.

✅ Point d’étape — Le plan doit mentionner une route PATCH /tasks/:id et une modification de la page web. S’il propose autre chose (par exemple supprimer la tâche au lieu de la marquer), c’est le moment d’intervenir, pas après.

Étape 3 — Inspecter la différence de code

Une fois l’agent au travail, le livrable le plus précieux pour un développeur est la différence de code. Plutôt que d’ouvrir chaque fichier, vous lisez d’un bloc tout ce qui a changé. Cherchez trois choses : la nouvelle route est-elle correcte ? La gestion d’un identifiant inexistant est-elle prévue ? Le code touche-t-il uniquement ce qui devait l’être ?

Ce dernier point est crucial. Un agent peut, en passant, reformater un fichier entier ou renommer une variable qui n’avait rien demandé. La diff révèle immédiatement ces effets de bord. Si vous voyez des changements hors périmètre, vous le noterez en commentaire à l’étape suivante. La diff n’est pas une simple jolie présentation : c’est votre principal outil de contrôle qualité.

Étape 4 — Regarder l’agent tester dans un navigateur

C’est l’une des capacités les plus marquantes d’Antigravity : un agent peut piloter un vrai navigateur pour tester ce qu’il vient de construire. La première fois, il vous proposera d’installer une extension de navigateur dédiée (côté Chrome) et de lui accorder les permissions nécessaires. Une fois en place, l’agent peut cliquer, faire défiler, saisir du texte, capturer le DOM, prendre des captures et enregistrer une vidéo de la session.

Pour notre fonctionnalité, l’agent ouvre public/index.html, coche une tâche, et vérifie qu’elle apparaît bien comme terminée. Le résultat se retrouve dans deux artifacts : une capture d’écran de l’interface après l’action, et un enregistrement de la manipulation. Regarder cette vidéo de quinze secondes vous en dit plus que dix minutes de lecture de code : vous voyez, littéralement, la fonctionnalité marcher — ou échouer.

Prenons un exemple concret de lecture de diff. Sur notre route PATCH /tasks/:id, vous devez voir apparaître quelques lignes ajoutées : la déclaration de la route, la recherche de la tâche par identifiant, la mise à jour du champ, et la réponse. Le bon réflexe est de chercher ce qui manque autant que ce qui est présent. La tâche introuvable est-elle gérée par une réponse 404, ou le code plante-t-il sur un identifiant inconnu ? Le champ est-il bien remis à la bonne valeur, et pas écrasé par tout le corps de la requête ? Une diff de quinze lignes se lit en trente secondes et révèle ces fragilités bien plus vite qu’un test manuel exhaustif. C’est cette efficacité de lecture qui justifie d’en faire votre premier outil de contrôle.

✅ Point d’étape — Dans le récapitulatif, l’agent doit indiquer que le test a réussi, avec une capture montrant une tâche cochée. Pour confirmer de votre côté : curl -X PATCH http://localhost:3000/tasks/1 puis un GET /tasks où la tâche 1 affiche "terminee":true.

Pourquoi la vidéo change la relecture

On sous-estime souvent l’apport de l’enregistrement de navigateur. Un test décrit en mots — « j’ai coché une tâche, elle est passée en terminée » — repose sur la parole de l’agent. La vidéo, elle, montre la réalité du comportement : l’animation, le temps de réponse, un éventuel scintillement de l’interface, un message d’erreur fugace dans un coin. Elle capture ce qu’aucun récapitulatif textuel ne dira jamais, parce que l’agent lui-même ne l’a peut-être pas remarqué. Pour une fonctionnalité visuelle, regarder les quelques secondes d’enregistrement est le moyen le plus dense d’acquérir la certitude que « ça marche vraiment », et pas seulement « d’après l’agent ». C’est aussi un excellent outil de communication : cette vidéo, vous pouvez la montrer à un collègue ou la conserver comme preuve de recette.

Étape 5 — Corriger par un commentaire ciblé

Supposons que tout marche, mais qu’un détail vous gêne : une tâche terminée reste en haut de liste, alors que vous la voudriez en bas, grisée. Inutile de tout reprendre ni de réécrire une longue consigne. Antigravity permet de commenter directement un livrable, à la manière des commentaires d’un document partagé.

Sélectionnez l’élément concerné dans l’artifact — par exemple la ligne du plan ou la portion de récapitulatif décrivant l’affichage — et ajoutez un commentaire en clair : « Les tâches terminées doivent passer en bas de la liste et apparaître grisées. » Validez. L’agent ingère ce retour et itère, sans que vous ayez eu à interrompre son fil ni à reformuler tout le contexte. C’est la boucle de feedback qui fait la différence : vous dialoguez avec le travail, pas seulement avec l’agent.

Ce mécanisme change la posture du relecteur. Au lieu de subir un gros bloc de code à prendre ou à laisser, vous affinez par petites touches, exactement comme vous annoteriez le brouillon d’un collègue. C’est plus précis, plus rapide, et cela laisse une trace claire de vos demandes.

Un dernier point mérite attention : à mesure que vous corrigez par commentaires, l’agent apprend vos préférences. Antigravity peut enregistrer du contexte utile dans une base de connaissances, si bien qu’une exigence répétée — par exemple « toujours gérer le cas d’identifiant introuvable » — finit par être anticipée plutôt que rappelée à chaque fois. La relecture d’aujourd’hui réduit donc la relecture de demain. C’est un cercle vertueux, à condition de rester précis dans vos retours : un commentaire flou apprend une règle floue.

🐞 Pièges fréquents

✅ Récapitulatif

Vous savez désormais lire un agent autant que son code. Vous connaissez les six grands types d’artifacts et l’ordre dans lequel les parcourir : liste de tâches pour le périmètre, plan pour l’approche, diff et récapitulatif pour l’exécution, captures et vidéo pour la preuve que ça marche. Surtout, vous savez corriger par commentaire ciblé, en dialoguant avec le livrable plutôt qu’en réécrivant tout. Cette discipline de relecture est ce qui rend l’autonomie de l’agent réellement exploitable : on délègue l’exécution, on garde le jugement.

🧾 Aide-mémoire

💪 À vous de jouer

Demandez à l’agent d’ajouter un compteur « X tâches terminées sur Y », puis vérifiez la fonctionnalité uniquement à partir des artifacts, sans ouvrir vous-même le navigateur. Réussir cette relecture « à l’aveugle » prouve que vous maîtrisez la lecture des livrables.

À lire aussi

• Cadrer un agent : AGENTS.md, Rules et Workflows — pour imposer en amont les conventions que vous corrigez aujourd’hui à la main.
• Orchestrer plusieurs agents avec l’Agent Manager — pour relire les livrables de plusieurs agents en parallèle.

Ressources officielles

• Tutoriel Google : Getting Started with Google Antigravity
• Annonce développeurs : Build with Google Antigravity

FAQ

Les enregistrements de navigateur sont-ils conservés ?
Ils restent attachés à la conversation de l’agent en tant que livrables. Tant que vous gardez la conversation, vous pouvez revoir la vidéo et les captures associées.

Dois-je quand même lire le code ?
Pour les changements sensibles ou critiques, oui : la diff est faite pour ça. Pour le tout-venant, le récapitulatif et les captures suffisent souvent à valider. L’idée n’est pas de ne jamais lire le code, mais de ne plus avoir à tout lire systématiquement.

Le commentaire fonctionne-t-il aussi pendant que l’agent travaille ?
Oui, c’est l’intérêt : vous pouvez annoter un livrable sans interrompre l’exécution en cours. L’agent prend en compte le retour et ajuste, ce qui évite les allers-retours brutaux de type « stop, recommence ».