Vibe Coder sur Visual Studio Code avec Copilot

Le « vibe coding » est une expression inventée par Andrej Karpathy en début d'année, elle désigne une nouvelle façon de programmer, en déléguant entièrement l'écriture du code à l'intelligence artificielle d'un agent. Mais un agent de programmation IA reste un outil, apprendre à le manier demande un peu de temps et quelques efforts.

À qui s'adresse ce tutoriel ? Aux développeurs sous Visual Studio Code, avec un abonnement GitHub Copilot payant, travaillant sur un projet existant.

Le plan gratuit ne suffit pas car nous aurons besoin des derniers modèles d'Anthropic ou d'OpenAI. Ce tutoriel fait de plus l'hypothèse d'une base de code existante avec de préférence un système de gestion de versions (comme Git).

Sommaire

• Configurer Visual Studio Code
• L'agent IA est un perpétuel nouveau venu
• Documenter le projet
• Surveiller la consommation des requêtes premium
• « Vibe coder » une fonctionnalité
• Conseils & réflexions

Configurer Visual Studio Code

Si ce n'est pas déjà fait, ouvrez la barre latérale du Chat en cliquant sur son icône en haut à droite du champ de recherche. En bas de cette barre latérale, passez en mode Agent et choisissez de préférence le modèle Claude Sonnet 4 ou GPT-5.

Les deux meilleurs modèles disponibles dans l'agent de VS Code sont Claude Sonnet 4 et GPT-5. Le premier est plus intelligent, le second plus rigoureux.

Même si cela n'est pas obligatoire, je recommande au développeur qui connait bien son travail d'essayer le mode « YOLO ». Votre VS Code et les plugins de Copilot doivent être à jour. Voici la configuration :

  "chat.agent.maxRequests": 1000,
  "chat.tools.global.autoApprove": true,

Attention : cela fait passer l'agent IA de VS Code dans un mode « YOLO » efficace, mais aussi risqué. Vous devrez désormais le surveiller durant son travail et systématiquement utiliser votre système de gestion de versions afin de pouvoir revenir à une version antérieure en cas de problème.

L'agent IA est un perpétuel nouveau venu

Un agent de programmation IA doit être traité comme un nouvel arrivant. À chaque session de travail, il redécouvre le projet depuis zéro. Et une session de travail ne dure que quelques minutes ou dizaines de minutes, alors on se lasse de se répéter. La bonne nouvelle est qu'il est dévoué et motivé : il lira à chaque fois les guides d'utilisation que nous lui fournirons. Tout commence donc par un effort de documentation.

Documenter le projet

Dans cette section, nous allons mettre en place un embryon de documentation à l'intérieur de votre projet. Voici la structure visée :

_docs/
├── vibe-flow/
│   ├── Code Quality & Refactoring.md
│   ├── How to Write a Technical Specification.md
│   ├── How to Write an Implementation Plan.md
│   └── Vibe Flow Guide.md
├── Code Style Guidelines.md
└── How to Write Unit Tests.md
_plans/
AGENTS.md

Un premier fichier d'instructions

Si vous avez déjà un fichier d'instructions .github/copilot-instructions.md, CLAUDE.md ou autre, passez à la section suivante.

Le premier jet du fichier d'instructions sera généré grâce à une commande fournie par VS Code : appuyez sur Ctrl+Shift+P (ou Cmd+Shift+P sur Mac) et recherchez « Chat: Generate Workspace Instructions File ». Cette commande vous fournit un prompt qui demande à l'agent d'explorer votre projet, le résultat sera enregistré dans un nouveau fichier .github/copilot-instructions.md.

Réorganiser la documentation

Avant toute chose, assurez-vous que votre projet est sauvegardé dans le système de gestion de versions et que l'état du répertoire de travail est propre.

Nous allons réorganiser les instructions provenant du premier fichier d'instructions dans un nouveau dossier de documentation _docs/. La première version de ce tutoriel contenait plusieurs prompts à exécuter laborieusement. Je me suis ensuite rendu compte qu'il était possible de tout gérer en une seule passe. Mais le prompt est devenu trop grand alors je l'ai mis sur GitHub. Voici donc comment faire :

1. Ouvrez ce dépôt GitHub, cliquez sur le lien « this installation prompt » et copiez tout le contenu ;
2. Pour le principe, toujours vérifier que les instructions ne sont pas malveillantes (mais ce dépôt est à moi) ;
3. Ouvrez un nouveau chat (« ＋ ») dans VS Code, collez, et envoyez.

Après l'exécution du prompt, des instructions provenant de votre ancien fichier d'instructions ont été déplacées dans un fichier _docs/Unused Instructions.md. L'agent vous propose un second prompt pour extraire des documents de ce fichier. Si le contenu du fichiers des instructions inutilisées vous semble pertinent, alors vous devriez suivre sa suggestion. Durant ce second travail, l'agent proposera un découpage, n'hésitez pas alors à engager une discussion et lui demander le découpage qui vous semblera adéquat. Par exemple, dans un monorepo contenant un backend et un frontend, j'ai notamment pour habitude de séparer deux notices « How to Work in Backend.md » et « How to Work in Frontend.md ».

À la fin du processus, à la place d'un fichier d'instructions monolithique, vous aurez un fichier AGENTS.md relativement court qui servira de point d'entrée commun aux agents IA sur votre projet. Il référence les fichiers de documentation technique disponibles dans un nouveau dossier _docs/.

Le fichier AGENTS.md est une toute nouvelle convention, proposée par l'équipe de OpenAI Codex, et certains agents ne l'ont pas encore adoptée. VS Code est compatible à partir de la version 1.104 (septembre 2025), Cursor à partir de la version 1.6 (septembre 2025 aussi). Pour les utilisateurs de Claude Code, une simple ligne @AGENTS.md dans son fichier CLAUDE.md suffira à le rendre compatible.

Pourquoi découper la documentation en plusieurs fichiers ?

La fenêtre de contexte d'un agent IA représente la quantité maximale de texte qu'il peut traiter simultanément. Elle contient tout : les instructions, la discussion, le code lu, écrit, corrigé, relu etc. Or, sa taille est limitée. Lorsqu'elle est remplie, il faut redémarrer avec un agent tout neuf. On préfère éviter que cela n'arrive trop vite.

Plus le fichier d'instructions est grand, moins il reste de contexte libre pour travailler. De plus, un fichier monolithique géant implique souvent des explications confuses. C'est pourquoi je recommande de séparer les documentations spécifiques dans des fichiers différents en demandant à l'agent de n'ouvrir que ce dont il a besoin.

Pour la même raison, l'effort consacré à synthétiser les instructions les plus consultées ne sera pas du temps perdu. Il faut être à la fois concis et complet.

Améliorer la documentation

L'agent, aussi performant soit-il, ne remplace pas votre expertise et votre compréhension fine du projet. Cela vaut vraiment la peine de vérifier un à un les documents présents dans le répertoire _docs. Supprimez ce qui est superflu ou évident, ne gardez que ce qui apporte une réelle valeur ajoutée.

Évitez ou limitez les injonctions désagréables en majuscules dans la documentation. Gageons que les techniques pour forcer une IA à obéir seront de moins en moins pertinentes au fur et à mesure que les modèles de langage s'amélioreront. Votre documentation est là pour durer. Considérez que le contenu du dossier de documentation sera utile à tous les nouveaux-venus sur le projet, IA comme humains. Expliquez donc les choses normalement.

Des instructions de workflow ont été téléchargées dans le dossier _docs/vibe-flow/. Elles sont également référencées dans le fichier AGENTS.md. Vous pourrez bien entendu les lire et les adapter. Dans la suite de ce tutoriel, nous allons les utiliser.

Surveiller la consommation des requêtes premium

Nous utilisons Claude Sonnet 4 ou GPT-5, qui sont des modèles premium. Aussi, il faut commencer à surveiller le niveau de consommation des requêtes premium car il y a une limite mensuelle. Cliquez sur l'icône du chat située en bas dans la barre latérale. Repérez le pourcentage de requêtes premium restantes pour le mois en cours.

Astuce : même s'il ne s'agit pas de vibe coding à proprement parler, n'hésitez pas à débloquer toute l'assistance à la programmation en cochant les cases de ce dialogue.

« Vibe coder » une fonctionnalité

Implémenter une fonctionnalité commence par la rédaction de spécifications. Lorsque cela est fait, n'oublions pas qu'un agent IA est, à chaque nouvelle session, un nouveau venu. Même après qu'il ait lu la documentation, on n'envoie pas un nouvel arrivant sur une base de code existante en lui disant de faire comme il le sent. On lui demande comment il envisage de traiter le problème (c'est le plan d'implémentation), on en discute avec lui. Ensuite on le laisse travailler. À la fin, on vérifie le travail.

Les étapes sont alors les suivantes :

1. Écrire des spécifications techniques ;
2. Faire générer un plan d'implémentation ;
3. Relire le plan ;
4. Faire appliquer le plan ;
5. Revue de code et demandes de corrections.

Ce processus est adapté à des tickets complexes. Le plan d'implémentation ne sera pas toujours nécessaire. En fait, il n'y a aucune raison d'être rigide sur quoi que ce soit. Mais, dans le cadre de ce tutoriel, suivons toutes les étapes.

1. Écrire des spécifications techniques

Pour implémenter quelque chose (un ticket) dans votre projet existant, tout commence par des spécifications techniques.

Le travail de spécification peut être fait en amont, avant la priorisation du ticket. Afin d'historiser les décisions, on peut choisir d'en garder une copie dans un logiciel de gestion de tickets.

Il vous faut un sujet concret à décrire en quelques mots ou lignes. Inutile de vérifier trop en détails comment faire car votre agent est particulièrement doué pour investiguer dans la base de code, éclaircir les idées, et rédiger des spécifications. Nos prompts de workflow auront également besoin d'un identifiant de ticket pour fonctionner. Il s'agit en fait d'un nom de répertoire qui sera créé dans _plans/. Si vous n'avez pas de ticket, inventez un identifiant fictif, par exemple 123.

Initialisez éventuellement un nouveau chat (« ＋ »), puis demandez à l'agent :

Read your documentation, then help me write a new spec for ticket 123. It's about [some feature you need]

Vous devriez voir l'agent progresser dans les fichiers de documentation. Il va suivre ses instructions et s'apercevra de l'existence de How to Write a Technical Specification.md et le lira puisqu'on lui demande une « spec ».

L'agent explorera ensuite le projet, puis discutera avec vous.

Lorsqu'il décidera que les informations qu'il a sont suffisantes, l'agent rédigera des spécifications techniques dans un nouveau fichier _plans/123/A1-spec.md. Relisez-les et demandez-lui itérativement de les améliorer. N'hésitez pas à les retravailler à la main.

Lorsque vous modifiez à la main le résultat du travail de l'agent sans prendre la peine de lui expliquer pourquoi, considérez que la session de l'agent devient inutilisable et démarrez-en une neuve. Autrement il restera sur ses idées initiales.

La syntaxe Markdown est un classique car elle est particulièrement bien comprise par les modèles de langage.

2. Faire générer un plan d'implémentation

Contrairement aux spécifications qui sont parfois écrites longtemps avant la phase d'implémentation, le plan d'implémentation devrait être écrit lorsqu'on est prêt à implémenter. Il contient de nombreux détails trop spécifiques comme des numéros de lignes dans le code qui seront immédiatement périmés si un autre travail est fait entre temps. En fait, il fait partie de l'implémentation.

Initialisez éventuellement un nouveau chat (« ＋ »), puis écrivez :

Write the implementation plan for ticket 123.

L'agent devrait remarquer l'existence d'une notice pour écrire un implementation plan, il le lira etc. À la fin il trouvera le fichier des spécifications techniques _plans/123/A1-spec.md. Il déposera un nouveau fichier _plans/123/A2-plan.md à côté.

3. Relire le plan

Relisez attentivement le plan d'implémentation. Discutez des options techniques possibles avec votre agent, demandez-lui de l'amender si nécessaire.

Plus un plan est complexe, plus il importe de faire l'effort de le comprendre. Sous peine de passer ensuite plus de temps à corriger. N'espérez jamais qu'un problème complexe puisse se résoudre correctement comme par magie sans que vous n'ayez à comprendre comment !

Petit point de vocabulaire pour distinguer modèles de langage et agents. On peut voir un modèle de langage (ou « LLM », pour Large Language Model) comme une capacité de raisonnement sur étagère. Des exemples de LLM : Claude Sonnet 4, GPT-5, Gemini 2.5 pro. Ils n'ont pas les mêmes points forts. Un agent de programmation IA est un programme doté d'un chat qui utilise un ou plusieurs modèles pour accomplir des tâches de programmation. Des exemples d'agents : Claude Code, l'agent de GitHub Copilot, celui de Cursor, Gemini CLI, OpenAI Codex CLI. Ces solutions ne se valent pas, les coûts diffèrent aussi. Il ne faut pas hésiter à les essayer et à les réessayer régulièrement car le paysage évolue rapidement.

4. Faire appliquer le plan

Pensez toujours à enregistrer dans le système de contrôle de version (git commit) tous vos éventuels changements en cours avant de demander à l'agent IA d'appliquer un plan d'implémentation. Cela permet de revenir en arrière en cas de problème. Cela permettra aussi de comparer le code avant et après l'application du plan.

Cette fois-ci, nous ne souhaitons pas remplir la fenêtre de contexte avec les détails du workflow donc nous allons donner directement le plan à l'agent. Initialisez un nouveau chat (« ＋ »), glissez-déplacez dedans le fichier du plan d'implémentation, ou bien ouvrez-le et assurez-vous que le fichier ouvert est bien visible par l'agent, puis écrivez :

Implement this plan

La dernière étape du plan demande d'écrire le résumé dans un fichier _plans/123/A3-summary.md.

Relancez toujours une nouvelle session de l'agent avant d'exécuter un plan. D'abord pour éviter la contamination des informations entre tâches, car cela vous empêcherait d'obtenir un résultat cohérent si vous deviez relancer un plan amendé après un échec. Ensuite parce que l'agent IA devient parfois moins fiable et plus confus lorsque sa fenêtre de contexte se remplit. De plus, en fin de contexte, l'agent se résume automatiquement la situation à lui-même puis relance une session neuve en lui passant le résumé, ce qui augmente l'incertitude sur le résultat ; mieux vaut éviter d'atteindre trop vite cette limite.

Le cas échéant, interrompez l’agent dès que vous vous apercevez qu'il va dans une mauvaise direction. Expliquez-lui ce qui ne va pas, il continuera sa session en prenant en compte votre message.

Une astuce : le travail de l'agent IA sur votre base de code peut parfois être bloquant puisque votre projet est en train d'être édité et ne compile ou ne s'exécute plus. Si vous vous demandez quoi faire pendant que l'agent fait son travail, mettez ce temps à profit pour réfléchir aux spécifications techniques des prochaines fonctionnalités. Toutefois, gardez un œil sur ce que fait votre agent.

5. Revue de code et demandes de corrections

Il arrive que l'implémentation fonctionne du premier coup — et c'est fun ! Mais, vous aurez l'occasion de le découvrir, les agents de programmation sont têtus pour certaines choses. Ils ont aussi tendance à dupliquer et complexifier paresseusement le code plutôt qu'à refactoriser, quand bien même ils en seraient parfaitement capables !

Aussi, nous avons un prompt dans le workflow pour inciter l'agent à effectuer des corrections. Initialisez un nouveau chat (« ＋ »), puis demandez :

Ensure code quality for ticket 123.

Ensuite, c'est à votre tour. Sur le plan de la qualité du code, ne laissez rien passer. N'acceptez pas du code qui serait moins bon que ce que vous auriez écrit vous-même. Ne faites pas non plus l'impasse sur du code que vous ne comprenez pas : au besoin, si vous vous êtes aventuré loin de votre zone de confort, c'est éventuellement le moment d'apprendre. Quoi qu'il en soit, vous restez responsable du code que vous commitez de la même manière que le conducteur doit garder le contrôle de son véhicule : en cas d'accident, le comportement de la voiture n'est pas une bonne excuse, celui qui utilise l'outil est toujours responsable.

Lorsque vous demandez à l'agent IA de corriger quelque chose, vous pouvez ensuite lui faire amender une documentation avec ce qu'il a appris. Par exemple :

Update the Code Style Guidelines file with what you've learned.

Il arrive de devoir terminer le travail à l'ancienne, c'est-à-dire à la main. Avec le temps, vous anticiperez de mieux en mieux les tickets sur lesquels l'agent sera efficace et ceux sur lesquels il risque de s'embourber. En n'oubliant pas que, au fil des mises à jour, sa performance s'améliore à pas de géant.

Conseils & réflexions

Ce que vous risquez si vous ne surveillez pas l'agent IA pendant son travail ?

• Rappelez-vous que dans l'étape de configuration, nous avons désactivé les protections, donc l'agent pourrait lancer des outils dangereux en ligne de commande ;
• Il peut aussi se retrouver bloqué dans une boucle infinie en cherchant une solution à un problème sans la trouver, et consommer ainsi une large part, voire la totalité de vos requêtes premium.

Méfiez-vous des prompts malintentionnés. Ne lancez jamais votre agent sur un projet inconnu. Et soyez vigilant à chaque fois que vous lui demandez de rechercher des informations sur Internet.

Le système de gestion de versions est un filet de sécurité, mais gardez à l'esprit que votre agent sait aussi l'utiliser.

Les répertoires _docs et _plans ne sont pas des conventions établies ; ce sont mes choix d'organisation. Il n'existe pas encore de bonnes pratiques en la matière. Je vous ai donné les miennes, adaptez librement.

Pour ma part, j'écris mes prompts et la documentation, tout comme le code, en anglais. Mais le français marchera très bien également.

Pour conclure, un mot sur le TDD. Le TDD en vibe coding est particulièrement efficace pour implémenter un algorithme dans une fonction. Le processus est similaire à ce que nous avons vu dans ce tutoriel, les tests unitaires remplacent le plan d'implémentation : 1. Écrire des spécifications. 2. Faire générer des tests unitaires, en précisant à l'agent de ne pas tenter de les exécuter. 3. Vérifier les tests, les faire compléter et modifier. 4. Faire générer une implémentation à partir des spécifications, l'agent doit faire en sorte que les tests passent. 5. Revue de code et demandes de refactorisations car l'agent, en luttant pour faire passer certains tests, aura peut-être dupliqué des parties de code.

Happy Vibe Coding!

Mise à jour du 14 août — Ajout de GPT-5. La section sur les spécifications techniques a été enrichie. La partie « Documenter le projet » a été complètement réécrite (pour ceux qui ont appliqué la première version de ce tutoriel, suivez simplement la nouvelle procédure, cela vous mettra à jour).

Mise à jour du 18 septembre — Passage à AGENTS.md.

Mise à jour du 20 septembre — Renommage de AI Workflow en Vibe Flow. Ceux qui ont appliqué une précedente version de ce tutoriel avec un fichier INDEX.md et le dossier ai-workflow : ce prompt vous mettra à jour.