Workflows quotidiens avec Vibe

Un outil de routine, pas d’exception

Vibe n’est pas un outil que l’on lance occasionnellement, quand on bloque : il est conçu pour s’installer dans le déroulé ordinaire d’une journée de développement. Cette leçon parcourt les usages les plus productifs, tels qu’ils s’observent dans les pratiques réelles de développeurs.

Préparer et soumettre une pull request

Le trajet qui mène du code écrit à la PR ouverte est répétitif, ce qui le rend intéressant à déléguer. Commencez par faire relire votre travail :

Résume les changements que j'ai faits depuis le dernier commit. 
Y a-t-il des problèmes de qualité ou de sécurité ?

L’agent exécute git diff, analyse le code modifié et vous renvoie un retour structuré : bugs potentiels, améliorations possibles, écarts de style. Vous corrigez ce qui doit l’être, puis vous demandez un message de commit conventionnel : Vibe produit un texte au format Conventional Commits — feat:, fix:, refactor: — cohérent avec le contenu réel du diff. La dernière étape tient en une phrase, « Crée une pull request avec un titre clair et une description détaillée des changements » : si le CLI GitHub (gh) est installé, l’agent pousse la branch et ouvre la PR lui-même.

Documenter ce que vous avez laissé en friche

Un usage moins attendu : faire documenter des aliases shell accumulés au fil des années. Si votre .bashrc ou votre .zshrc compte des dizaines de raccourcis dont plus personne ne se rappelle l’intention, une seule demande suffit.

Lis mon fichier @~/.zshrc et documente tous les aliases que tu trouves. 
Pour chacun, explique ce qu'il fait et ajoute un commentaire au-dessus.

Vibe parse le fichier, isole les aliases, en déduit la fonction et ajoute un commentaire descriptif au-dessus de chacun. Le fichier redevient maintenable pour un coût d’attention nul.

Débugger par étapes successives

Face à une erreur, le réflexe le plus rentable est de la donner brute à l’agent avec le contexte de son apparition :

J'ai cette erreur quand je lance le serveur :
TypeError: Cannot read properties of undefined (reading 'map')
Trouve d'où ça vient et corrige-le

L’agent cherche les endroits où .map() est appelé, repère les cas où la variable peut valoir undefined et propose une correction avec vérification de nullité. Sur un bug moins évident, le diagnostic se construit en plusieurs tours, chacun s’appuyant sur le résultat du précédent.

> Le test d'intégration user.test.ts échoue. Lance-le et montre-moi l'erreur.
< [Exécute le test, affiche l'erreur]
< L'assertion à la ligne 42 échoue : expected 200 but got 401...

> Pourquoi le statut est 401 ? Vérifie le middleware d'authentification.
< [Lit le middleware, analyse le flux]
< Le token JWT n'est pas passé dans les headers du test...

> Corrige le test pour inclure le token
< [Propose la modification avec le diff]

Ce cheminement reproduit la démarche d’un développeur qui débogue — observer, formuler une hypothèse, la vérifier — mais chaque boucle prend quelques secondes au lieu de quelques minutes.

Piloter un refactoring long

Les refactorings d’ampleur échouent rarement sur la difficulté technique : ils échouent parce qu’on perd le fil. La todo list de Vibe sert à ça. Faites d’abord établir le plan :

Crée un plan pour migrer ce projet de JavaScript à TypeScript. 
Liste toutes les étapes nécessaires.

Vibe produit une suite de tâches ordonnées, que vous attaquez ensuite une par une — « Commence par la première étape du plan » — en consultant l’avancement avec Ctrl+T, qui affiche ce qui est terminé et ce qui reste. Vous reprenez ainsi le chantier trois jours plus tard sans reconstituer où vous en étiez.

Arriver sur un projet inconnu

L’onboarding est le moment où le gain est le plus visible : une question bien cadrée remplace des heures de lecture de documentation.

Je viens d'arriver sur ce projet. Donne-moi un briefing complet :
- Architecture globale
- Technologies utilisées
- Points d'entrée principaux
- Comment lancer le projet en local
- Tests : comment les lancer et quelle couverture

Dans le même esprit, la génération de tests se demande très directement : « Génère des tests unitaires pour @src/services/payment.ts en couvrant les cas normaux et les cas d’erreur ». L’agent lit le code, identifie les chemins d’exécution, écrit les assertions et adapte de lui-même le framework au projet, qu’il s’agisse de Jest, Vitest ou Pytest.

Automatiser les tâches répétitives

Tout ce qui précède se passe en interactif, mais les vérifications récurrentes gagnent à devenir des scripts, grâce au mode programmatique.

# Script de vérification quotidienne
vibe --prompt "Vérifie les vulnérabilités npm et résume les problèmes critiques" \
     --output json \
     --max-turns 5

# Analyse de code avant commit (hook pre-commit)
vibe --prompt "Vérifie que le code modifié respecte les conventions du projet" \
     --max-price 0.10 \
     --output text

Les deux garde-fous à ne pas oublier ici sont --max-turns et --max-price, qui bornent respectivement le nombre d’échanges et le coût de la session. Sans eux, un agent lancé sans surveillance dans un hook pre-commit peut boucler longtemps, et cher.

Points clés à retenir

• Vibe accélère la préparation de PR avec analyse, commit message et création automatisés
• Le debug interactif permet un diagnostic progressif et ciblé
• La todo list (Ctrl+T) suit la progression des refactorings complexes
• Le mode programmatique (--prompt, --output json) permet l’automatisation dans des scripts
• L’exploration de nouveau projet fournit un onboarding rapide et structuré