Поваренная книга вайбкодера: одна LLM в роли архитектора, ревьювера и тестировщика

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

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

L'effet de base sur lequel repose toute la méthode : le même modèle qui vient d'écrire une fonctionnalité et en était satisfait, dans le rôle de reviewer, y trouve trois vrais bugs avec des scénarios de défaillance. Un seul ensemble de poids — deux opinions diamétralement opposées sur le même code.

Faits clés de la méthode :

• La troupe se compose de quatre rôles : architecte, développeur, reviewer, testeur
• Le passage d'un rôle à l'autre s'effectue via des prompts de rôle («skills»)
• L'auteur maintient un vrai projet en production sur ce principe, écrit par des agents avec presque aucun code manuel
• La première étape ne nécessite pas une seule ligne de code écrite manuellement — la troupe se construit elle-même

La division n'est pas un bug, mais une technique architecturale : un reviewer qui ne sait pas qu'il examine son propre code critique plus honnêtement que n'importe quel collègue réel.

Pourquoi le processus doit vivre dans un fichier

Les décisions architecturales prises par le modèle dans le rôle d'architecte disparaissent du contexte au moment où le même modèle bascule vers le rôle de développeur. Sans plan enregistré, l'agent réinvente la roue à chaque fois — dépensant des tokens à répéter ce qui a déjà été fait.

L'auteur insiste : toute décision qui doit survivre à une session doit exister dans un fichier, et non dans le dialogue ni dans la mémoire du modèle. Les skills — ensembles d'instructions de rôle pour chacun des quatre rôles — y sont stockées et chargées à chaque changement de rôle.

«Le processus doit vivre dans un fichier, pas dans la tête» — 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 entre les sessions.

Comment lancer le premier projet multi-agents

La troupe sait se construire elle-même — c'est la principale conclusion pratique de l'article. Il suffit de donner à l'agent dans le rôle d'architecte une description de la tâche : il formera la structure du projet, répartira les tâches entre les rôles et créera les fichiers de plan.

Selon la description de l'auteur sur Habr, tout le cycle — d'un dépôt vide à un code fonctionnel avec revue et tests — se déroule sans une seule ligne écrite manuellement. Le flux de travail se présente comme suit :

• Skills — instructions de rôle définissant la «personnalité» de l'agent dans chaque rôle
• Fichiers de plan — décisions enregistrées qui survivent aux changements de session et de contexte
• Cycle de rôles — architecte → développeur → reviewer → testeur, avec répétition lors de la détection de bugs
• Auto-assemblage — la structure du projet est construite par l'agent-architecte lui-même, pas par un humain

«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 a cessé d'être une expérience de laboratoire : une seule personne avec un seul modèle de langage construit une équipe interne qui se critique plus honnêtement que la plupart des reviewers réels. Le principal obstacle à l'entrée n'est pas l'infrastructure, mais la volonté d'enregistrer le processus dans des fichiers.