Aider ou OpenCode : choisir un CLI pour votre projet Git

Commencez par Aider si vous souhaitez sélectionner explicitement les fichiers modifiables et examiner de petits changements Git. Essayez OpenCode si vous préférez alterner planification et exécution tout en contrôlant outils et agents. C’est un choix de méthode ; la qualité dépend aussi du modèle, du contexte et de la tâche.

Utilisez un petit projet de test ou deux copies propres d’une même révision. Évitez le dépôt principal contenant du travail inachevé. Excluez secrets, clés professionnelles et données inutiles.

Comparer les contrôles

Besoin	Aider	OpenCode
Choisir fichiers modifiables et références	/add, /read-only, /drop, liste avec /ls	Vérifier contexte et permissions de l’agent sur fichiers et outils
Discuter avant modification	/ask, puis /code	Plan et Build
Contrôler les commits	Commits automatiques configurables	Définir les commandes Git autorisées
Restreindre les outils	Commencer par discuter et contrôler les fichiers ajoutés	Règles allow, ask, deny

La référence Aider explique la sélection des fichiers du chat. L’agent principal OpenCode peut appeler des subagents : examinez les outils réellement invoqués, pas uniquement le nom du mode.

Régler d’abord les commits Aider

Aider commite ses modifications par défaut. Avant d’éditer des fichiers dirty, il peut aussi commiter des changements préexistants. Configurez ce comportement avant la première modification si vous voulez maîtriser tout l’historique.

Pour un essai avec commits manuels, lancez le client déjà installé et configuré :

aider --no-auto-commits --no-dirty-commits

Ces options désactivent les deux automatismes de commit. Elles n’empêchent pas les modifications et ne remplacent pas une sauvegarde. Voir Git integration pour ce comportement, /diff et les conditions de /undo.

Ajoutez uniquement le fichier à modifier et la référence en read-only. Vérifiez /ls, passez en /ask et demandez l’explication du changement. Après accord, utilisez /code avec une tâche limitée. Voir Chat modes.

Vérifier l’agent OpenCode

OpenCode possède les agents principaux Build et Plan. La documentation actuelle décrit Plan comme demandant une autorisation pour les modifications et Bash ; Build sert à exécuter le travail. Plan n’est pas un bac à sable de fichiers distinct. Comparez vos réglages au guide Agents.

Dans un nouveau projet de test, vous pouvez interdire explicitement modifications et commandes :

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "deny",
    "bash": "deny"
  }
}

Enregistrez cela dans opencode.json. Dans un projet existant, fusionnez la section sans remplacer le fichier entier. Les règles propres à l’agent peuvent remplacer les règles globales : vérifiez-les avant l’essai. Cette configuration limite les outils nommés, sans garantir l’isolation de toute action externe.

Demandez une explication du même fichier sans modification. Avant l’édition, ajustez uniquement les permissions nécessaires et vérifiez les commandes accessibles. N’autorisez pas tous les outils pour terminer le test. La syntaxe et la priorité sont dans Permissions.

Une petite tâche commune

Choisissez une modification vérifiable sans croire l’explication du modèle. Par exemple, une fonction générant un fragment d’URL doit convertir " Release Notes " en "release-notes" et lever ValueError pour une chaîne vide. Limitez le changement à un fichier de fonction et un fichier de test.

Pour chaque client, notez la même révision initiale et la même consigne, le modèle et le fournisseur d’accès, les fichiers modifiables, la commande de test autorisée et l’attente de commits automatiques.

Comparez d’abord les plans, puis autorisez une modification limitée dans chaque copie. Exécutez votre test et examinez :

git status --short
git diff --check
git diff --stat
git log -3 --oneline

Après un commit automatique, git diff peut être vide. Comparez le HEAD actuel à la révision de départ enregistrée pour voir le changement complet. Contrôlez séparément les fichiers untracked, absents du diff normal.

Si davantage de fichiers ou de permissions sont nécessaires, notez précisément pourquoi. C’est plus utile que « il semblait plus rapide ». Un succès ne démontre pas un avantage pour d’autres langages, modèles ou dépôts.

Choisir à partir du résultat

Choisissez Aider si le contrôle manuel du contexte et de petites modifications successives vous conviennent. Choisissez OpenCode si les agents distincts et le contrôle des outils vous aident, avec des droits réels clairs et vérifiables. Si un fichier superflu est modifié ou un commit créé à l’improviste, corrigez les réglages et répétez le même essai.

Vérifiez la connexion API séparément de la qualité du code : une autorisation réussie ne prouve pas un code correct. Un guide d’installation OpenCode existe déjà ; le critère ici est un résultat maîtrisé dans votre projet Git.