Un article sur Habr décrit un framework d'IA qui guide Claude avec Clean Architecture et un cycle TDD

Habr a publié une analyse détaillée d'un framework d'IA qui force un LLM à écrire du code selon un processus d'ingénierie strict, et non en « vibe coding » libre. L'auteur affirme faire désormais passer presque tout son développement par cette approche, qui s'appuie sur Clean Architecture, le TDD et une relecture humaine obligatoire.

Comment fonctionne le flux

L'approche repose sur une idée simple : un bon logiciel n'est pas un ensemble de fichiers, mais un ensemble de scénarios de comportement validés. Le travail ne commence donc pas par la génération de code, mais par le découpage du produit en histoires indépendantes, chacune apportant une valeur utilisateur distincte.

Pour chaque histoire, Claude passe d'abord par une étape de spécification : il mène un entretien, rédige la description et les critères d'acceptation, conçoit l'API, réalise des maquettes, et ne dresse qu'ensuite la liste des cas de test. L'implémentation commence après.

L'auteur écrit avoir éprouvé ce processus pendant 3,5 mois : environ 4 000 commits, 1 500 tests, quelque 350 vérifications e2e et environ 25 000 lignes de code de production y sont passés, sans compter la couche de tests.

L'élément central du dispositif est la commande /continue. Elle consulte la liste des histoires et le fichier progress.md, détermine à quelle étape le développement s'est arrêté et fait avancer la tâche sans qu'il faille choisir manuellement l'action suivante.

TDD et gates

Le framework ne se contente pas de demander au modèle d'« écrire une fonctionnalité » : il le guide littéralement à travers un cycle ATDD avec des étapes TDD imbriquées. Côté backend, cela commence par un test d'acceptation au rouge ; Claude descend ensuite vers le cas d'usage et les adaptateurs, puis passe chaque niveau au vert par étapes. La logique est la même pour les autres parties du produit : on fixe d'abord le comportement vérifiable, puis on écrit le code, et non l'inverse. L'auteur cherche ainsi à arrimer le travail du modèle à l'architecture plutôt qu'au hasard.

• entretien et formalisation des exigences de l'histoire
• génération du plan de test et des cas avant le début de l'implémentation
• cycle red-green-refactor pour le cas d'usage, les adaptateurs et les tests d'acceptation
• quality gates vérifiant la rigueur des tests, l'architecture et la couverture
• commit après chaque étape et pause obligatoire pour la relecture humaine

« Avec des prompts nus, on ne va pas bien loin. »

Par-dessus le TDD, l'auteur a ajouté des quality gates en filet de sécurité. À l'étape rouge, le modèle vérifie séparément la rigueur des tests et qu'ils ne cassent pas l'architecture de test ; au vert, il refactorise le code et contrôle la couverture. Chaque gate dispose d'une checklist que le LLM doit parcourir explicitement.

La gestion du contexte fait l'objet d'une attention particulière : chaque sous-étape s'exécute dans un agent distinct, et progress.md permet de réinitialiser le contexte après chaque commit et de ne charger que le minimum de données pour la passe suivante.

Fenêtres d'IDE en parallèle

Le côté pratique de cette approche compte autant que l'architecture elle-même. Un seul lancement de /continue peut durer de 5 à 20 minutes, et jusqu'à 40 minutes, voire une heure, sur des tests lourds. Pour ne pas attendre sur un seul fil, l'auteur conseille de cloner plusieurs fois le dépôt de démonstration, ou d'utiliser des worktrees, et de lancer différentes histoires en parallèle dans des IDE séparés. Dans son propre processus, jusqu'à six fenêtres sont ouvertes en même temps : quatre ou cinq sont occupées par le travail de l'agent, les autres servent à la relecture, au refactoring et à la dette technique.

Pour les cas atypiques, des commandes supplémentaires coexistent avec le flux principal. Pour démarrer, l'auteur a publié deux dépôts : un Kanban de démonstration en Java + React et un squelette vide du framework. /task sert aux corrections de bugs, à l'infrastructure et aux longues tâches qui n'entrent pas dans une histoire avec le rituel TDD complet. /prompt-update sert à améliorer le framework lui-même quand le modèle butte de nouveau sur un problème récurrent.

L'auteur reconnaît ouvertement les limites : la solution est née d'une stack web précise, est taillée pour Clean Architecture et ATDD, consomme beaucoup de tokens et ne rend pas le développement entièrement autonome. Si un bug n'est pas repéré à la relecture, il partira tranquillement en production.

Ce que cela signifie

L'approche montre vers où se déplace le développement mature avec l'IA : des prompts isolés vers des pipelines reproductibles, où le modèle travaille à l'intérieur du processus et non à sa place. La conclusion principale est assez tranchée : un LLM peut déjà accélérer le développement en production, mais seulement s'il est tenu dans le cadre de tests, de checklists, d'étapes courtes et d'un contrôle humain permanent.