Attention is all we have

Les premières semaines avec un agent, on est excité. Il écrit en une heure ce qui prenait une journée, et on se surprend à lui confier des choses qu'on n'aurait jamais commencées seul. Puis, très vite, la journée change de forme. Elle part à relire ses PR, l'une après l'autre : mille lignes toutes vertes, puis les suivantes. Relire le code d'un agent, personne n'a envie de le faire, et c'est pourtant devenu l'essentiel du travail. On relit pour une raison : garder un système qu'on contrôle et qu'on comprend. Je crois que le harness qu'on met autour des agents se juge là-dessus : au contrôle qu'il nous rend pour moins d'attention que la revue, pas à ce qu'il fait produire à l'agent.

Le goulot est passé de l'écriture à la revue#

On livre plus que jamais, et c'est justement le problème. L'écriture coûtait cher, alors elle limitait ce qui arrivait en revue. Elle ne coûte presque plus rien. La revue, elle, coûte toujours la même chose : de l'attention.

Le papier qui a introduit le Transformer, l'architecture des modèles de langage d'aujourd'hui, le dit dans son titre : Attention is all you need. Le modèle porte son attention sur chaque token, sans se fatiguer. Nous, on en a pour quelques heures par jour, et elles ne se multiplient pas en ajoutant des GPU. Chaque ligne que l'agent écrit sans qu'on sache si elle tient attend ces heures-là.

Relire ne tient pas, alors on finit par appuyer sur le bouton#

La réponse évidente, c'est de mieux relire. Mes amis développeurs me racontent tous la même chose : des PR d'agents de plus en plus longues, relues de plus en plus vite. L'un d'eux s'est entendu dire par son équipe : « maintenant, tu ne lis plus le code, tu merges ». Il reste responsable de ce qui part en production, sans plus avoir le moyen de le vérifier.

Ça, c'est le cas ordinaire. Le mien est le cas extrême. Depuis des mois, relire demande une attention que mon énergie ne me permet plus. Je ne relisais pas peu, ni trop vite : je ne relisais rien. Mais j'aime construire, alors j'ai continué : les agents ont écrit chaque ligne de mes outils, phax parmi eux. Quand quelque chose cassait, je voyais l'erreur sans pouvoir aller la corriger. Je disais à l'agent « corrige ça », il corrigeait, et une autre surgissait ailleurs.

Je crois que mon cas montre seulement plus tôt ce qui attend tout le monde, le jour où l'agent écrit plus vite qu'on ne peut lire.

Chaque pratique fait passer un jugement du côté calculé#

À chaque erreur, je me posais la même question : qu'est-ce qui ferait que l'agent la corrige, et que ce genre d'erreur ne revienne plus ? Les réponses, je les range aujourd'hui dans une grille, celle de Birgitta Böckeler (Harness engineering for coding agent users, martinfowler.com, avril 2026). Elle parle du harness utilisateur, ce qu'on met autour de l'agent, à distinguer du harness du fournisseur, la boucle et les outils dans lesquels tourne le modèle. Elle sépare les guides, qui orientent l'agent avant qu'il agisse, des capteurs, qui vérifient après. Chacun est calculé, par un programme qui répond vrai ou faux, ou inféré, par un modèle qui juge.

Deux dimensions. Un guide agit avant l'agent, un capteur après. Chacun est inféré, jugé par un modèle, ou calculé, décidé par un programme. Les guides inférés sont un skill, le CLAUDE.md, un plan que l'agent lit ; un guide calculé est un brief calculé à partir du code. Les capteurs inférés sont une revue par un modèle ou une personne ; les capteurs calculés sont le type checker, le linter, les tests et les fitness functions. Chaque pratique fait passer un jugement vers le calcul, et le capteur calculé est l'optimum.

Inféréun modèle juge

Calculéun programme décide

Guidesavant que l'agent agisse

un skill · CLAUDE.md · un plan que l'agent lit

vers le calcul

un brief calculé à partir du code

Capteursaprès que l'agent a agi

une revue par un modèle ou une personne

vers le calcul

l'optimumtype checker · linter · tests · fitness functions

Un type checker au plus strict et un linter sont des capteurs calculés. Je n'ai plus à me demander si une valeur peut être indéfinie : le compilateur refuse le code, et l'agent corrige. Des tests d'acceptation écrits par une phase, et que la phase qui code ne peut pas modifier, rendent ce capteur fiable. Il ne reste à regarder que ce que les tests vérifient. Un plan qui dit, avant le code, quels fichiers chaque phase va toucher est un guide, et comparer ensuite ce que la phase a touché à ce plan est un capteur calculé. Au lieu du diff, on regarde les écarts que l'agent doit justifier.

L'optimum est toujours du même côté de la grille : le calcul, et d'abord le capteur calculé. Un jugement que porte un programme tient sans notre attention. Ce qui reste inféré, un modèle qui juge ou une personne qui relit, c'est ce que le calcul ne sait pas encore porter, et c'est là que notre attention doit aller. À chaque jugement passé du côté calculé, le système reste un système qu'on contrôle et qu'on comprend. La grille, case par case et avec ses exemples, c'est l'objet de l'article Guides et capteurs.

Un harness vaut ce qu'il t'évite de regarder la prochaine fois.