Claude AI dans Quatre IDEs : Pourquoi le Développeur est Devenu le Principal Goulot d'Étranglement pour les Agents

Sur Habr AI a été publié un article sur la façon dont les assistants d'IA accélèrent simultanément le développement et créent un nouveau type de surcharge. Quand on travaille sur plusieurs projets en même temps, la principale limitation n'est plus Claude AI ni la qualité de la génération de code, mais l'attention du développeur lui-même.

Le Goulot d'Étranglement est l'Humain

L'auteur décrit une scène presque quotidienne : quatre IDE ouverts, chacun exécutant une ou plusieurs sessions avec Claude AI, et vous devez constamment basculer entre eux manuellement. Quelque part, vous devez planifier l'étape suivante, ailleurs vous devez vérifier rapidement un fragment critique, ailleurs vous devez concevoir un test pour ne pas avoir à lire le code ligne par ligne. En théorie, les agents devraient travailler pendant qu'une personne se repose. En pratique, tout s'arrête au moment exact où l'opérateur a besoin de manger, de dormir ou de simplement quitter la pièce.

« Ce n'est pas le modèle avec ses défauts, c'est moi ».

C'est une observation importante pour toute la vague du développement piloté par l'IA. Même si un modèle écrit plus vite qu'un humain, c'est toujours l'humain qui reste le gestionnaire de contexte : gardant en tête l'état des projets, décidant où une révision est nécessaire et où les vérifications d'entrée et sortie suffisent, et basculant constamment entre les tâches. De ce fait, l'automatisation promise se transforme non pas en un autopilote tranquille, mais en une forme plus intense et stressante de gestion de plusieurs processus semi-autonomes.

Tests au Lieu de Révision

À partir de l'article, il est clair que l'auteur remplace de plus en plus la révision de code traditionnelle par des tests basés sur des scénarios. La logique est simple : si une tâche ne comporte pas de risque financier direct, il est plus rapide de ne pas creuser dans chaque module, mais de vérifier le système comme une boîte noire. Dans l'exemple du contrat intelligent sur EVM, l'agent a reçu un ensemble de contraintes d'ingénierie—nonce hors ligne, rejet des demandes RPC inutiles, gasLimit constant, round robin entre les adresses—et ensuite, au lieu de lire le code, ils ont commencé à attaquer la solution avec des questions et des exécutions de test.

• Révision parallèle à partir du contexte actuel et propre
• Vérification de ce qui se passe lorsque les sources de prix sont interrompues
• Contrôle de la logique gasPrice et risque de brûler les dépôts en frais
• Mesure de la latence du traitement des ticks et de l'envoi asynchrone
• Exécution à blanc avec des mocks plutôt que des transactions réelles

Cette approche permet d'identifier rapidement les points faibles sans immersion profonde dans l'implémentation. Selon l'auteur, pas à pas autour du bot principal, il a fallu construire des services de fond pour le contrôle du solde, la confirmation des transactions et la gestion du nonce. Le résultat s'est avéré fonctionnel, bien que la vérification principale se soit faite non par la lecture du code source, mais par la simulation séquentielle d'échecs et de scénarios problématiques connus. Cela fait basculer le rôle du développeur d'écrivain de code à opérateur de qualité et de risques.

Expert, Pas Passager

Mais le schéma ne fonctionne que là où l'humain comprend lui-même comment la solution doit être structurée. Tant que le développeur est plus fort que le modèle dans son domaine, il peut le guider avec de brefs conseils d'expert, établir les bonnes vérifications et repérer rapidement les lacunes dangereuses. Dès que l'équipe arrive à une section où l'opérateur n'a pas de réponse sûre, surgit l'illusion que l'agent va maintenant mener sa propre recherche et choisir le meilleur chemin. C'est ici, selon l'observation de l'auteur, que la magie s'arrête brutalement.

D'où la conclusion principale du texte : le développeur de l'avenir n'est pas simplement une personne qui sait comment ouvrir un chat avec un modèle, mais un opérateur-expert d'IA avec une réflexion presque au niveau senior. Il doit gérer plusieurs projets en parallèle, prendre des décisions architecturales, assumer la responsabilité des résultats et gérer les files d'attente des tâches pour les agents. L'auteur voit l'étape suivante dans l'orchestration non seulement des modèles eux-mêmes, mais des opérateurs : un espace de contexte partagé où vous pouvez reprendre les tâches bloquées, voir l'historique des décisions et transférer le contrôle sans perdre la vue d'ensemble.

Ce Que Cela Signifie

Les outils d'IA augmentent déjà le débit du développeur, mais ils n'éliminent pas le besoin d'expérience, de concentration et de responsabilité. Le prochain déficit dans l'industrie n'est pas l'accès à un autre modèle, mais les moyens de gérer plusieurs agents sans changement constant de contexte manuel et épuisement.