Un agent de code peut piloter une correction de bug de bout en bout — reproduire, localiser, corriger, vérifier, valider — mais vous gardez le contrôle en limitant la boucle avec des permissions ciblées, une approbation humaine et des étapes petites et réversibles. L'agent fait la frappe ; vous décidez ce qui s'exécute vraiment.
1. REPRODUCE → write/run a failing test that demonstrates the bug (red)
2. LOCATE → search the codebase, read the relevant files, form a hypothesis
3. PROPOSE → draft a minimal fix (you can review the plan before any edit)
4. VERIFY → run tests + lint/typecheck → fix is proven by the test going green
5. REVIEW → show the DIFF for your approval (nothing committed yet)
6. COMMIT → only after approval, on a branch, with a clear message
L'idée clé est la vérification dirigée par les tests : l'agent n'affirme pas « corrigé » — il le prouve en faisant passer un test en échec. Le test en échec de l'étape 1 est le signal objectif que le changement a fonctionné.
- SCOPED PERMISSIONS → allowlist safe commands (test, lint); prompt for the rest
- APPROVAL GATES → human confirms destructive/irreversible actions + the final commit
- SMALL STEPS → one focused change at a time → easy to review and revert
- BRANCH / WORKTREE → work isolated from main; throw it away if it goes wrong
- DIFF REVIEW → read the actual diff before commit, not just the agent's summary
# The agent runs the suite itself and reports the result before proposing a commit
npm test -- --runInBand # red before the fix, green after → objective verification
git diff # you review every line that will be committed
L'exécution dans une branche ou un worktree git signifie que le pire cas est git checkout main — l'expérience n'a jamais touché votre état de travail. Les petits commits réversibles rendent chaque étape facile à inspecter et à annuler.
La programmation agentique vous fait passer de taper chaque ligne à examiner et orienter. L'effet de levier est réel, mais le risque qu'un agent valide avec assurance un changement faux ou destructeur aussi. Garder une porte d'approbation humaine avant les commits, vérifier avec des tests plutôt que de faire confiance à la prose, et isoler le travail dans une branche vous permet de capturer la rapidité de l'automatisation tout en restant celui qui décide ce qui atteint main.