Coder avec des agents (1) : où placer son attention

Je code avec l'IA tous les jours. Après GitHub Copilot et Cursor, je suis passé à Claude Code, avec OpenRouter et OMP pour ne pas dépendre d'un seul modèle.

Mon clavier s'use moins. Ce qui a le plus changé, c'est l'endroit où passe mon attention.

Le goulot a changé de place

Un agent écrit en quelques minutes ce qui me prenait une journée. Il boit beaucoup moins de café que moi. Donc il en écrit beaucoup plus. Et tout ça, il faut le relire.

Le code est devenu abondant. Mon attention, non. Où la dépenser ? J'ai essayé deux réponses avant de trouver la mienne.

Trois façons de coder avec une IA

La première m'a fait peur, la seconde m'a épuisé.

Tout déléguer : le vibe coding

flowchart LR
    v1["Moi<br/>une envie"] --YOLO--> v2["L'agent<br/>tout le reste"]
    classDef accent stroke-width:3px
    class v1 accent

On décrit, on accepte, on ne lit pas. Pour un prototype jetable, pourquoi pas.

Pour du code qui doit vivre, c'est une bombe à retardement, dont personne n'a lu le minuteur. On ne sait plus ce que fait le code. Les tests vérifient ce que l'agent a écrit, pas ce que je voulais. La dette s'accumule en silence. En équipe, c'est pire : ne pas relire son code, c'est refiler le travail aux collègues qui le relisent. Et je n'apprends rien. Pour moi, c'est non.

Tout contrôler : le micro-management

flowchart LR
    m1["Moi"] --> m2["L'agent"] --> m3["Moi"] --> m4["L'agent"] --> m5["Moi"] --> m6["…"]
    classDef accent stroke-width:3px
    class m1,m3,m5 accent

C'est ce que j'ai fait pendant des mois : une consigne, un diff, je valide, la consigne suivante. Un peu comme apprendre le vélo à quelqu'un sans jamais lâcher la selle.

Le contrôle semble total, mais ça ne se parallélise pas : deux sessions, deux fois plus de questions. Je deviens le goulot. Et mon attention s'émiette : je valide des morceaux sans juger l'ensemble, jusqu'au oui machinal.

Ce que je vise : en amont je cadre, en aval je juge

flowchart LR
    c1["En amont<br/>je cadre"] --> c2["L'agent<br/>code, teste, commite,<br/>se fait relire"] --> c3["En aval<br/>je juge"]
    classDef accent stroke-width:3px
    class c1,c3 accent

La qualité se joue à deux moments : en amont, quand je décide quoi construire, et en aval, quand je juge ce qui a été construit. Le milieu, je le délègue, mais encadré : les tests d'abord, une relecture par un agent qui n'a pas écrit le code.

Le cadrage pèse plus lourd qu'il n'y paraît. Jovi De Croock le dit en une phrase¹ : « If the intent is wrong, proving conformance to it gets you the wrong thing faster. » Une intention fausse, bien exécutée, livre la mauvaise chose plus vite.

Pourquoi ne pas laisser un agent relire ?

Un agent ne se fatigue pas, lit tout jusqu'au bout et ne survole jamais le vendredi à 18 h.

Parce qu'il ne répond de rien. Quand ça casse en production, c'est mon nom sur le commit, pas le sien. Et ce n'est pas lui qu'on appelle. Même gittifacts, qui pousse l'automatisation au plus loin, note dans chaque commit « which human is accountable for that agent » : quel humain répond de l'agent.

Et parce que relire recouvre plusieurs métiers. Chacun attrape des choses différentes.

Qui	Le meilleur pour	Par exemple
Les machines (CI, outils de mesure)	ce qui se vérifie	un test rouge avant le correctif et vert après, la couverture, le score de mutation2, une API ou une dépendance modifiée
L'agent relecteur	ce qui se lit, vite et partout	une convention oubliée, un cas limite non testé, un écart entre le plan et le diff
Moi	ce qui se juge	le bon problème, le contexte (le legacy, les incidents passés), un arbitrage produit

flowchart LR
    C["Un changement"] --> M["Les machines<br/>ce qui se vérifie"]
    M --> A["L'agent relecteur<br/>ce qui se lit"]
    A --> H["Moi<br/>ce qui se juge"]
    H --> L["Livré"]
    classDef accent stroke-width:3px
    class H accent

Chaque étage filtre ce qu'il sait voir. Quand j'arrive, il ne reste que ce que les autres ne savent pas juger : c'est là que mon attention vaut le plus.

L'article donne une règle que je trouve juste : un agent peut ajouter du doute, jamais en retirer. Chez gittifacts, l'avis d'un modèle peut durcir une relecture, jamais l'alléger. Pareil quand une vérification manque : « Unknown means escalate. »

Les deux casquettes

Si je ne garde que le cadrage et le verdict, je dois porter le quoi et le pourquoi autant que le comment. Un agent fait ce qu'on lui demande. Quand la demande est floue, il comble les trous avec ce qu'il trouve. Il lui manque le contexte métier, le recul business et l'expérience.

Un exemple inventé et volontairement simpliste :

flowchart TD
    D["« Il nous faudrait<br/>un export<br/>des commandes »"]
    D -- "l'agent seul" --> A1["Toutes les commandes,<br/>en direct, testé<br/>sur 20 lignes"] --> A2["En production :<br/>un gros client<br/>cause un timeout"]
    D -- "casquette produit" --> P["Pour qui ?<br/>Pour quoi faire ?"] --> P2["« Pour la compta,<br/>chaque mois »<br/>donc l'export du mois"]
    P2 -- "casquette tech" --> T["On connaît la contrainte de prod :<br/>un client passe<br/>200 000 commandes par mois"] --> T2["On propose des jobs<br/>asynchrones par lots"]
    classDef accent stroke-width:3px
    class P,T accent

La casquette produit réduit le besoin : l'export du mois, pas tout l'historique. La casquette tech connaît ce que le code ne dit pas : le volume réel en production. D'où des jobs asynchrones, par lots. L'agent, lui, a fait exactement ce qu'on lui demandait, et ses tests passent.

Je cadre donc d'abord le produit, puis la technique. Et je relis d'abord le job to be done : le comportement livré est-il celui demandé ? La maintenabilité et la performance viennent après.

Pourquoi je relis quand même

Jovi De Croock va plus loin que moi : « Humans approve intent. Machines prove conformance. » Quand les vérifications automatiques (tests, couverture, mutations) montrent qu'un changement est sans risque, sa plateforme le fusionne sans humain. À deux conditions : chaque changement part derrière son propre feature flag et s'annule en quelques secondes, et la plateforme a d'abord montré qu'elle classe les changements comme les humains l'auraient fait.

Moi, je relis encore. Pour quatre raisons.

• Je réponds de ce que je livre, et de ce qui casse.
• Je veux comprendre avant de livrer. Un code que je n'ai pas compris, je ne sais ni le défendre ni le réparer en urgence. Et je ne peux pas capitaliser dessus quand on itère : il faut partir d'une base que l'IA n'est pas seule à connaître.
• Je veux pouvoir challenger l'agent. Pourquoi cette requête ? Pourquoi pas la méthode qui existe deux fichiers plus loin ?
• Je veux continuer d'apprendre. C'est en relisant que j'apprends le plus sur le code et le produit.

Comprendre le code sert aussi loin de l'éditeur. Quand on imagine une fonctionnalité avec le product manager et l'équipe, il faut savoir sur quoi on s'appuie. On ne va pas ouvrir un chat avec l'IA en pleine réunion à chaque doute. Pour avancer, il est très utile de savoir ce qu'il y a sous le capot.

Où l'humain s'arrête

Je ne suis pas le seul à chercher le bon réglage. Voici les méthodes que j'ai regardées, rangées du tout-délégué au tout-contrôlé. La jauge compte la place de l'humain.

Méthode	Part de l'humain	Qui valide le plan	Qui relit le code	Qui fusionne
Vibe coding	○○○○○○	personne	personne	l'agent
AI-Driven Dev (mode autonome)	●○○○○○	l'humain, via un ticket	un agent	l'équipe, selon son processus
gittifacts, de Jovi De Croock	●●○○○○	l'humain	des machines et un agent, l'humain si c'est risqué	la file de merge, seule quand rien n'est risqué
killer-saas, de Mike Codeur	●●●○○○	l'humain	un agent, puis l'humain	l'agent
Mon workflow	●●●●○○	moi	un agent, puis moi	moi
Skills de Matt Pocock	●●●●●○	l'humain, spec et tickets	l'humain à chaque commit, puis un agent	l'humain
Micro-management	●●●●●●	l'humain	l'humain, à chaque diff	l'humain

Tout le monde s'accorde sur le noyau : un plan validé en amont, un juge qui n'a pas écrit le code en aval. Les méthodes divergent sur ce qui vient après. killer-saas est la plus proche de la mienne, à un geste près : elle laisse l'agent fusionner. Elle part d'un produit neuf. Moi, d'un code qui existe déjà et que toute une équipe maintient. La fusion, je la garde.

Où je place mon attention

Pas partout. Sur trois choses.

1. En amont, sur l'intention. C'est là qu'une minute d'attention rapporte le plus.
2. En aval, sur ce qui se juge. Ce qui se vérifie, les machines le font mieux que moi. Ce qui se lit, l'agent relecteur aussi. Il me reste le bon problème, le contexte et l'arbitrage produit.
3. Sur assez de code pour en répondre. De quoi le défendre, le réparer en urgence et en parler avec l'équipe sans demander à l'IA.

Le reste, je le délègue : écrire, tester, la première relecture. Et j'arrête de regarder chaque diff au fil de l'eau. Mes yeux me remercient.

Les questions qui restent

Le jugement qu'il faut pour relire une machine, on l'a acquis en écrivant. Si l'agent écrit à notre place, où s'entraîne-t-on ? Les juniors le sentiront en premier. Je n'ai pas encore de réponse.

Et une autre question en découle : comment relire le code d'un collègue ? S'il a codé avec une IA et l'a déjà relu lui-même, ma relecture apporte-t-elle encore quelque chose ?

Tout ça me donne envie de creuser la relecture entre collègues : ce qu'un regard humain apporte encore quand l'auteur a déjà fait relire son code par un agent, et comment se répartir le travail sans relire deux fois la même chose.

Et je vous dois plus de détails sur le workflow sur lequel j'itère encore : un plugin pour Claude Code, quatre rôles, deux arrêts, un journal qui apprend d'un projet à l'autre, et beaucoup de choses qui ne marchent pas encore. Je ne promets pas laquelle des deux notes sortira la première. Celle qui sera prête, sans doute.

Mise à jour du 28 octobre 2026. Entre-temps, j'ai continué d'itérer sur mon workflow. Mais je ne veux pas non plus réinventer la roue.

Je me suis donc inscrit à Software Factories for Real Engineers, la formation de Matt Pocock. Je mets mon workflow en pause le temps de la suivre, puis je reviendrai sur ce qu'elle m'a appris, et sur ce qui reste du mien.