Un agent a tourné en boucle pendant 40 heures : comment intégrer l'IA au développement sans régressions

Les débats sur l'utilité des développeurs à l'ère du vibe coding se résument généralement à des émotions. L'auteur de cette analyse publiée sur Habr montre plutôt ce qui se passe en pratique lorsqu'on confie une tâche à un agent sans lui fixer de cadre.

Là où le vibe coding déraille

Dans le projet personnel Xenodrift, remanié à plusieurs reprises, les décisions antérieures cessaient d'être respectées à chaque nouvelle modification. Des régressions apparaissaient, et certaines fonctionnalités disparaissaient tout simplement. La cause est banale : les exigences n'étaient consignées nulle part, et il n'existait aucun moyen de vérifier leur respect. À chaque fois, l'agent travaillait avec le fragment de contexte courant et ne se souvenait pas de ce qui avait été convenu auparavant.

Mais une mauvaise qualité de code n'est pas inévitable. Dans la démo de l'application bancaire DemoBank, l'auteur a fixé des exigences de performance, de réutilisation des fonctionnalités et de design system, tout en s'abstenant volontairement de dicter l'architecture. Le résultat : une structure modulaire feature-first inspirée de la Clean Architecture, BLoC/Cubit pour la gestion d'état, ainsi que l'idempotence et des retry dans la couche réseau. La fonctionnalité de paiement des amendes fonctionne aussi bien à l'intérieur de l'application que de manière autonome, sans traîner de dépendances inutiles.

La performance a été testée sur un véritable smartphone d'entrée de gamme, le realme RMX3760 : lors d'un défilement d'une minute de 12 000 opérations, la part des images dépassant le budget de 16,7 ms s'est élevée à 0,25 %, pour un critère de moins de 1 %. L'auteur précise honnêtement qu'il s'agit d'un seul appareil et d'un seul scénario.

Vitesse n'est pas synonyme de maturité

DemoBank a demandé environ 27 heures de travail cumulé de Codex et environ 19 heures de temps réel, parallélisme compris, auxquelles s'ajoutent 2 à 3 heures de l'auteur lui-même. Les exécutions des tests de performance sur le téléphone se sont révélées particulièrement coûteuses. Pour une équipe, la métrique ne devrait pas être « en combien de temps a-t-on généré le code », mais « combien de temps entre la définition de la tâche et la modification acceptée », revues et retouches comprises.

Harness, quality gate et responsabilité

Par AI Harness, l'auteur entend l'environnement de travail de l'agent : contexte du projet, outils, limites d'action, vérifications automatiques et procédure de remise du résultat à un humain. Les idées clés :

• Les vérifications dont dépend la recette doivent se lancer automatiquement et bloquer la fusion. La consigne « lance les tests » dans le prompt ne le garantit pas.
• La boucle « continue jusqu'à ce que les vérifications passent » doit être bornée. L'un des projets de l'auteur a tourné 40 heures, jusqu'à ce qu'il l'arrête manuellement. Il faut des limites de temps et d'argent, et en cas d'erreur répétée sans progrès, l'agent doit s'arrêter et rendre compte de ce qu'il a essayé.
• Après un arrêt forcé, il faut réparer le processus, pas seulement corriger le code : l'agent a peut-être mal compris la tâche, la carte du projet est peut-être obsolète ou le modèle trop faible.
• Chaque décision doit avoir un responsable identifié : le comportement est validé par le product manager et l'analyste, les contrats d'un module sont vérifiés par son propriétaire, et l'interprétation de la tâche par l'agent est examinée par le développeur avant l'écriture du code.

Contexte, contrats et domaines

Une grande fenêtre de contexte ne garantit pas que l'information soit bien exploitée : l'étude Lost in the Middle a montré que la qualité dépend de la position des données dans le contexte. Il faut donc une carte des modules, des contrats à jour et des ADR. L'auteur propose de conserver le contrat d'API dans une source unique, par exemple TypeSpec, et d'en générer OpenAPI, la documentation et le code client, en vérifiant la cohérence dans la CI. Les ADR obsolètes doivent être marqués comme superseded.

Mais un contrat ne remplace pas les tests comportementaux : une clé d'idempotence peut être décrite dans le schéma, alors que l'absence de double remboursement ne se vérifie que par un scénario dédié. Exemple tiré du e-commerce : avec une mauvaise carte du projet, l'agent peut appeler l'API du prestataire de paiement directement depuis le module de commandes, et les remboursements n'apparaîtront pas dans le journal des paiements. Le DDD et des règles d'architecture vérifiées automatiquement sont ici utiles, de même qu'une revue par un autre modèle.

Que faire

Limites : il s'agit de l'expérience d'un seul auteur sur de petits projets, sans audit de code indépendant. Mais les conclusions sont transposables. Consignez les exigences dans des spécifications (OpenSpec, Spec Kit, BMAD, Kiro), rendez le quality gate obligatoire, fixez des budgets pour les boucles d'agent et attribuez des responsables au contexte. Le rôle du développeur passe de la saisie de code à la définition du cadre et à la recette du résultat.