Le jour où l'agent a tout cassé
Vous lancez l'agent IA sur une tâche ambitieuse : "Refactore tout le module de paiement." Vingt minutes plus tard, il a touché 14 fichiers, réécrit des fonctions, déplacé du code. Et là, le site ne démarre plus. Une erreur fatale, quelque part, dans ces centaines de lignes modifiées.
Sans Git, vous êtes seul face au chaos. Vous ne savez plus ce qui marchait avant, ni quelle modification a tout fait exploser. Vous passez votre soirée à recoller les morceaux à la main.
Avec Git bien utilisé, la même situation se règle en deux minutes : git reset --hard sur votre dernier commit propre, et tout revient à l'état d'avant. L'agent peut bien sûr réessayer, mais cette fois sur des bases saines.
La discipline numéro un : Git n'est pas un outil de sauvegarde optionnel quand on code avec une IA. C'est le filet de sécurité qui sépare le pro de celui qui accepte un blob de 2000 lignes et croise les doigts.
Commiter AVANT de lâcher l'IA
Le réflexe naturel est de commiter une fois que tout marche. Avec un agent IA, c'est l'inverse : commitez avant de le laisser faire de gros changements. Vous créez ainsi un point de restauration connu, un état dont vous êtes sûr.
Ce point de référence est ce qui rend git diff et git reset utiles. Si l'IA part dans le décor, vous comparez proprement son travail avec votre dernier état stable.
# Avant de lâcher l'agent sur une grosse tâche
git add .
git commit -m "Etat stable avant refacto paiement"
# L'agent fait son travail... puis on inspecte
git diff # ce que l'IA a réellement changé
git reset --hard HEAD # tout annuler si c'est ratéCette habitude coûte cinq secondes et vous sauve des heures. Un point de restauration avant chaque grosse intervention, c'est le minimum.
Un commit = un changement cohérent
Un commit atomique contient une seule idée : une fonctionnalité, une correction, un renommage. Pas dix choses mélangées. Pourquoi ? Parce que chaque commit devient un point de restauration précis.
Si vous mélangez dans un seul commit la correction d'un bug, l'ajout d'une feature et un renommage massif, vous ne pouvez plus annuler l'un sans perdre les autres. Avec des commits atomiques, vous revenez chirurgicalement à l'état exact qui vous intéresse.
L'outil clé pour cela est git add -p (patch). Il vous fait valider chaque morceau de modification un par un, au lieu de tout balancer en bloc. Parfait pour trier ce que l'IA a produit.
# Valider les changements morceau par morceau
git add -p
# Mettre de côté du travail en cours sans commiter
git stash
git stash pop # le récupérer plus tardAstuce : quand l'agent produit un gros diff, faites git add -p et acceptez seulement les morceaux que vous comprenez. Le reste, vous le relisez ou vous le jetez. Vous reprenez le contrôle ligne par ligne.
Lire le diff et isoler les expériences
L'IA vous dit toujours qu'elle a fait du bon travail. git diff vous dit ce qu'elle a vraiment fait. Lire le diff avant de commiter n'est pas optionnel : c'est votre dernière barrière avant que du code non relu n'entre dans l'historique.
Pour les expériences risquées, isolez l'agent sur une branche dédiée. Si ça marche, vous fusionnez. Sinon, vous supprimez la branche et votre code principal n'a jamais été touché.
# Isoler une experimentation de l'agent
git checkout -b experiment-agent
# ... l'IA travaille librement ici ...
# Ca marche ? On fusionne. Sinon :
git checkout main
git branch -D experiment-agentEnfin, un historique propre transforme "l'IA a cassé quelque chose" en enquête de deux minutes. git bisect trouve automatiquement le commit fautif par dichotomie : au lieu de fouiller des centaines de lignes, vous testez quelques états et Git désigne le coupable.
Attention : git reset --hard détruit définitivement les modifications non commitées. Vérifiez toujours git status avant de l'exécuter : c'est précisément pour ça qu'on commite souvent : pour qu'un reset ne fasse jamais perdre de travail validé.
The day the agent broke everything
You launch the AI agent on an ambitious task: "Refactor the whole payment module." Twenty minutes later, it has touched 14 files, rewritten functions, moved code around. And now the site won't start. A fatal error, somewhere, in those hundreds of modified lines.
Without Git, you face the chaos alone. You no longer know what worked before, nor which change blew everything up. You spend your evening gluing the pieces back together by hand.
With Git used well, the same situation is solved in two minutes: git reset --hard to your last clean commit, and everything returns to its previous state. The agent can of course try again, but this time on healthy foundations.
The number one discipline: Git is not an optional backup tool when coding with an AI. It is the safety net that separates a pro from someone who accepts a 2000-line blob and crosses their fingers.
Commit BEFORE you let the AI loose
The natural reflex is to commit once everything works. With an AI agent, it is the opposite: commit before letting it make big changes. You create a known restore point, a state you are sure about.
That reference point is what makes git diff and git reset useful. If the AI goes off the rails, you cleanly compare its work against your last stable state.
# Before letting the agent loose on a big task
git add .
git commit -m "Stable state before payment refactor"
# The agent does its work... then we inspect
git diff # what the AI actually changed
git reset --hard HEAD # undo it all if it failedThis habit costs five seconds and saves you hours. One restore point before each major change is the bare minimum.
One commit = one coherent change
An atomic commit contains a single idea: one feature, one fix, one rename. Not ten things mixed together. Why? Because each commit becomes a precise restore point.
If you mix a bug fix, a new feature, and a massive rename into a single commit, you can no longer undo one without losing the others. With atomic commits, you return surgically to the exact state you care about.
The key tool for this is git add -p (patch). It makes you validate each chunk of changes one by one, instead of dumping everything in one block. Perfect for sorting what the AI produced.
# Validate changes chunk by chunk
git add -p
# Set aside work in progress without committing
git stash
git stash pop # get it back laterTip: when the agent produces a big diff, run git add -p and only accept the chunks you understand. The rest, you review or discard. You take back control line by line.
Read the diff and isolate experiments
The AI always tells you it did a great job. git diff tells you what it actually did. Reading the diff before committing is not optional: it is your last barrier before unreviewed code enters the history.
For risky experiments, isolate the agent on a dedicated branch. If it works, you merge. If not, you delete the branch and your main code was never touched.
# Isolate an agent experiment
git checkout -b experiment-agent
# ... the AI works freely here ...
# Works? We merge. Otherwise:
git checkout main
git branch -D experiment-agentFinally, a clean history turns "the AI broke something" into a two-minute investigation. git bisect automatically finds the faulty commit by binary search: instead of digging through hundreds of lines, you test a few states and Git points at the culprit.
Warning: git reset --hard permanently destroys uncommitted changes. Always check git status before running it — this is exactly why we commit often: so a reset never loses validated work.
Demandez à l'IA de vous proposer un message de commit clair à partir de votre diff, et de vous aider à découper un gros changement en commits atomiques :
Voici la sortie de `git diff` de mon travail en cours. Aide-moi à découper ces changements en commits atomiques (un seul sujet cohérent par commit). Pour chaque commit, donne-moi : la liste des fichiers ou morceaux concernés, et un message de commit court et précis en français à l'impératif. Si un changement mélange plusieurs idées, dis-moi comment le séparer avec `git add -p`.
L'IA vient de t'aider à découper ton diff. Mais explique d'abord, avec tes mots, pourquoi on commite avant de lâcher l'agent, et ce que git diff puis git reset --hard HEAD permettent une fois qu'il a fini.
git diff montre ce que l'agent a vraiment changé (pas ce qu'il prétend), et git reset --hard HEAD ramène tout à ce dernier commit propre si c'est raté. Sans ce commit préalable, il n'y a rien vers quoi revenir : le diff comparerait contre du code déjà douteux.Écrivez la séquence de commandes Git que vous lanceriez AVANT de laisser un agent IA refactorer un gros module, puis pour inspecter et au besoin annuler son travail. Utilisez au moins : commit, diff, et reset.
Le site marchait, tu n'avais rien commité. L'agent a touché 14 fichiers, le refacto est cassé. Tu lui demandes comment récupérer. Il te propose ce plan. Ton rôle de relecteur : l'accepter ou le rejeter, et dire pourquoi.
# Pas de panique, on revient a l'etat d'avant :
git reset --hard HEADgit reset --hard HEAD ramène au dernier commit ; or il n'y en a pas un de propre récent, et le code cassé n'a jamais été commité. HEAD pointe sur un état bien plus ancien : tu détruirais d'un coup tout le travail de l'agent et le tien, sans rien récupérer d'utile. C'est précisément le scénario que la leçon évite en commitant avant. Le bon réflexe ici : git stash pour mettre les modifs de côté sans les perdre, puis trier au calme avec git diff et git add -p.Sans remonter dans la leçon : à quel moment commite-t-on quand on lance un agent IA, et qu'est-ce qu'un commit atomique ?
git diff et on annule au besoin avec git reset --hard HEAD). Un commit atomique contient une seule idée cohérente (une feature, un fix, un renommage), jamais dix choses mélangées : chaque commit devient un point de restauration précis qu'on peut annuler ou retrouver sans toucher au reste.Git vous protège quel que soit l'outil, mais tous les outils ne se valent pas selon la tâche. La prochaine leçon, choisir son modèle et son outil, vous aide à trier : quel assistant pour un refacto, lequel pour du code jetable, lequel pour explorer une grosse base.
Leçon 12 : Choisir son modèle et son outil →