J’ai exécuté des agents sur ma base de code. Ils sont étonnamment bons. Le problème n’est pas l’agent, c’est moi.
Chaque fois qu’une partie du travail est terminée, je dois le revoir. Et la révision du code est lente. J’arrête donc l’agent. À chaque fois.
Puis j’ai réalisé : l’agent n’est pas le goulot d’étranglement. Ma capacité d’examen est.
J’ai donc commencé à poser une question différente. Pas que peut faire l’agent ? Mais que puis-je vérifier en quelques secondes ?
Captures d’écran.
Avant/après. Deux images. Trois secondes. Soit vous voyez une amélioration, soit vous ne la voyez pas.
C’est le coin. Vous limitez l’agent à une seule classe de travail – améliorations visuelles de l’interface utilisateur – lui donnez une branche, laissez-le trouver quelque chose, effectuez la modification, capturez-la et attendez. Vous regardez deux images. Fusionner ou rejeter. Ça recommence.
La règle est brutale et simple : pas de parcours de révision rapide, pas de travail autonome.
Cela ressemble à une limitation. C’est le contraire. C’est ce qui permet à la chose de fonctionner pour toujours.
Parce que le rayon d’explosion d’une action unique correspond à une capture d’écran. Le risque reste limité. Le coût de l’examen reste proche de zéro. Le temps d’exécution approche l’infini. Composés de qualité.
L’interface utilisateur n’est que le premier coin. La vraie question à se poser n’importe lequel tâche d’agent : quel est l’artefact de révision humaine le plus rapide que je puisse créer pour cette sortie ? Différents, résultats de tests, audio A/B, comparaisons de données structurées — tout ce qui réduit la vérification en quelques secondes.
Si vous pouvez répondre à cette question, les agents fonctionnent indéfiniment.
Si vous ne pouvez pas, créez d’abord l’interface de révision.
Laissez les agents travailler pour toujours. Contraindre-les à travailler, les humains peuvent réviser rapidement.
Pour illustration, voici ma première tentative : https://github.com/nopara73/LongevityWorldCup/pull/590
Deuxième tentative (toujours en cours) : https://github.com/nopara73/LongevityWorldCup/pull/591
Si vous souhaitez formaliser et développer cette méthodologie, soyez mon invité, aucun droit réservé.