Je passe pas mal de temps à essayer de cerner plus précisément quelles composantes sont réellement utiles dans les harness et process agentiques. Et il est parfois difficile de trouver les critères et la méthodologie qui vont déterminer si une variation est déterminante, neutre ou négative - à commencer par l’isolation de cette variation.
MCP or not MCP 🤔
Récemment je me suis par exemple demandé ce qu’apportaient les MCPs iOS basiques (XcodeBuildMCP et mcpbridge) avec des modèles récents (Sonnet 5 en l’occurrence). Je pensais partir pour des bancs de test de plus en plus fins, et un résultat nuancé… Mais ce fut vite bouclé : j’ai testé déjà avec et sans XcodeBuildMCP et je n’ai pas réussi à durcir suffisamment mes tâches pour faire échouer l’agent de manière significative - même nu. Pire, j’ai eu +74% de coût avec le MCP. Conclusion : on n’en est plus là.
Restent peut-être des différences fines qui peuvent avoir leur importance à l’échelle (tokens, vitesse) mais peu significatives pour l’objectif net. Next ! 💅
Giving eyes to the agent 👀
Ensuite je me suis attardé sur un post-mortem intriguant : je voulais reproduire l’animation 3D des stories Instagram et je me suis retrouvé avec une animation “porte de saloon”.
J’étais presque certain de mon hypothèse : l’échec venait du fait que l’agent n’avait pas effectué de vérification visuelle de l’implémentation. J’aurais dû mettre cette capacité et ce critère dans la boucle et tout se serait probablement bien passé !
Je suis donc parti dans une démarche de reproduction du scénario, avec des exécutions échelonnées. Quatre départs identiques par ailleurs : même app de test, même tâche, même modèle, et le même juge final qui attend en embuscade. Seul l’échafaudage de vérification change.
- À nu : la spec chiffrée de l’animation, amputée de ses tolérances et de ses sections de vérification. Pas d’outil, pas de consigne.
- Outillé, sans consigne : la spec complète (méthode de vérification comprise) et un hook de debug qui pose la transition à n’importe quelle position (le doigt qui scrubbe mécanisé). Mais aucune incitation à s’en servir.
- Incité, libre : le même environnement, plus une consigne de vérifier son travail « par les moyens que tu juges suffisants ».
- Boucle imposée : tout ça, plus l’oracle : un vérificateur indépendant qui mesure chaque frame contre la spec, à faire passer avant de livrer.
Mais ce fut vite bouclé 😅 : aucune erreur, toutes les animations sont nickel !
🗑️ in, 🗑️ out
S’ensuivit alors le vrai post-mortem, celui qui ne présume pas de la cause : comment mon implémentation initiale a-t-elle drifté, quelles sont les différences avec ces tests ? Je vous le donne en mille : les specs.
J’ai en effet délégué à un très haut niveau en spécifiant quelque chose comme : “la même animation cube 3D qu’Instagram”, et pire, en refusant de préciser. Non pas que j’avais une confiance aveugle, mais je voulais éprouver une forte autonomie de l’agent, et j’estimais qu’il s’en sortirait probablement.
Là, tout s’enchaîne très logiquement : l’agent fait quelques recherches sur les animations 3D SwiftUI, tombe sur la doc Apple et focus sur un snippet, ça va être sa baseline. Il me délègue alors la vérification visuelle. Je réponds que ça ne matche pas l’anim attendue, mais l’agent me retoque “le code est correct” 🥸 Ensuite, de mémoire : j’ai jeté mon Macbook par la fenêtre et suis allé sautiller dans la forêt. 🧚
Lors de mes tests, à l’inverse, j’ai eu en amont une conversation de 10-15 minutes avec l’agent et j’ai répondu à toutes ses demandes : des screenshots, des vidéos avec la transition automatique ainsi que celle drivée par une gesture, la relation entre la position de la vue et mon doigt lors de la gesture…
Et l’agent a finement analysé tout ça. ffmpeg n’était pas installé sur ma machine, alors il a improvisé un script AVAssetImageGenerator pour extraire les frames des vidéos, et il en a reconstruit le modèle complet : géométrie du cube, équations des arêtes, correspondance entre la position du doigt et l’angle de rotation. Le tout committé dans une spec, gelée avant le premier run. On partait donc de specs rock solid 🪨 - aucune place à l’échec 🧐
Conclusions
Tout cela confirme une tendance très intuitive : les modèles frontière sont extrêmement performants, et l’outillage qui vient compenser leurs défauts devient inutile à mesure qu’ils progressent.
Un très bon exemple est le chain-of-thought. Avant, on orchestrait le raisonnement depuis l’extérieur : un appel pour dérouler les étapes, un second pour extraire la conclusion, et des variantes entières qui échantillonnaient plusieurs chaînes ou exploraient des arbres d’étapes. Toute cette machinerie s’est dissoute dans les modèles de raisonnement, qui la déroulent désormais en interne.
Une partie du harness d’aujourd’hui est le modèle de demain. 🕊️
Mais tout ne se dissout pas. 🧪
Avec un agent solide et un modèle frontière, un problème bien posé passe. La réussite n’est plus le sujet. Le verdict, si.
Car même dans mes runs réussis, la vérification improvisée n’offrait aucune garantie stable. Selon l’outillage disponible, elle allait de mesures au pixel près jusqu’au simple « ça a l’air bon » devant un enregistrement. Le résultat était le même à chaque fois, la preuve non.
Voilà où le harness reste déterminant, et le restera à mon avis longtemps.
- Le ciblage. Des garde-fous sur les specs. Forcer les références, co-construire, chiffrer, geler avant d’implémenter. Quand c’est l’agent qui invente ses critères de succès, ça part mal, et aucun modèle ne rattrapera une cible fausse.
- La non-régression. L’oracle ne se jette pas après la livraison. La porte de saloon qu’un futur refactor réintroduira ne passera pas, elle.
- La garantie du verdict. Toute la différence entre « vérifié » et « regardé ».
Restent les limites de l’exercice : une tâche, un modèle, un run par variante, une toy app, une génération de modèles antérieure pour l’échec d’origine (Opus 4.8, Sonnet 4.6). Limite assumée, pas une cause.
La démo complète est publique (fixture, spec, harness, les quatre livraisons) : github.com/PittsCraft/ios-agent-visual-loop