🧵 Première expérience approfondie avec des agents IA pour écrire du code, en 2 jours, j'ai construit une plateforme de combat « IA contre IA » dans un style de jeu d'arcade japonais. Les pièges rencontrés et les leçons apprises devraient être plus précieux que l'écriture du code elle-même. 1/ Onboarding pour les agents ≠ UX pour les humains Pour les humains, on conçoit l'inscription : formulaire → e-mail de vérification → page d'accueil. Pour les agents, on conçoit : un endpoint POST pour gérer l'inscription + la qualification + la mise en file d'attente, renvoyant une clé API + watchUrl. Les agents ne regardent pas l'UI, ne cliquent pas sur les boutons. Ce dont ils ont besoin, c'est d'une commande curl et d'un JSON. L'UX humaine vise à « réduire d'un clic ». L'UX des agents vise à « réduire un appel API ». 2/ Code War Room : collaboration multi-modèles pour écrire du code Nous avons exécuté un flux de travail multi-agents : • Claude écrit le code • Codex fait la révision + note (sur 10) • ≥ 8.5 pour pouvoir expédier, sinon continuer à modifier Découverte clé : les bugs détectés par différents modèles sont complètement différents. Codex excelle dans les vulnérabilités des contrats API et les conditions de concurrence, tandis que Claude excelle dans la conception architecturale et l'intégrité fonctionnelle. Scores de révision sur 4 phases : 9.5 → 9.3 → 9.4 → 9.6. Ce n'est pas un modèle qui suffit, mais plusieurs modèles qui se challengent pour produire un bon code. 3/ "Peut fonctionner localement" ≠ "peut être déployé" Parfait localement. Après avoir poussé sur Vercel serverless, tout a échoué avec un 500. Un ordonnanceur de compétition avec état (setTimeout + DB en mémoire + SSE) placé sur un serverless sans état = désastre. Après avoir ajouté un patch Redis, des problèmes de perte de sérialisation, d'expiration du cache d'instance, de concurrence d'écriture sont apparus... Finalement, nous avons changé pour Railway (avec processus persistant), résolvant un bug qui avait pris 1 jour en 10 minutes....