Relis l'intention, laisse les machines vérifier le reste

Les pull requests d'agents arrivent en plus grand nombre, elles paraissent sûres d'elles, et tu ne peux pas demander après coup à l'auteur "à quoi pensais-tu ?". Les premières recherches commencent à montrer ce que cela signifie en pratique.

Une étude portant sur 7 156 PR d'agents a montré que le type de tâche compte plus que l'agent qui l'a écrite : "documentation tasks achieve 82.1% acceptance compared to 66.1% for new features." Aucun agent n'a gagné dans toutes les catégories. [2] Une seconde étude a examiné 654 PR d'agents rejetées et identifié sept modes de rejet qui n'apparaissent que dans les PR d'agents — et que "a large proportion of rejected PRs (67.9%) lack explicit reviewer feedback." [1] Autrement dit : la plupart du temps, personne ne dit à l'agent pourquoi.

Les deux études utilisent le même jeu de données public de PR d'agents (AIDev), et toutes deux ont été publiées en février 2026 ; les agents ont évolué depuis — lis ces chiffres comme une tendance, pas comme un classement.

Tout ce qu'une machine peut vérifier ne devrait jamais atteindre un humain : formatage, types, lint, complexité, tests. Chacun de ces points a sa place plus tôt dans la chaîne — lors de l'édition de l'agent, au commit, en CI. On explique comment mettre ça en place dans notre guide sur le feedback instantané pour les agents de code.

Le guide de relecture de code de Google s'applique encore aux agents : le relecteur regarde la conception, la fonctionnalité, la complexité, les tests, le nommage et les commentaires — ce qui rend une base de code plus saine avec le temps. [3] La différence avec les agents, c'est que la partie mécanique de cette liste peut être automatisée presque entièrement.

"C'est fait, tous les tests passent" est une affirmation. Demande plutôt des preuves. Ajoute une ligne de remise dans chaque story demandant à l'agent de "summarize changed files, checks run, failures encountered, and any remaining risk." [8] Les Cloud Agents de Cursor peuvent aussi joindre des captures d'écran, des vidéos et des références de logs à la pull request, pour que tu puisses voir le changement fonctionner sans récupérer la branche. [7]

## What changed
- auth/login-form.tsx — locked-account message + reset link
- auth/login-form.test.tsx — new test for the locked case

## Checks run
- npm run typecheck ✔
- npm test -- auth ✔ (14 passed)

## Failures hit
- First run broke the signup error style; fixed by reusing ErrorBanner.

## Remaining risk
- Copy not reviewed by product. Lockout threshold unchanged (non-goal).

Ne laisse pas l'agent noter son propre travail. Un relecteur automatique dans un contexte neuf repère des choses dont l'auteur ne peut pas se rendre compte. La documentation de Claude Code décrit un schéma rédacteur/relecteur : "A fresh context improves code review since Claude won't be biased toward code it just wrote." [4] Cursor Bugbot "analyzes PR diffs and leaves comments with explanations and fix suggestions" [5], et GitHub Copilot code review fait de même sur GitHub. [6] Claude Code sur le web peut aller plus loin et corriger automatiquement les pull requests : il surveille une PR et réagit aux échecs de CI et aux commentaires de relecture — un bon exemple de renvoi des constats à l'agent. [9]

Il y a un revers, et la même documentation est honnête à ce sujet :

"A reviewer prompted to find gaps will usually report some, even when the work is sound, because that is what it was asked to do. Chasing every finding leads to over-engineering." [4]

N'agis donc que sur les constats qui affectent la correction ou les exigences énoncées. Tout le reste est optionnel.

Rappelle-toi les 67,9 % : la plupart des PR d'agents rejetées ne portent aucune raison explicite. [1] Quand tu rejettes une PR ou demandes des changements, dis pourquoi — dans la PR ou dans la story. "Faux" n'apprend rien. "Cela devrait réutiliser l'ErrorBanner existant, voir signup-form.tsx" corrige cette exécution et la suivante. Si le même retour revient sans cesse, il a sa place dans vos conventions partagées, pas dans un commentaire de plus.

L'argument de ce guide est que la relecture devrait se faire par couches : d'abord les machines, puis un relecteur indépendant, toi en dernier — mesuré par rapport à la story. Aerunit couvre la couche intermédiaire et l'étalon. Quand un agent ouvre une pull request, Aerunit la relit automatiquement et peut renvoyer les constats à la même session de l'agent pour qu'il les corrige, afin que la PR que tu ouvres ait déjà subi un premier passage.

L'étalon, c'est la story elle-même : le story writer d'Aerunit propose des issues Linear avec périmètre, critères d'acceptation et non-objectifs, afin que tu relises par rapport à une cible nommée. Et les conventions d'équipe que tu répéterais sinon dans des commentaires de relecture vivent une seule fois dans un contexte et des skills partagés, injectés dans chaque story et chaque exécution.