Le modèle n’est plus la partie la plus intéressante d’une configuration d’agent de codage.
Cela semble faux si vous regardez uniquement des démos. La démo concerne toujours le modèle. Il lit le problème, écrit le code, explique la différence et exécute peut-être même les tests. Enregistrement d'écran propre. Belle fin. Tout le monde applaudit.
Les vrais projets sont plus compliqués. Le plus difficile n’est pas de faire en sorte qu’un agent produise du code une seule fois. Le plus difficile est de rendre ce travail reproductible, inspectable, récupérable et suffisamment ennuyeux pour qu'une équipe puisse lui faire confiance un mardi lorsque personne n'a de patience pour un autre flux de travail magique.
C’est pourquoi l’enveloppe autour de l’agent commence à avoir plus d’importance que l’agent lui-même.
La première vague d’adoption d’agents de codage a entraîné les gens à réfléchir par invites. Posez de meilleures questions. Collez un meilleur contexte. Gardez le fil vivant. Rappelez au modèle ce qui compte.
Cela fonctionne pour un travail ponctuel. Il s'effondre au moment où l'œuvre devient une boucle.
Une véritable boucle de développement a un état. Il a des contraintes. Il a un examen. Il a des modes de défaillance. Il a des autorisations. Il y a des transferts difficiles entre les trackers de problèmes, les dépôts, les exécuteurs de tests, les portes de déploiement et les humains déjà surchargés.
Les discussions récentes de DEV.to autour de l'orchestration des agents et de la révision de l'IA à la validation vont dans cette direction. La conversation s'éloigne de « le modèle peut-il écrire du code ? » et vers "quel chemin l'œuvre parcourt-elle avant que quiconque lui fasse confiance ?"
C'est la bonne question.
Si la seule interface est...
[Courte citation de 8% de l'article original]