Claude AI dans quatre IDE : pourquoi le développeur est devenu le principal goulot d'étranglement des agents

Un texte publié sur Habr AI explique comment les assistants d'IA accélèrent le développement tout en créant un nouveau type de surcharge. Quand plusieurs projets avancent en parallèle, la principale limite n'est plus Claude AI ni la qualité du code généré, mais l'attention du développeur lui-même.

Le goulot d'étranglement, c'est l'humain

L'auteur décrit une scène presque banale : quatre IDE ouverts, chacun avec une ou plusieurs sessions de Claude AI, et il doit sauter de l'un à l'autre à la main. Ici, il faut planifier l'étape suivante ; là, vérifier vite un fragment critique ; ailleurs, imaginer un test pour ne pas lire le code ligne par ligne. En théorie, les agents devraient travailler pendant que l'humain se repose. En pratique, tout s'arrête précisément quand l'opérateur doit manger, dormir ou simplement quitter la pièce.

« Ce n'est pas le modèle et ses bévues, c'est moi. »

C'est une observation importante pour toute la vague du développement assisté par IA. Même si le modèle écrit plus vite qu'une personne, c'est l'humain qui reste le répartiteur de contexte : il garde en tête l'état des projets, décide où une revue est nécessaire et où il suffit de vérifier les entrées et les sorties, et passe sans cesse d'une tâche à l'autre. Résultat : l'automatisation promise ne devient pas un pilote automatique serein, mais une façon plus dense et plus nerveuse de piloter plusieurs processus semi-autonomes.

Des tests plutôt que la revue

L'article montre que l'auteur remplace de plus en plus la revue de code classique par des tests par scénarios. La logique est simple : si la tâche ne comporte pas de risque direct de perte financière, il est plus rapide de ne pas fouiller chaque module et de tester le système comme une boîte noire. Dans l'exemple d'un contrat intelligent sur l'EVM, l'agent a reçu un ensemble de contraintes d'ingénierie (nonce hors ligne, refus des requêtes RPC superflues, gasLimit constant, round robin sur les adresses), puis, au lieu de lire le code, l'auteur a attaqué la solution par des questions et des exécutions.

• Revue parallèle à partir du contexte actuel et d'un contexte vierge
• Vérification de ce qui se passe si les sources de prix tombent
• Contrôle de la logique de gasPrice et du risque de brûler le dépôt en frais
• Mesure de la latence de traitement des ticks et de l'envoi asynchrone
• Dry run avec des mocks plutôt que de vraies transactions

Cette approche permet de repérer vite les points faibles sans plonger dans l'implémentation. Selon l'auteur, il a fallu, pas à pas, ajouter autour du bot principal des services en arrière-plan pour surveiller le solde, les confirmations de transactions et le nonce. Le résultat fonctionne, même si la vérification principale n'est pas passée par la lecture du code source, mais par la simulation méthodique de pannes et de scénarios problématiques connus. Cela fait glisser le rôle du développeur d'auteur de code à opérateur de qualité et de risques.

Un expert, pas un passager

Mais ce schéma ne marche que si la personne comprend comment la solution doit être conçue. Tant que le développeur est plus compétent que le modèle dans le domaine, il peut le guider par de courts conseils d'expert, poser les bonnes vérifications et repérer vite les lacunes dangereuses. Dès que l'équipe atteint un point où l'opérateur n'a pas de réponse sûre, l'illusion s'installe que l'agent va mener lui-même l'enquête et choisir le meilleur chemin. C'est précisément là, d'après l'auteur, que la magie s'arrête net.

D'où la conclusion principale du texte : le développeur de demain n'est pas simplement quelqu'un qui sait ouvrir un chat avec un modèle, mais un expert opérateur d'IA au raisonnement quasi senior. Il doit mener plusieurs projets en parallèle, prendre des décisions d'architecture, répondre du résultat et démêler les files de tâches des agents. L'auteur voit la prochaine étape dans l'orchestration non seulement des modèles, mais aussi des opérateurs : un espace de contexte partagé où l'on peut reprendre des tâches bloquées, consulter l'historique des décisions et transmettre la main sans perdre la vue d'ensemble.

Ce que cela signifie

Les outils d'IA augmentent déjà le débit des développeurs, mais n'éliminent pas le besoin d'expérience, de concentration et de responsabilité. La pénurie la plus immédiate dans l'industrie n'est pas l'accès à un modèle de plus, mais les moyens de piloter de nombreux agents sans changement de contexte manuel permanent ni épuisement.