Aider u OpenCode: elegir un CLI para tu proyecto Git

Empieza probando Aider si quieres elegir expresamente los archivos editables y revisar cambios pequeños en Git. Empieza con OpenCode si prefieres alternar planificación y ejecución, con control de herramientas y agentes. Es una elección de workflow; la calidad depende también del modelo, el contexto y la tarea.

Usa un proyecto de prueba o dos copias limpias de la misma revisión. No hagas la comparación en el repositorio principal con cambios pendientes. Excluye secretos, claves de trabajo y datos innecesarios.

Controles que conviene comparar

Necesidad	Aider	OpenCode
Elegir archivos editables y de referencia	/add, /read-only, /drop y lista con /ls	Revisa contexto y permisos de archivos y herramientas del agente
Discutir antes de editar	/ask, después /code	Plan y Build
Controlar commits	Commits automáticos configurables	Decide qué comandos Git se permiten
Limitar herramientas	Empieza discutiendo y controla los archivos añadidos	Reglas allow, ask, deny

El manual de comandos de Aider explica cómo se seleccionan y usan archivos en el chat. El agente principal de OpenCode puede recurrir a subagents: revisa las herramientas realmente invocadas, no solo el nombre del modo.

Configura los commits de Aider antes de editar

Aider crea commits de sus cambios por defecto. También puede confirmar cambios preexistentes antes de editar archivos dirty. Ajusta esto antes de la primera modificación si quieres controlar todo el historial.

Para una prueba con commits manuales, inicia el cliente instalado y configurado así:

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

Los parámetros desactivan esas dos acciones automáticas; no impiden editar ni sustituyen una copia de seguridad. Consulta Git integration para ese comportamiento, /diff y las condiciones de /undo.

Añade solo el archivo de la tarea como editable y el de referencia como read-only. Revisa /ls, pasa a /ask y pide explicar el cambio. Tras acordarlo, usa /code con una tarea acotada. Véase Chat modes.

Revisa los permisos del agente OpenCode

OpenCode tiene agentes principales Build y Plan. La documentación actual indica que Plan pide autorización para editar archivos y ejecutar Bash; Build está orientado a realizar el trabajo. Plan no es un sandbox de archivos independiente. Contrasta tu configuración con Agents.

En un nuevo proyecto de prueba puedes prohibir explícitamente edición y comandos:

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

Guárdalo en opencode.json. Si el proyecto ya existe, combina la sección sin sustituir todo el archivo. Las reglas del agente pueden prevalecer sobre las globales: compruébalas antes. Esto limita las herramientas indicadas, no garantiza aislar todas las acciones externas.

Pide explicar el mismo archivo sin cambiarlo. Antes de editar, modifica solo los permisos necesarios y comprueba los comandos disponibles. No autorices todas las herramientas para completar la prueba. La sintaxis y prioridad están en Permissions.

Una tarea pequeña para ambos

Elige un cambio comprobable sin confiar en la explicación del modelo. Por ejemplo, una función que genere un fragmento URL debe convertir " Release Notes " en "release-notes" y lanzar ValueError con una cadena vacía. Limita la modificación a un archivo de función y otro de pruebas.

Anota para cada cliente la misma revisión inicial y el mismo prompt, modelo y proveedor de acceso, archivos editables, comando de prueba permitido y si esperas commits automáticos.

Compara primero los planes y autoriza después el cambio acotado en cada copia. Ejecuta tu prueba y revisa:

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

Un commit automático puede dejar vacío git diff. Compara el HEAD actual con la revisión inicial registrada para ver todo el cambio. Revisa los archivos untracked por separado: no aparecen en el diff normal.

Si hacen falta más archivos o permisos, anota el motivo concreto. Aporta más que decir «parecía más rápido». Una ejecución correcta no demuestra superioridad con otros lenguajes, modelos o repositorios.

Decide según el resultado

Elige Aider si te sirve seleccionar contexto manualmente y revisar cambios pequeños. Elige OpenCode si necesitas agentes distintos y control de herramientas, y sus permisos reales resultan claros y verificables. Si cualquiera modifica un archivo extra o crea un commit inesperado, ajusta la configuración y repite la prueba.

Comprueba la conexión API por separado: autorizarse correctamente no garantiza código correcto. Ya existe una guía de instalación de OpenCode; aquí importa obtener un resultado controlado en tu proyecto Git.