vibecode-pro-max-kit : un harnais de développement piloté par spécifications pour agents de codage

Le problème visé : un agent qui perd le fil

Le README ouvre sur une formule courte : « Your AI forgets. This remembers. » Le diagnostic est celui de toute session longue avec un agent de codage. Au fil des échanges, le contexte se dégrade, l'agent repart sur une hypothèse abandonnée vingt messages plus tôt, et le résultat ressemble moins à une fonctionnalité qu'à un empilement de rustines. Le kit se présente comme un remède à ce qu'il appelle la context rot, la pourriture du contexte. Sa réponse n'est pas un modèle plus gros mais un protocole : sept phases nommées Research, Spec, Innovate, Plan, Validate, Execute et Update-Process, franchies dans cet ordre, avec des points de contrôle entre elles. Le public annoncé est large (vibecoders, product owners, dirigeants), ce qui est en soi un signal : l'outil suppose que la personne qui décrit le besoin n'est pas forcément celle qui relit le code. La phase Spec est donc centrale. Vous y écrivez ce que vous voulez construire sous forme d'histoires utilisateur en langage courant, et les phases suivantes mesurent leur travail par rapport à cette référence. Le pari est explicite dans le README : c'est l'endroit le moins coûteux pour détecter un malentendu.

RIPER-5 : sept phases et deux boucles qui se corrigent seules

Le mécanisme central tient en deux boucles. La première, appelée PVL, enchaîne plan, vérification, correction : l'agent relit son plan, cherche les manques, les comble, puis recommence. La seconde, EVL, applique la même logique aux tests. Le README indique que chacune peut tourner jusqu'à dix cycles. Ce plafond compte : il empêche une boucle de correction de tourner indéfiniment sur un problème qu'elle ne sait pas résoudre. Un second outil, vc-autoresearch, reprend le motif find-gaps, fix, repeat et peut être pointé vers des plans, des tests, des spécifications, de la documentation ou des évaluations. Avant de s'engager sur une conception, l'agent peut lancer des sondes de faisabilité qui rendent un verdict VIABLE ou NOT-VIABLE. Le détail intéressant est ailleurs : un sélecteur de stratégie compare, avant chaque phase, le coût d'un agent seul, de plusieurs agents ou d'une équipe coordonnée, puis retient l'option la moins chère qui convient. Le README décrit aussi une répartition des modèles : le modèle coûteux écrit le code, un modèle moins cher fait le reste. Aucun chiffre d'économie n'est fourni, et cette répartition dépend entièrement de la tarification de votre fournisseur.

La mémoire projet écrite sur disque

La promesse de survie au redémarrage repose sur un choix simple : les notes de progression sont écrites sur disque à chaque phase. Une exécution interrompue peut donc reprendre là où elle s'était arrêtée, y compris dans une nouvelle session. Le kit apprend la base de code lors de la configuration initiale et met à jour ses notes partagées après chaque fonctionnalité livrée. C'est le point où le projet se distingue d'un simple fichier de règles collé dans un prompt système : la mémoire est un artefact du dépôt, pas un état de conversation. Le revers est immédiat et le README ne l'aborde pas. Ces notes vivent dans votre arborescence, elles évoluent à chaque phase, et rien dans la documentation fournie ne décrit de politique de nettoyage ou de versionnement de ces fichiers. Sur un dépôt où plusieurs personnes travaillent en parallèle, il faut décider tôt si ces notes sont commitées, ignorées ou régénérées, sinon elles deviennent une source de conflits.

Installation et vie du kit en ligne de commande

L'installation tient en une ligne curl, que le README présente comme détectant les nouveaux utilisateurs et les utilisateurs de retour, sans écraser vos fichiers. Le kit expose ensuite une commande par étape du cycle de vie : setup, update, publish. La version 3.2.4 des notes de release porte sur un correctif de perte de données dans install.sh, avec un report des répertoires de contenu vers vc-update. La 3.2.3 indique que vc-update exécute une migration adaptative sur les installations dont la version est identique. La 3.2.5 ajoute des indications d'installation pour Windows. Ces trois entrées, prises ensemble, racontent quelque chose de précis : l'installateur et le chemin de mise à jour ont bougé trois fois en deux jours, et l'une de ces corrections concernait une perte de données. Ce n'est pas un argument contre l'outil, c'est un argument pour lire install.sh avant de le lancer sur un dépôt qui compte. Le kit annonce 15 agents, 33 skills, 10 hooks et 7 outils, ainsi que 36 validateurs chargés de contrôler sa propre structure. Ces validateurs sont des vérifications mécaniques, pas des avis, et c'est probablement la partie la plus solide du dispositif.

Autopilot : la promesse et ce qu'elle coûte

Le kit met en avant un mode autopilot en trois voies (quick, fast, full) et une commande /goal décrite comme un jeton run-until-done : un bloc à copier-coller qui maintient l'agent en marche de phase en phase sans arrêt, et qui reprend l'exécution dans une session neuve. Le README parle explicitement de zéro porte humaine. C'est le point où il faut être direct : une chaîne qui avance sans validation humaine déplace le contrôle, elle ne le supprime pas. Le contrôle se fait en amont, dans la rédaction de la SPEC, et en aval, dans la relecture du diff. Si votre SPEC est floue, l'autopilot produira avec assurance quelque chose que vous n'avez pas demandé, et les boucles PVL et EVL ne rattraperont pas une erreur d'intention : elles vérifient la cohérence interne du plan et des tests, pas l'adéquation au besoin réel. La clarification d'intention, qui pose quelques questions ciblées quand une demande est vague, est le seul garde-fou amont mentionné, et elle repose sur la qualité de votre réponse.

Ce que le kit ne fait pas, et à quoi le comparer

Le kit ne remplace ni votre CI, ni vos tests, ni votre revue de code. Il organise la façon dont un agent aborde une tâche. La comparaison la plus utile est avec Spec Kit de GitHub, qui partage la même intuition : écrire une spécification avant de laisser l'agent coder. La différence d'approche est nette. Spec Kit reste centré sur la production et la gestion des artefacts de spécification, que vous enchaînez vous-même avec des commandes distinctes. vibecode-pro-max-kit va plus loin dans l'orchestration : boucles de correction automatiques, sélection de stratégie d'agents, répartition entre modèles, mémoire persistée par phase. Ce surcroît d'automatisation a un prix en lisibilité. Avec Spec Kit, vous voyez chaque étape parce que vous la déclenchez. Ici, une exécution en mode full peut traverser sept phases et vingt cycles de correction avant que vous ne regardiez le résultat. Si votre équipe veut comprendre pourquoi l'agent a pris une décision, le second outil demande plus de travail de reconstitution.

Licence, maintenance et coût de mise à jour

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Le kit embarque des prompts, des définitions d'agents et des skills : si vous les adaptez à votre organisation, pensez à ce que vous redistribuez. Le rythme de publication est élevé, avec trois versions entre le 20 et le 21 juin 2026 selon les notes de release. Un rythme soutenu signifie des correctifs rapides, mais aussi que le fichier install.sh et le chemin vc-update sont des surfaces mouvantes. La commande vc-update, qui exécute une migration adaptative même quand la version installée est identique, mérite un essai sur une copie du dépôt avant usage réel. Rien dans le matériel fourni ne permet d'estimer le coût en jetons d'une exécution complète : le README affirme que la répartition entre modèles réduit la dépense, sans donner de mesure. Ce point reste à vérifier par vous, sur vos propres tâches.

Conclusion éditoriale

À adopter si vous confiez à un agent des fonctionnalités entières et que vous acceptez de rédiger une SPEC en langage courant avant toute conception : le cycle RIPER-5 et la commande /goal sont faits pour ce cas. À éviter si votre travail quotidien consiste en corrections ponctuelles, car les voies Quick Fix et Fast existent précisément pour ne pas payer la cérémonie complète. Avant de vous engager, vérifiez trois choses dans le dépôt : le contenu de install.sh et la façon dont il traite vos fichiers existants, le script vc-update et sa migration adaptative, et la liste des 36 validateurs, qui sont les seuls garde-fous mécaniques du kit.

Sources officielles

1. Issues
2. License: MIT
3. README
4. Releases
5. withkynam/vibecode-pro-max-kit on GitHub