Dans le cadre du concours AI for Industry Challenge, l'équipe MacCody, composée de deux pères de famille travaillant en parallèle de leurs activités professionnelles, a entrepris de tester une hypothèse contre-intuitive : un contrôleur robotique classique — fondé sur des règles explicites et du code ordinaire — pouvait-il être développé et mis au point assez rapidement, grâce aux agents de code, pour devenir compétitif dans une tâche où la majorité des participants misent sur des politiques apprises par apprentissage automatique ?

Le défi consistait à commander un bras robotique UR5e dans l'environnement de simulation Gazebo, afin d'insérer des connecteurs à fibre optique SFP et SC dans des ports disposés sur un plateau de tâche aléatoire, en exploitant des images de caméra, des capteurs de force/couple et les états articulaires du robot.

Une question différente

L'équipe précise d'emblée qu'il ne s'agit pas d'une histoire à succès, ni d'un procès des agents de code. Leur objectif était de déterminer si un flux de travail associant un humain et un agent de codage pouvait construire, itérer et déboguer un contrôleur classique suffisamment avancé pour être significativement compétitif. « C'était la véritable expérience pour nous », écrivent-ils, ajoutant que ce cas d'usage pourrait aussi servir de bac à sable pour évaluer les agents de code sur des tâches complexes.

Les agents de code ont changé l'économie de l'expérimentation : le coût des tokens et de la génération de code leur a semblé suffisamment bas, en partie grâce à un accès subventionné, pour justifier une exploration large, construire des outils, abandonner des pistes faibles et persévérer. Ils ne cherchaient pas un coup de chance isolé, mais des stratégies explicites qui fonctionnent malgré des changements de graines aléatoires, de poses de plateau, de placements de connecteurs ou de perturbations dans la prise.

Contexte de l'équipe et configuration

L'équipe ne partait pas de zéro : l'un des membres possédait une expérience en ROS/Gazebo et en recherche en robotique, ce qui a réduit les frictions initiales. Cependant, le plus grand gain de productivité ne venait pas de ces connaissances seules, mais de la combinaison d'une expérience adjacente et de l'automatisation par agent de code. « L'agent a rendu moins coûteux de transformer une compréhension partielle en code, outils, wrappers et expériences », expliquent-ils.

Ils ont conservé un flux de travail majoritairement mono-agent avec un humain dans la boucle, jugeant plus précieux de préserver une image mentale partagée de ce que le contrôleur tentait d'accomplir, plutôt que de maximiser le parallélisme autonome. Les approches multi-agents et les schémas d'usine sombre leur semblaient encore trop expérimentaux pour un problème aussi emmêlé.

Leur infrastructure technique était volontairement simple : un serveur loué à l'heure avec un GPU RTX 3090, 10 cœurs CPU et plus de 32 Go de RAM ; l'interface agent de code Pi ; l'outil pi-autoresearch pour des boucles autonomes de benchmark, édition et analyse ; pi-telegram pour les notifications asynchrones et l'envoi d'images ; et un abonnement GitHub Copilot Business pour un accès soutenu au modèle.

Résultats mitigés mais révélateurs

Au début du classement public, l'équipe a brièvement occupé la 6e position avec un score de 47,34. En fin de compétition, leur classement final était la 65e place avec 112,75 points. Leur meilleur score interne enregistré atteignait 151,71, mais ils le considèrent comme un pic plutôt qu'un niveau stable, en raison de la variance réelle de la tâche et des évolutions continues de la politique.

L'équipe insiste sur le fait que ces résultats ne prouvent pas que la commande classique bat les méthodes apprises, ni qu'ils ont résolu le défi — ils n'ont pas terminé dans le top 30. Néanmoins, cela a suffi à modifier leur a priori : ils prennent désormais au sérieux l'idée que les agents de code peuvent accélérer matériellement le travail robotique classique, au point de reconsidérer les contrôleurs explicites dans des contextes où beaucoup opteraient par défaut pour l'apprentissage.

Évolution du contrôleur

Le contrôleur n'est pas une astuce unique, mais s'est transformé au fil du temps en un contrôleur visuotactile classique étagé. Voici les grandes étapes : acquisition visuelle et sélection de cible, pré-alignement au-dessus du plateau, descente surveillée, classification du contact, recherche locale près de l'embouchure du connecteur, insertion conforme, vérification et récupération.

Ce résumé est plus net que le processus réel, qui a vu le contrôleur devenir de plus en plus explicite à mesure que l'équipe se heurtait à une question récurrente : à quoi le système doit-il faire confiance à chaque instant ? À la vision ? Au contact ? Aux logiques de récupération, de retrait ou de tentative ?

La phase précoce a consisté à obtenir une base de travail classique fonctionnelle. L'article détaille que la majorité de l'effort a porté sur la gestion des incertitudes et des cas limites, plutôt que sur l'innovation algorithmique.

Leçons pour la communauté

L'équipe conclut que leur expérience, bien qu'imparfaite, offre un retour utile aux roboticiens et aux personnes travaillant avec les LLM et les agents de code. Elle illustre comment un workflow humain-agent peut repousser les limites de la programmation explicite dans des tâches complexes, tout en soulignant les limites actuelles en matière de fiabilité et de passage à l'échelle. Le défi initial — construire un contrôleur classique compétitif — reste ouvert, mais la voie semble plus praticable qu'imaginé.