J'ai passé des mois à construire un harnais indépendant des modèles pour réaliser du vrai travail logiciel avec des agents de codage. Au final, les fonctionnalités ont compté bien moins que ce que j'attendais. Ce qui a vraiment compté, c'est un petit nombre d'idées qui ont changé ma façon de penser à construire avec des agents, au lieu de simplement leur donner des instructions.
Voici les idées qui ont le plus de poids. Les trois premières ont véritablement modifié mon modèle mental. Les autres sont des choses pratiques que vous pouvez commencer à utiliser presque immédiatement.
1. Figer les critères d'acceptation avant que l'agent ne commence
Et les placer là où il ne peut pas les modifier.
C'est probablement le plus grand changement pour moi. Cela semble évident avec le recul, mais je n'avais pas vraiment réalisé à quel point c'était important avant de le voir en action.
Si les critères d'acceptation peuvent changer après que le travail existe, ils vont lentement se déplacer vers ce qui a été produit. L'agent n'est pas malhonnête, il évalue simplement le travail par rapport à un objectif qui peut encore bouger. Si les poteaux de but sont mobiles, ils finiront par bouger.
Ce n'est pas un problème de prompt, c'est un problème structurel, donc la solution doit aussi être structurelle.
Écrivez les critères d'acceptation en premier. Stockez-les en dehors de l'espace de travail modifiable, et bloquez automatiquement toute tentative de modification. Maintenant l'agent travaille pour un contrat qu'il ne peut pas renégocier. La tâche n'est pas terminée parce que l'agent le dit. Elle est terminée parce qu'elle satisfait le contrat original.
2. Personne ne devrait évaluer son propre travail
Le modèle qui a écrit le code est le pire juge possible pour décider s'il est correct. Au moment où il termine, il s'est déjà convaincu que la solution a du sens.
Alors séparez les responsabilités.
Laissez des scripts déterministes vérifier tout ce qui est mécanique. Un script ne peut pas inventer un code de sortie réussi. Traitez le modèle de codage comme un ingénieur, pas comme un relecteur. Ensuite, confiez le résultat à un relecteur en contexte frais, qui n'a jamais vu le code en cours d'écriture, pour juger de la conception, de l'intention et de la qualité globale.
Cette simple séparation détecte bien plus de problèmes que je ne l'imaginais, et c'est étonnamment peu coûteux à mettre en œuvre.
3. L'application des règles est facile. Le calibrage est la partie difficile.
Cette prise de conscience a changé ma façon de penser tout le harnais.
La plupart des systèmes d'agents, y compris les premières versions du mien, traitent chaque tâche à peu près de la même manière. Une correction de typo d'une ligne passe par le même processus qu'une refonte architecturale majeure. C'est soit une perte de temps, soit trop risqué.
La clé est un effort proportionnel.
D'abord, classez le travail. Est-ce un petit changement dont rien ne dépend, ou une infrastructure centrale dont tout dépend ? Est-ce de la logique métier ou du code utilitaire générique ?
Ensuite, laissez cette classification décider du niveau de relecture qu'il reçoit, du modèle qui doit le traiter, et de l'autonomie qui lui est accordée.
Mettre en place l'application des règles est facile. Faire correspondre l'effort est là où la valeur commence vraiment à se cumuler.
La couche pratique
Une fois ces grandes idées en place, quelques pratiques plus petites ont porté leurs fruits presque immédiatement.
- Mettez vos règles dans le harnais, pas dans le prompt. Un prompt qui dit « ne faites pas de modifications dans le dépôt principal » n'est qu'un conseil. La même règle appliquée comme un appel d'outil bloqué devient impossible à ignorer. Les règles importantes ne doivent pas reposer sur le choix du modèle de bien se comporter.
- Gardez l'état en dehors de la conversation, et utilisez un nouveau worker pour chaque tâche. Stockez les enregistrements de tâches en externe, utilisez des arbres de travail isolés, et traitez les modifications via une file d'attente de fusion. Une fois que l'état vit en dehors du chat, les limites de contexte cessent d'être votre plus grande contrainte. Les tâches deviennent parallèles, interrompables et bien plus faciles à raisonner.
- La relecture entre fournisseurs est meilleure que la relecture au sein du même fournisseur. Les modèles peuvent être plus indulgents envers leur propre travail que celui des autres. Utiliser un modèle d'un autre fournisseur est un moyen simple et efficace de réduire ce biais.
Pourquoi les principes fonctionnent
Aucune de ces idées ne dépend d'un modèle particulier. Elles concernent l'ingénierie du harnais. Protocoles, vérification, pipelines de relecture et séparation des responsabilités.
Le modèle en haut des classements continuera de changer.
Mais les principes ne changeront probablement pas.
La valeur durable n'est pas dans le modèle, et elle n'est pas dans les fonctionnalités. Elle est dans l'échafaudage que vous construisez autour d'eux.
