Le vibe coding ne commence pas par le prompt.

Il commence par le contexte.

Un agent sans contexte travaille par approximation. Il essaie de deviner le projet, le ton, les contraintes, l’architecture et le critère de terminé.

Parfois il tombe juste. Souvent il donne seulement cette impression.

Le contexte n’est pas un ornement. C’est une infrastructure de travail.

Chaque étape demande son propre contexte.

Le diagnostic n’utilise pas le même contexte que la planification.

La planification n’utilise pas le même contexte que l’implémentation.

Tout mettre dans le même prompt revient à demander à l’agent de mélanger question, décision et exécution.

Ce qui compte comme contexte

Le contexte ne consiste pas à tout déverser dans le chat.

Un bon contexte est une information organisée, actuelle et utile pour la tâche.

Il peut se trouver dans :

  • AGENTS.md;
  • README.md;
  • PLANS.md;
  • la documentation dans docs/;
  • le code existant;
  • les tests;
  • les décisions enregistrées;
  • les critères de terminé;
  • les commandes de validation.

L’agent doit comprendre le terrain sur lequel il avance.

Pas pour obéir aveuglément. Pour agir avec moins de bruit.

L’erreur du chat unique

Une mauvaise pratique consiste à essayer de faire tout le vibe coding dans un seul chat, une seule conversation ou une seule tâche.

Cela paraît efficace.

Ça ne l’est pas.

Les longues conversations accumulent intention, correction, détour, exception et improvisation. Après de nombreux échanges, personne ne sait exactement quelle décision reste valable.

L’agent perd en netteté.

La personne aussi.

Exploration, planification, implémentation et revue sont des phases différentes. Tout mélanger dans une seule conversation transforme le processus en quelque chose de difficile à auditer.

Le même problème existe dans le prompt.

Ne demandez pas diagnostic, planification et implémentation dans la même requête.

Chaque étape doit être une tâche séparée, avec sa propre entrée, son propre objectif et sa propre sortie.

Un projet ne devrait pas dépendre de la mémoire fragile d’une fenêtre ouverte.

Il devrait dépendre de fichiers, d’un historique, de validations et de décisions enregistrées.

Une étape par tâche

Le meilleur flux est plus petit.

Plus simple.

Plus vérifiable.

Le diagnostic est une tâche.

La planification en est une autre.

L’implémentation en est une autre.

Elles doivent se produire dans cet ordre.

Et elles doivent se produire dans des prompts séparés.

Cette règle vaut aussi pour chaque prompt d’exemple.

Un prompt suggéré doit se concentrer sur une seule étape : diagnostic, planification ou implémentation.

Si le prompt concerne le diagnostic, il ne doit pas demander de plan.

Si le prompt concerne la planification, il ne doit pas demander de changements de code.

Si le prompt concerne l’implémentation, il doit partir d’un plan approuvé et exécuter seulement une partie.

L’exemple doit enseigner la frontière.

Pas seulement résoudre le cas.

Diagnostic

Le diagnostic sert à comprendre l’état actuel.

Il ne doit pas planifier toute la solution.

Il ne doit pas modifier de fichiers.

Étape : diagnostic.

Lis AGENTS.md, README.md et les documents pertinents.
Fais seulement un diagnostic.
N'implémente rien.
Ne crée pas encore de plan détaillé.
Liste le contexte trouvé, les lacunes, les risques et les questions.

Planification

La planification sert à transformer le diagnostic en séquence de travail.

Elle ne doit pas implémenter.

Elle doit créer des étapes petites, vérifiables et ordonnées.

Étape : planification.

À partir du diagnostic approuvé, crée un plan incrémental.
Ne modifie pas le code.
Sépare les étapes par objectif, fichiers probables et validations.
Indique la première étape assez petite pour une implémentation isolée.

Implémentation

L’implémentation sert à exécuter une étape spécifique du plan.

Elle ne doit pas rouvrir tout le diagnostic.

Elle ne doit pas réinventer la planification.

Étape : implémentation.

Implémente seulement l'étape 1 du plan approuvé.
Avant de modifier, dis quels fichiers tu comptes changer.
Ensuite lance les validations disponibles.
Liste les fichiers modifiés, les risques et les points en attente.

Ces prompts sont limités volontairement.

La limite ne gêne pas l’agent. La limite donne une direction.

Si le prompt demande diagnostic, planification et implémentation en même temps, il commence déjà mal.

Un bon vibe coding n’est pas une grande session héroïque.

C’est une séquence de cycles clairs.

Les skills ne sont pas de la décoration

Les skills existent pour élargir la capacité de l’agent dans des situations spécifiques.

C’est la partie importante : spécifiques.

Utiliser une skill sans nécessité est une mauvaise pratique.

Elle peut ajouter trop d’instructions, appeler les mauvais outils, augmenter le coût de la tâche, produire des fichiers inutiles ou déplacer l’attention hors du vrai problème.

Toutes les tâches n’ont pas besoin d’une skill.

Corriger un texte simple ne demande pas le même dispositif que créer une présentation. Ajuster un post ne demande pas le même flux qu’enquêter sur un échec de CI. Implémenter un petit changement de layout ne demande pas de transformer la tâche en recherche large.

La bonne question est :

Cette skill aide-t-elle directement l’étape actuelle ?

Si la réponse est non, ne l’utilisez pas.

Un bon outil a aussi besoin du bon moment.

Trop de contexte gêne aussi

Il existe une autre erreur : envoyer trop de contexte.

Un agent ne s’améliore pas seulement parce qu’il a reçu plus de fichiers, plus de liens, plus de règles et plus d’historique.

Il s’améliore quand il reçoit le contexte pertinent.

Avant de demander n’importe quelle étape, il vaut mieux séparer :

  • l’objectif de cette étape;
  • les fichiers probables;
  • les contraintes;
  • les exemples importants;
  • les commandes de validation;
  • ce qui ne doit pas être modifié.

Le reste peut attendre.

Un bon contexte est un découpage.

Comment diviser une grande tâche

Quand l’idée est grande, ne demandez pas tout.

Transformez-la en étapes.

1. Diagnostic : comprends le problème, le dépôt et les risques. Ne planifie pas en détail. N'implémente pas.
2. Planification : transforme le diagnostic approuvé en petites étapes. N'implémente pas.
3. Implémentation : exécute seulement une étape approuvée.
4. Validation : lance les commandes disponibles et relis le résultat.
5. Enregistrement : documente décisions, risques et prochaines étapes.
6. Étape suivante : avance seulement après validation de l'étape précédente.

Ce flux protège le projet.

Il protège aussi votre esprit.

Vous n’avez pas besoin de tout décider d’un seul souffle. Vous devez créer les conditions pour que la prochaine décision soit meilleure.

Un mauvais prompt

Étape déclarée : diagnostic.

Fais le diagnostic.
Ensuite, dans la même tâche, crée le plan et implémente tout ce qui est nécessaire
pour résoudre tout le projet.

Cette demande ouvre trop de portes.

L’agent devra diagnostiquer, décider et exécuter en même temps.

Cela peut sembler productif au début. Mais le coût apparaît plus tard, quand chaque ajustement oblige à défaire des choix qui n’ont jamais vraiment été décidés.

Un meilleur prompt

Étape : diagnostic.

Lis AGENTS.md et docs/convencoes-conteudo.md.
Fais seulement le diagnostic pour la publication d'un nouveau post.
Ne planifie pas l'implémentation.
Ne modifie pas de fichiers.
Liste le contexte trouvé, les risques, les questions et les prochaines étapes suggérées.

Cette demande a une frontière.

Elle sépare la lecture de la décision. Elle sépare la décision de l’exécution. Elle évite qu’une bonne idée devienne un changement automatique avant la revue humaine.

C’est ainsi que l’agent travaille mieux.

Pas par liberté totale.

Par direction suffisante.

Le principe

Le contexte est la différence entre demander de l’aide et diriger le travail.

Les skills doivent entrer quand elles servent le cycle actuel.

Les conversations doivent être assez petites pour être comprises.

Les tâches doivent être assez petites pour être validées.

Diagnostic, planification et implémentation doivent être séparés.

Toujours en séquence.

Jamais dans le même prompt.

Le projet doit porter sa propre mémoire.

Le vibe coding ne consiste pas à laisser la machine courir.

C’est créer un environnement où elle court dans la bonne direction.