Habr décrit un framework d’AI pour Claude avec Clean Architecture et cycle TDD

Sur Habr, une analyse détaillée d'un framework d'IA a été publiée qui force le LLM à écrire du code non pas en mode libre de "vibe-coding", mais selon un processus d'ingénierie rigoureux. L'auteur affirme qu'il mène déjà presque tout son développement par le biais de cette approche et s'appuie sur Clean Architecture, TDD et un examen obligatoire du code par les humains.

Comment le flux est structuré

L'approche est basée sur une idée simple : bon logiciel n'est pas un ensemble de fichiers, mais un ensemble de scénarios de comportement confirmés. C'est pourquoi le travail ne commence pas par la génération de code, mais par la division du produit en histoires indépendantes, chacune fournissant une valeur utilisateur distincte. Pour chaque histoire, Claude passe d'abord par une phase de spécification : mène des entretiens, formule des descriptions, des critères d'acceptation, conçoit des APIs, crée des maquettes et seulement ensuite compile une liste de cas de test. Ce n'est qu'après cela que la mise en œuvre commence.

L'auteur écrit qu'il a testé ce processus en pratique sur 3,5 mois : environ 4.000 commits l'ont traversé, 1.500 tests, environ 350 vérifications e2e et environ 25.000 lignes de code de production, sans compter la couche de test. L'élément central du schéma est la commande /continue. Elle examine la liste des histoires et le fichier progress.md, détermine à quel stade le développement s'est arrêté et fait avancer la tâche sans sélection manuelle de l'action suivante.

TDD et gates

Le framework ne demande pas simplement au modèle d'« écrire une fonctionnalité », mais le guide littéralement à travers le cycle ATDD et les étapes TDD imbriquées. Pour le backend, cela commence par un test d'acceptation rouge, puis Claude descend—aux cas d'usage et aux adaptateurs, après quoi il "verdit" progressivement chaque niveau. La logique est la même pour les autres parties du produit : d'abord le comportement vérifiable est fixé, puis le code est écrit, pas l'inverse. C'est ainsi que l'auteur tente de lier le travail du modèle à l'architecture plutôt qu'à la chance aléatoire.

• entretiens et formalisation des exigences d'histoires
• génération du plan de test et des cas avant le début de la mise en œuvre
• cycle red-green-refactor pour les cas d'usage, les adaptateurs et les tests d'acceptation
• quality gates avec vérifications de la rigueur des tests, de l'architecture et de la couverture
• commit après chaque étape et pause obligatoire pour examen humain

« On ne va pas loin avec de simples prompts. »

En plus du TDD, l'auteur a ajouté des quality gates de sécurité. À l'étape rouge, le modèle vérifie séparément comment les tests sont rigoureux et ne cassent pas l'architecture des tests ; à l'étape verte, il refactorise le code et vérifie la couverture. Chaque gate a une liste de vérification que le LLM doit explicitement parcourir. Un accent particulier est mis sur la gestion du contexte : chaque sous-étape s'exécute dans un agent séparé, et progress.md permet de réinitialiser le contexte après chaque commit et de charger uniquement le minimum de données pour la prochaine passée.

Fenêtres d'IDE parallèles

Le côté pratique de cette approche n'est pas moins important que l'architecture elle-même. Une exécution de /continue peut prendre de 5 à 20 minutes et sur des tests lourds—jusqu'à 40 minutes ou même une heure. Pour ne pas attendre dans un seul fil, l'auteur suggère de cloner le référentiel de démonstration plusieurs fois ou d'utiliser des worktrees et d'exécuter différentes histoires en parallèle dans des IDEs séparés.

Dans son propre processus, jusqu'à six fenêtres sont ouvertes simultanément, quatre ou cinq étant occupées par le travail de l'agent, tandis que les autres sont utilisées pour l'examen, le refactorisation et la dette technique. Pour les cas non standard, il existe des commandes supplémentaires aux côtés du flux principal. L'auteur a publié deux repos pour l'entrée : un Kanban de démonstration sur Java + React et un scaffold de framework vide.

/task est nécessaire pour les corrections de bugs, l'infrastructure et les tâches longues qui ne rentrent pas dans une histoire avec un rituel TDD complet. /prompt-update est pour améliorer le framework lui-même si le modèle trébuche à nouveau sur un problème récurrent. Cependant, l'auteur reconnaît directement les limitations : la solution a grandi à partir d'une pile web spécifique, est adaptée à Clean Architecture et ATDD, consomme beaucoup de tokens et ne rend pas le développement complètement autonome. Si un bug n'est pas détecté à la révision, il parviendra tranquillement à la production.

Qu'est-ce que cela signifie

L'approche montre vers où le développement d'IA mature se déplace : des prompts uniques aux pipelines reproductibles, où le modèle fonctionne à l'intérieur du processus au lieu de le remplacer. La conclusion principale ici est plutôt stricte : LLM peut déjà accélérer le développement de production, mais seulement s'il est maintenu dans les limites des tests, des listes de vérification, des étapes courtes et du contrôle humain constant.