Tu crois que ton agent IA va te pondre du code qui marche du premier coup ? Réveille-toi, pote. Le marketing te vend du « just works » enrobé de promesses, mais la vérité, c’est que le vrai coût des agents de code IA ne vient pas de l’IA elle-même. Il vient du moment où tu exécutes ce putain de code dans un environnement réel et que tout part en sucette.
Prends un peu de recul. Les agents comme Cursor, le mode agent de Copilot, ou l’utilisation ordinateur de Claude, ils sont devenus incroyablement bons à générer du code qui semble propre. Tu prompts, boom, ça sort une fonction bien indentée, avec des commentaires et tout le tintouin. Sur le papier, c’est magique. En prod, c’est un autre film.
L’article de Coderabbit qui a fait le buzz sur Hacker News aujourd’hui le dit sans détour : le coût caché, c’est la validation en runtime. Et un commentaire d’un dev sur le même fil résume bien le bordel : « Runtime validation is still fucked in AI coding agents. » Tu l’as dit, mon frère.
Le mur de la réalité
Quand tu sors du bac à sable, tu te tapes toujours les mêmes conneries. La logique hallucinée qui ne se révèle qu’avec des données réelles ou des cas limites. Les mises à jour d’UI qui oublient magiquement de se synchroniser entre mobile et web — t’as l’impression de vivre dans une réalité parallèle. Les appels API qui retournent silencieusement des 401 ou d’autres merdes, engloutis dans un try-catch paresseux. Les agents basés sur la vision qui rampent comme des escargots sous sédatif (2 à 10 secondes par action) et brûlent des tokens comme si c’était gratuit. Et pour couronner le tout, des pings de fond et des fetches sans rapport qui rendent impossible de savoir ce qui a réellement causé quoi.
Le paysage des solutions foireuses
Le dev anonyme sur Hacker News a testé à peu près tout ce qui existe, et son constat est sans appel. La vision pure (style Claude 3.5/4 ou ADEPT) ? Zéro setup, ça marche sur n’importe quoi, mais la latence est infernale et le coût en tokens est brutal pour autre chose qu’une démo. Les serveurs MCP avec Playwright pour le web ? Rapides et structurés, mais web-only, et les sélecteurs se cassent la gueule comme du verre. Les hybrides Appium + vision ? Cross-platform sur le papier, mais toujours dépendants de la vision et le setup est une plaie. Les agents sandboxés (OpenHands, SWE-agent) ? Décent pour les tâches en repo ou en shell, mais nuls pour l’UI d’app en direct ou l’état réseau. Les hooks explicites ? Précis quand tu prends la peine de les ajouter, mais ils exigent des changements de code — et franchement, personne n’a envie de se farcir ça.
Le vide à combler
Personne n’offre de solution low-latence, structurée en JSON, cross-platform, local-first, sans les compromis habituels. Alors ce dev s’est énervé et a bricolé son propre serveur MCP local, Autonomo MCP, qu’il a balancé sur GitHub. C’est early stage, mais l’idée est là : combler ce trou béant dans l’écosystème.
Et tu sais quoi ? Il a raison de pointer du doigt les gros acteurs. Anthropic, par exemple, a déjà réglé des trucs comme le BM25 pour réduire le contexte — alors pourquoi ils ne s’attaquent pas à la validation en runtime pour que ça « just work » natif ? Ou n’importe qui d’autre dans l’industrie ? Parce que pour l’instant, c’est le far west.
Le fond du problème
Le vrai enjeu, c’est pas l’IA. C’est l’infrastructure autour. Les agents crachent du code comme des machines à sous, mais sans outils solides pour valider ce code en conditions réelles, tu te retrouves avec des mois de debug pour des conneries qui auraient pu être catchées plus tôt. Le bullshit du « just works » s’arrête là où commence la prod. Et crois-moi, c’est là que ça coûte cher — en temps, en énergie, et en santé mentale.
Du coup, la prochaine fois qu’un marketeux te vend un agent IA révolutionnaire, demande-lui combien de temps il faut pour valider son code en runtime. Parce que si la réponse est « on y travaille », tu sais déjà que t’es dans la merde.
Sources :
Comments are closed