Senar : pourquoi les agents AI ne remplacent pas les programmeurs et modifient le processus de développement

Dans la deuxième partie d'une série sur SENAR, l'auteur examine non pas la qualité des modèles, mais le processus de développement lui-même avec les agents IA. L'idée principale est simple : un agent peut écrire du code plus rapidement qu'un humain, mais il ne se comporte pas comme un ingénieur lorsqu'il rencontre une lacune de connaissances.

Où l'agent échoue

Le cas le plus révélateur est un audit d'un ancien système Java avec 17 modules et sans documentation à jour. L'agent a compilé une carte architecturale convaincante : dépendances, interfaces, descriptions de composants et relations entre services. Presque tout semblait précis jusqu'à ce qu'il atteigne une ancienne couche proxy qui subsistait après la migration vers une file d'attente de messages.

Dans le code, cette couche ressemblait à un appel HTTP ordinaire, et l'agent l'a décrite avec assurance comme faisant partie de l'architecture standard, bien que pour les personnes ayant travaillé sur le projet auparavant, ce soit un contournement temporaire et une trace d'une ancienne solution. C'est ici que la différence clé entre un agent et un développeur devient apparente. Une personne typiquement remarque une construction étrange, signale le risque et va clarifier l'historique de la décision auprès de l'équipe ou de l'auteur du code.

Un agent reconstruit plus souvent l'explication manquante lui-même : formule une raison logique, invente un objectif et ne distingue pas les faits du référentiel de sa propre reconstruction. Plus le résultat semble soigné, plus les chances sont élevées de rater une erreur lors de la révision et d'accepter une hypothèse comme vérité architecturale.

«

La différence entre un programmeur et un agent n'est pas la vitesse. »

Cinq conclusions clés

À partir de ce cas, l'auteur en déduit cinq modèles récurrents qui, selon son expérience, apparaissent sur presque n'importe quel projet avec des agents IA pour le développement. Ils ne concernent pas seulement la qualité du code, mais aussi la façon dont l'agent perçoit les tâches, le contexte et les conséquences de ses décisions. Au total, cela explique pourquoi le même outil peut accélérer considérablement le développement sur des tâches simples et créer tout aussi rapidement des problèmes cachés sur des tâches complexes.

• L'agent n'a pas de mémoire du projet : si l'historique des décisions n'est pas explicitement transmis, il n'existe pas pour l'agent.
• Il exécute la tâche littéralement et ne complète pas le contexte commercial comme le ferait un développeur expérimenté.
• Une mauvaise hypothèse se multiplie rapidement à travers une série de fichiers et d'utilitaires similaires.
• L'agent ne voit pas l'architecture au-delà du prompt actuel et choisit le chemin localement pratique.
• Il ne vit pas avec les conséquences de ses décisions, la responsabilité du lancement et des données restant avec les humains.

La conclusion pratique de ces observations est sévère : la tâche doit contenir non seulement des objectifs et des critères d'acceptation, mais aussi des scénarios négatifs, des contraintes, des interdictions et des limites architecturales. Si vous laissez des lacunes, l'agent les remplira. C'est pourquoi la porte d'entrée de qualité chez SENAR exige d'abord de rassembler la spécification et le contexte, puis de lancer la génération. La vitesse n'est utile que lorsque l'espace pour la spéculation est réduit à l'avance par un humain.

Le coût de l'automatisation rapide

Le code rapide d'un agent crée un type différent de dette—cognitive. Un module peut fonctionner, les tests passer, le linter rester silencieux, mais l'équipe ne comprend pas pourquoi il est structuré ainsi et quelles décisions y sont intégrées. L'auteur donne l'exemple d'un module cache d'environ 500 lignes : après quelques semaines, il fallait changer la stratégie de purgation des données obsolètes, et au lieu d'une heure pour la retouche, une demi-journée a été consacrée à la restauration de la logique que personne n'avait explicitement acceptée ou enregistrée.

Pour éviter de masquer les défaillances du système par des corrections manuelles, l'auteur propose de calculer MIR—la proportion de tâches pour lesquelles des éditions manuelles du code ont été nécessaires après le travail de l'agent. Sur les projets matures, cette métrique s'est maintenue autour de 5–15 %, au démarrage d'un nouveau—environ 20 %. L'enjeu n'est pas un joli rapport, mais un retour d'information : si les corrections manuelles se répètent, le problème ne se situe pas dans un fichier mais dans le contexte, la spécification, les limites architecturales ou le modèle choisi.

Le nouveau rôle de l'ingénieur

Cela change le rôle des humains dans l'équipe. Selon l'auteur, jusqu'à 60 % du temps va maintenant à la spécification des tâches, à la collecte de contexte et aux décisions architecturales, environ 30 % à la vérification des résultats et encore 10 % à l'ajustement des outils, des métriques et du processus lui-même. L'écriture de code cesse d'être le centre du travail : les ingénieurs ressemblent de plus en plus à ceux qui définissent les tolérances, décomposent les systèmes complexes et vérifient que le résultat soigné de l'agent ne s'est pas transformé en une erreur coûteuse.

Une conclusion séparée semble sévère : tout ce qui n'est pas écrit n'existe pas pour l'agent. Si les limites des modules, les conventions d'API, les raisons des décisions passées et les dépendances interdites vivent uniquement dans la tête d'un tech lead, l'agent les violera presque certainement, car techniquement l'importation peut fonctionner et les tests peuvent passer. C'est pourquoi la documentation dans le modèle SENAR est nécessaire non pour la conformité, mais comme une interface de travail entre les humains, les agents et les futurs développeurs qui devront maintenir ce code.

Ce que cela signifie

Pour les équipes qui adoptent sérieusement les agents IA dans le développement, la grande nouvelle n'est pas qu'ils accélèrent le développement. Ce qui importe bien davantage, c'est ceci : sans spécification stricte, enregistrement des décisions et vérification constante, la vitesse se transforme rapidement en dette cognitive, et l'ingénieur passe d'auteur de code à éditeur, architecte et contrôleur de qualité.