Le livre de recettes du vibe coding : un seul LLM dans les rôles d'architecte, de relecteur et de testeur

Un développeur russe a publié en août 2026 sur Habr un guide détaillé du développement multi-agents avec un seul modèle de langage, sans achat d'infrastructure supplémentaire et sans plusieurs mois de paramétrage.

Qu'est-ce que la « schizophrénie du LLM » ?

Tout la méthode repose sur un effet de base : le modèle qui vient d'écrire une fonctionnalité et s'en estime satisfait trouve, dans son rôle de relecteur, trois vrais bugs, scénarios de plantage à l'appui. Un seul jeu de poids, deux avis diamétralement opposés sur le même code.

Les faits clés de la méthode :

• La troupe compte quatre rôles : architecte, développeur, relecteur, testeur
• On passe d'un rôle à l'autre grâce à des prompts de rôle (les « skills »)
• L'auteur fait tourner sur ce principe un vrai projet de production, écrit par des agents presque sans code manuel
• La première étape n'exige pas une seule ligne de code écrite à la main : la troupe se construit toute seule

Ce dédoublement n'est pas un bug mais une technique d'architecture : un relecteur qui ignore qu'il examine son propre code se montre plus honnête dans sa critique que n'importe quel collègue en chair et en os.

Pourquoi le processus doit vivre dans un fichier

Les décisions d'architecture prises par le modèle dans le rôle d'architecte disparaissent du contexte au moment où ce même modèle bascule dans le rôle de développeur. Sans plan consigné par écrit, l'agent réinvente la roue à chaque fois et dépense des tokens à refaire ce qui a déjà été fait.

L'auteur insiste : toute décision appelée à survivre à une session doit exister dans un fichier, et non dans le dialogue ni dans la mémoire du modèle. Les skills, c'est-à-dire les jeux d'instructions propres à chacun des quatre rôles, sont stockés au même endroit et chargés à chaque changement de rôle.

«

Le processus doit vivre dans un fichier, pas dans la tête », telle est la thèse centrale du guide publié sur Habr.

Le changement de contexte entre les rôles prend quelques secondes ; les accords et décisions accumulés ne se perdent pas d'une session à l'autre.

Comment lancer un premier projet multi-agents

La troupe sait se construire toute seule : c'est le principal enseignement pratique de l'article. Il suffit de donner à l'agent dans le rôle d'architecte la description de la tâche : il établit la structure du projet, répartit le travail entre les rôles et crée les fichiers de plans.

Selon la description de l'auteur sur Habr, tout le cycle, du dépôt vide au code fonctionnel avec relecture et tests, se déroule sans une seule ligne écrite à la main. Le flux de travail se présente ainsi :

• Skills : instructions de rôle qui définissent la « personnalité » de l'agent dans chaque rôle
• Fichiers de plans : décisions consignées par écrit, qui survivent aux changements de session et de contexte
• Cycle des rôles : architecte → développeur → relecteur → testeur, avec reprise en cas de détection de bugs
• Auto-assemblage : c'est l'agent architecte, et non un humain, qui construit la structure du projet

«

Accessible, sans encyclopédie : le temps d'un café », c'est ainsi que l'auteur décrit le format de son guide sur Habr.

Ce que cela signifie

Le développement multi-agents n'est plus une expérience de laboratoire : une seule personne, avec un seul modèle de langage, monte une équipe interne qui s'autocritique plus honnêtement que la plupart des relecteurs humains. Le principal seuil d'entrée n'est pas l'infrastructure, mais la volonté de consigner le processus dans des fichiers.