Quand Codex modifie un mauvais code, la chose la plus tabou est de le supprimer manuellement partout. Gardez d’abord le diff pour confirmer quels fichiers ont été modifiés, puis revenez en arrière selon la granularité de Git. Cela peut non seulement restaurer le projet, mais aussi laisser des indices sur le problème et éviter de répéter le gouffre la prochaine fois.
Première chose : voir ce qui a été changé en premier
Exécutez 'git status' dans le dossier racine du projet et voyez 'git diff'. S’il y a beaucoup de modifications, ne les supprimez pas directement, mais classez-les d’abord par fichier : code métier, fichier de configuration, fichier verrouillé, fichier généré et fichier test. Beaucoup de défaillances ne viennent en réalité que d’un ou deux chemins de configuration ou d’importation, et vous n’avez pas à perdre tous les résultats.
Si vous ne l’avez pas encore validé, il est recommandé de sauvegarder un patch temporaire : git diff > codex-bad-change.patch. Ce document n’est pas destiné au lancement, mais à une comparaison future.
Comment retomber plus stable
Si seul un fichier est cassé, restaurez seulement ce fichier, ne videz pas tout le dépôt. Vous pouvez utiliser le panneau de contrôle de version dans l’éditeur pour supprimer fichier par fichier, ou utiliser la récupération au niveau des fichiers de Git.
Si les modifications du Codex couvrent plusieurs fichiers, expliquons pourquoi chaque fichier a été modifié. Les documents qui ne peuvent pas être expliqués sont d’abord supprimés ; Expliquez clairement mais implémentez un bug dans le fichier puis corrigez-le partiellement.
Comment éviter de trop changer la prochaine fois
Laissez Codex gérer un seul objectif à la fois : écrire d’abord des tests, puis changer d’implémentation, et enfin exécuter la validation. Ne laissez pas cela se refactoriser, corriger des bugs, modifier l’interface utilisateur et optimiser les performances en un seul message. Plus la tâche est confuse, plus il est difficile d’annuler le différend.
Vous pouvez aussi spécifier avant de commencer : « Faites jusqu’à 3 modifications à la fois, listez le plan avant la modification, et listez les modifications réelles et les commandes de validation après l’achèvement. » « Cela réduit considérablement la probabilité de perdre le contrôle.
Que faire sans Git
Pour les projets sans Git, copiez et sauvegardez le répertoire actuel avant de laisser l’IA le modifier. Une meilleure approche consiste à initialiser Git immédiatement et à valider l’état exécutable courant une fois. Les outils de programmation IA sont excellents pour des changements rapides, mais seulement si vous avez un point de retour en arrière.
La conclusion est simple : Codex n’est pas terrible à modifier le code, mais ce qui est effrayant, c’est qu’il n’y a ni différence, ni engagement, ni frontière. Tant que vous laissez d’abord des preuves puis que vous revenez en arrière selon le document, la plupart des problèmes peuvent être résolus rapidement.
