Après le travail sur la gestion du contexte et l’orchestration, je reviens à quelque chose de plus terre à terre : le code. Je peux organiser les fichiers, alléger les consignes, isoler les agents ; à la fin, ce qui compte, c’est que la feature réponde vraiment à ce que je voulais construire.
J’avais une constitution claire et des fichiers d’instructions bien tenus. Sur le papier, ça tenait. Dans le code, c’était autre chose : l’IA génère, interprète, oublie parfois une contrainte et accumule. Or le code n’est pas une victoire en soi. Comme le rappelle Software Engineering at Google, le code est aussi une charge à maintenir. Plus l’agent produit vite, plus il peut aussi introduire de duplication, de dette ou de code smells. Il me fallait des garde-fous, pas seulement de bonnes consignes.
À ce moment-là, je mets surtout en place des outils pour tenir la qualité. Les consignes ne suffisent pas : il faut des boucles de feedback, des tests, des hooks, des contrôles, des retours assez clairs pour que l’agent voie où ça casse et corrige pendant qu’il travaille.
État des lieux
À cette date, beaucoup d’outils font déjà partie de mon quotidien de développeur. Je finis donc par les mettre aussi dans la boucle des agents : prompts réutilisables, commandes, constitution projet, orchestrateur, CI qui bloque les PR cassées, et mécanique pour générer les bons fichiers de contexte selon l’outil utilisé.
Mon travail reste du développement, mais il se déplace : je passe moins de temps à écrire les lignes moi-même, et plus de temps à solidifier l’environnement dans lequel les agents travaillent. Le sujet n’est plus seulement d’empiler de meilleures consignes. C’est de rendre la qualité vérifiable.
Quand les règles deviennent exécutables
À partir de là, je cherche surtout à raccourcir la boucle. L’IA génère du code, le système répond. Si ça casse, je veux un retour clair, au bon moment, pour que l’agent corrige tout de suite. Je déplace certaines règles répétables hors du prompt : elles deviennent des contrôles exécutés par le système, puis renvoyés à l’agent sous forme de retour exploitable.
On parle souvent de DX, la Developer Experience pensée pour les humains. Ici, je commence surtout à penser l’expérience de travail de l’agent : des retours courts, ciblés, lisibles dans le contexte restant. C’est ça que j’appelle AIX. Quand je configure un linter, un message d’erreur ou un script, je pense à l’agent qui va devoir lire ce retour, corriger, relancer. Si le retour est clair, elle repart. S’il est vague ou trop bruyant, elle patine et répète les mêmes erreurs.
Dans la pratique, la boucle n’est pas toujours aussi propre que sur le schéma. Je formule une tâche, l’agent explore, écrit du code, modifie des fichiers, puis les contrôles commencent à répondre : lint, types, tests, hooks, CI. À chaque retour, je veux éviter le mur de logs. Je veux un signal que l’agent peut exploiter pour corriger sans repartir dans le flou.
Dans cette boucle, toutes les vérifications ne jouent pas le même rôle. Certaines doivent être très rapides : un formatage, un lint ciblé, parfois un typecheck limité au fichier ou à la zone modifiée. Celles-là peuvent se déclencher souvent, juste après une écriture. D’autres ressemblent plutôt à de petits pipelines : elles tournent à la fin d’un tour de travail, juste avant que l’agent rende la main. Elles peuvent relancer des checks plus lourds, capturer l’état du diff et des erreurs, ou même demander une revue à un autre agent. Dans ce workflow, le tour ne devrait pas se terminer sur un “j’ai fini” si quelque chose casse encore. L’agent repart dans la boucle.
Attention
Trop de hooks recrée le problème que j’essaie d’éviter. Si chaque action déclenche un long retour, je protège peut-être le cadre, mais je pollue aussi le contexte. Et un contexte pollué finit par dégrader la sortie. Un bon garde-fou doit renvoyer un signal utile, pas remplir la fenêtre de bruit.
Ça ne se limite pas au lint ou aux tests. J’ajoute aussi des validations maison : frontières runtime, migrations, documentation, contexte, environnement, sécurité. Chaque projet a ses angles morts ; les garde-fous servent à les rendre visibles plus tôt.
La liste exacte des outils change d’un projet à l’autre. Le déplacement, lui, reste le même : une règle importante ne reste pas seulement dans un prompt. Quand elle peut être vérifiée, je cherche à la faire vérifier par le système.
Mise à jour (avril 2026)
Depuis, mes boucles de retour ont encore changé. J’utilise maintenant davantage de retours pendant l’écriture elle-même : formatage, lint ciblé, parfois typecheck ou validation de composant dès qu’un fichier change. C’est plus rapide qu’une vérification complète au commit ou en CI, mais ça ne la remplace pas. Les deux niveaux n’ont pas le même rôle.
L’IA génère du code, mais elle ne travaille pas dans le vide. Elle agit dans une pile de contexte : fichiers d’instructions, consignes utilisateur, fichiers chargés pendant la tâche, code existant, commentaires, documentation, hooks et checks. Mon rôle se déplace là : tenir cette pile assez propre pour que l’agent puisse agir sans inventer le cadre.
Les garde-fous ne sont donc pas une couche séparée du contexte. Ils en font partie. Ils transforment une règle, une convention ou une erreur en signal exploitable. Quand cette pile est bien tenue, l’agent peut avancer beaucoup plus loin sans que je sois obligé de reprendre chaque décision à la main.