5BY.AI
개발자 노트Décision de conception
July 23, 2026

Comment maintenir les critères de jugement en confiant la revue de code à une autre IA

On peut expliquer la structure du code à une IA et confier la revue de sécurité ou de performance à une autre.

Mais si la nouvelle IA ne connaît pas les conditions de préservation et l'état des preuves du travail actuel, elle peut reproposer des solutions déjà écartées ou élargir le périmètre.

Ce qui doit être relié dans la revue de code, ce n'est pas seulement des fragments de code, mais les faits confirmés, les conditions interdites et les frontières d'approbation des modifications.

Ce qui manque si l'on ne transmet que le code

Même avec le même diff, sans les informations suivantes, le jugement peut différer :

Saved conserve les preuves

On peut laisser comme Saved les interprétations importantes de journaux, les branches de code et les avertissements de risque.

Saved n'est pas une fonctionnalité qui confirme la réponse de l'IA comme bonne réponse. C'est une coordonnée pour revenir à une question et réponse spécifiques que le prochain réviseur doit revérifier.

Anchor crée le contrat de revue

Avant de passer à une autre IA, on peut organiser dans un Anchor ce qui suit :

L'Anchor ne remplace pas tout le document d'instructions d'implémentation, mais il fournit le critère de départ de l'examen.

Handoff sépare les rôles

On peut confier à une IA l'examen des preuves en lecture seule, et à une autre une revue de diff limitée.

Avec le Handoff, on peut recevoir des perspectives différentes par rôle sans réexpliquer les mêmes critères à chaque fois.

La nouvelle IA ne suit pas inconditionnellement la conclusion précédente. Elle examine indépendamment sur la base des conditions de conservation et des preuves.

On empêche que les solutions se mêlent avant la confirmation de la cause

Le plus dangereux dans la revue de code est de traiter une cause possible comme la cause réelle.

En laissant clairement l'état actuel des preuves dans l'Anchor, on peut réduire le passage arbitraire de la nouvelle IA à la modification, au rollback et au refactoring.

5BY.AI n'approube pas automatiquement le travail. Il transmet à la conversation suivante les Gate et conditions STOP décidés par l'utilisateur.

On examine le flux de revue dans la Graph View

Dans la Graph View de 5BY.AI, on peut examiner comment le Pack d'investigation des causes, les Saved importants, l'Anchor d'approbation des modifications et le Pack de revue ultérieur s'enchaînent.

On peut revérifier ce qui suit, qui disparaît avec le seul commit final :

Workflow réel

  1. On examine l'incident et le flux du code dans la première IA.
  2. On laisse la frontière d'incohérence importante comme Saved.
  3. On crée un Anchor avec la cause et le contrat de conservation.
  4. On fait un Handoff vers une autre IA pour un examen des réfutations en lecture seule.
  5. Si la cause est maintenue, on fixe la portée du patch exact.
  6. Après implémentation, on effectue une revue de diff limitée dans une nouvelle IA.
  7. On enregistre les résultats et les risques restants dans un nouvel Anchor.

Ne remplace pas les enregistrements de développement officiels

Le dépôt de code, les tickets, les résultats de tests et les enregistrements de déploiement doivent rester dans les systèmes officiels.

5BY.AI ne remplace pas ces enregistrements, mais permet de retrouver le flux de jugement formé en examinant avec l'IA.

Ce dont on a besoin en confiant la revue de code à une autre IA, ce n'est pas copier beaucoup d'explications.

C'est maintenir au même point de départ ce qui est prouvé et ce qui ne l'est pas encore, les fonctionnalités à préserver et la portée autorisée.

Les Saved, Anchor et Handoff de 5BY.AI empêchent ces critères de jugement de disparaître entre les fenêtres de conversation et les services d'IA.

Articles et fonctionnalités associés

#5BY.AI#Revue de code#Multi-IA#Contexte de développement#Anchor#Handoff
Comment maintenir les critères de jugement en confiant la revue de code à une autre IA | 5BY.AI