Éditer du code avec Vibe

Décrire plutôt qu’écrire

Modifier du code avec Vibe consiste d’abord à dire ce que vous voulez, en français, sans chercher à formuler une instruction technique :

Ajoute une validation d'email dans la fonction registerUser

Refactore ce composant pour utiliser des hooks React au lieu des classes

Corrige le bug dans le handler de connexion qui ne gère pas les timeouts

L’agent lit le code existant, en comprend le contexte et propose une modification adaptée. Il s’appuie principalement sur l’outil search_replace, qui procède de manière chirurgicale : seul le bloc concerné est réécrit, le reste du fichier n’est pas touché. Cela évite l’effet redouté de la réécriture complète d’un fichier, où une correction de trois lignes s’accompagne de cinquante lignes de reformatage parasite.

Voir avant d’accepter

Vibe ne modifie jamais un fichier en silence. Il affiche un diff coloré dans le terminal, au format exact de git diff : les lignes supprimées apparaissent en rouge, préfixées par -, les lignes ajoutées en vert, préfixées par +, et le contexte environnant reste visible pour que vous situiez la modification dans le fichier. Tout développeur lit ce format sans effort, ce qui est précisément le but.

Vient alors l’approbation. En mode par défaut, la séquence est invariable : l’agent analyse le code et prépare la modification, il affiche le diff, vous constatez exactement ce qui va changer, puis vous approuvez avec y ou refusez avec n. Aucune modification n’atteint votre codebase sans ce geste. C’est ce qui rend l’outil utilisable sur du code de production : le contrôle final reste chez vous, ligne par ligne.

Refuser n’est d’ailleurs pas la seule issue quand une proposition ne convient qu’à moitié. Le plus efficace est de corriger le tir en conversation :

Presque, mais utilise une regex au lieu d'un split pour le parsing de l'email

Vibe ajuste sa proposition en tenant compte de votre remarque et de tout ce qui a été dit avant dans la session.

Quand la modification touche plusieurs fichiers

Une fonctionnalité réelle se répartit rarement sur un seul fichier, et Vibe gère cette dispersion sans que vous ayez à découper la demande :

Ajoute un endpoint /api/users/:id/avatar avec upload de fichier. 
Crée le route handler, le middleware de validation et le test unitaire.

L’agent identifie les fichiers à modifier et ceux à créer, prépare les modifications pour chacun, puis vous soumet l’approbation fichier par fichier. Vous pouvez donc accepter le handler et refuser le test si sa forme ne vous convient pas.

Faire relire son code

L’édition n’est qu’une partie du travail : Vibe se montre tout aussi utile en relecture. Demandez-lui une revue de sécurité sur un fichier précis avec « Revois les changements dans @src/api/auth.ts et dis-moi s’il y a des problèmes de sécurité », une analyse de performance avec « Analyse ce fichier et suggère des améliorations de performance », ou un contrôle de style avec « Vérifie que ce code respecte les bonnes pratiques TypeScript ». Dans chaque cas, l’agent lit, signale les problèmes potentiels et propose des corrections argumentées.

Pour un audit où la moindre écriture serait inacceptable, ne comptez pas sur votre vigilance au moment d’approuver : retirez purement et simplement les outils d’écriture à un agent dédié.

# ~/.vibe/agents/reviewer.toml
active_model = "devstral-2"
system_prompt_id = "code_reviewer"
disabled_tools = ["write_file", "search_replace", "bash"]

Lancez-le avec :

vibe --agent reviewer

Cet agent ne peut plus que lire et analyser. C’est la configuration à privilégier pour un audit de sécurité, ou pour relire le dépôt d’un prestataire.

Ce qui distingue une bonne demande d’une mauvaise

La qualité de la modification suit directement la précision de la consigne. Comparez ces deux formulations : la première laisse l’agent deviner votre intention, la seconde ne lui laisse rien à inventer.

# Trop vague
Améliore ce fichier

# Précis
Ajoute du logging avec le module winston pour les erreurs dans le handler createOrder,
en loggant le code d'erreur HTTP et le message

Le second réflexe consiste à désigner explicitement le terrain de la modification avec @, comme dans « Dans @src/middleware/auth.ts, ajoute un check du token expiry avant de valider la session ». Le troisième, à ne jamais clore une série de modifications sans contrôle : demandez « Lance les tests pour vérifier que les modifications n’ont rien cassé », et l’agent exécutera la commande appropriée à votre projet — npm test, pytest, cargo test — avant de vous dire si tout passe.

Reste le cas de l’approbation donnée trop vite. Rien n’est perdu : vous pouvez demander à l’agent d’annuler la dernière modification dans @src/api/auth.ts, ou reprendre la main par Git sans quitter le mode interactif, le préfixe ! exécutant la commande shell directement.

!git checkout -- src/api/auth.ts

Points clés à retenir

• Décrivez vos modifications en langage naturel, Vibe génère le code
• Les diffs colorés montrent exactement ce qui change avant approbation
• Le mode par défaut exige une approbation explicite pour chaque modification
• Les modifications multi-fichiers sont gérées automatiquement
• Un agent en lecture seule est idéal pour la code review
• Toujours vérifier les tests après une série de modifications