Aider: un agente de desarrollo en CLI

#Qué es Aider, y qué hace en tu repositorio

Aider es un asistente de programación en línea de comandos, de código abierto, que se presenta como una herramienta de programación en pareja con una IA en el terminal. Ejecutas el comando aider en un repositorio Git, describes un cambio en lenguaje natural y propone modificaciones de archivos, las aplica y las guarda en un commit. Funciona tanto con modelos alojados (Claude, GPT, DeepSeek) como con modelos locales servidos por Ollama o LM Studio, lo que lo convierte en uno de los pocos agentes de código utilizables sin que ninguna línea de tu proyecto salga de la máquina. El repositorio oficial supera las 49.000 estrellas en GitHub.

Tres cosas lo distinguen de un simple chat. Primero, mantiene un mapa del repositorio: con cada solicitud, envía al modelo una lista de archivos con sus clases, funciones y firmas principales, de modo que el modelo sabe dónde buscar sin que le muestres todo. Segundo, está integrado con Git: cada modificación se convierte en un commit que se puede revertir. Por último, ejecuta en un bucle los comandos que le indicas, como el linter y las pruebas, e intenta corregir lo que falla. No es un agente autónomo que explore la web o inicie servidores: es un editor de código guiado por la conversación.

#Instalar Aider

El método oficial más corto pasa por el paquete aider-install, que instala Aider en su propio entorno Python aislado y, si es necesario, descarga una versión de Python compatible. Para este método, el requisito es tener una versión de Python entre la 3.8 y la 3.13. Existen instaladores de una sola línea basados en uv para macOS, Linux y Windows. El procedimiento anterior con pipx sigue funcionando, pero la documentación actual recomienda aider-install.

python -m pip install aider-install
aider-install

# Vérifier
aider --version

Sitúate después en la raíz de tu proyecto. Si la carpeta no es un repositorio Git, Aider propone crear uno, pero es mejor que lo inicialices tú mismo: toda la red de seguridad descrita más abajo se basa en Git.

#Conectarlo a Ollama sin tener problemas con el contexto

La documentación oficial de Aider para Ollama se resume en cuatro pasos: definir la variable OLLAMA_API_BASE (la dirección habitual es http://127.0.0.1:11434), descargar el modelo con ollama pull, iniciar el servidor y, después, ejecutar aider con el prefijo ollama_chat/ delante del nombre del modelo. Se recomienda expresamente el prefijo ollama_chat/ en lugar de ollama/.

export OLLAMA_API_BASE=http://127.0.0.1:11434
ollama pull devstral:24b
OLLAMA_CONTEXT_LENGTH=8192 ollama serve

# Dans un autre terminal, à la racine du projet
aider --model ollama_chat/devstral:24b

La trampa más costosa es la ventana de contexto. Ollama utiliza por defecto 2.000 tokens de contexto, lo cual es minúsculo para un agente de código, y, un punto decisivo, descarta silenciosamente lo que excede ese límite. Sin saberlo, puedes estar hablando con un modelo que solo ha recibido el principio de tus archivos. Aider limita el problema: por defecto, ajusta por sí mismo la ventana de Ollama al tamaño de cada solicitud más 8.000 tokens para la respuesta. Si prefieres un tamaño fijo, debes usar un archivo de ajustes del modelo, no el archivo de configuración principal.

- name: ollama_chat/devstral:24b
  extra_params:
    num_ctx: 32768

El contexto tiene un coste en memoria: la caché KV crece con la ventana, y un modelo de 24 mil millones de parámetros que ya ocupa aproximadamente 14 GB en Q4 deja poco margen en una tarjeta de 16 GB. La guía sobre la ventana de contexto y la de cuantización de la caché KV ofrecen cifras orientativas sobre los órdenes de magnitud.

#Qué modelo local usar con Aider

Aider es tan bueno como el modelo que lo controla, y la dificultad es doble: el modelo debe razonar sobre el código y respetar un formato de edición estricto. Un modelo que no sigue este formato produce modificaciones que la herramienta no sabe aplicar. La clasificación pública de Aider, basada en 225 ejercicios de Exercism en seis lenguajes, mide precisamente esta doble capacidad; está dominada por modelos alojados de gran tamaño, y los modelos que caben en un equipo personal ocupan posiciones sensiblemente peores. Consúltala antes de esperar un resultado al nivel de los modelos en la nube.

Para un equipo local, Devstral 24B, publicado por Mistral AI y All Hands AI, es un punto de partida coherente: está diseñado para agentes de código, pesa 14 GB en la biblioteca Ollama y anuncia una ventana de 128 000 tokens. En una GPU de 12 GB o menos, hay que recurrir a un modelo más pequeño y aceptar más errores de formato. La guía «Mejor LLM local para programar» compara los candidatos actuales; esta guía no fija ninguna clasificación, porque cambia demasiado rápido.

#Un primer cambio, desde el prompt hasta el commit

1. 01
   Añadir los archivos correctos

   Inicia aider pasándole los archivos que quieras modificar, por ejemplo aider src/api.py src/models.py. Los archivos añadidos son los que puede editar; conoce el resto del repositorio mediante el mapa.
2. 02
   Describir el cambio con precisión

   Escribe una solicitud completa: «Agrega un endpoint GET /users/:id que devuelva al usuario o un error 404 si no existe». Una solicitud vaga produce un diff vago.
3. 03
   Releer el diff

   Aider muestra los cambios y los aplica. Revísalos con /diff antes de continuar: ese es el momento de rechazarlos, no después de tres solicitudes adicionales.
4. 04
   Verificar el commit

   Cada edición se registra con un mensaje descriptivo. Si el resultado es malo, /undo anula el último commit realizado por Aider.
5. 05
   Encadenar pequeñas etapas

   Pide después las pruebas, la gestión del caso límite y el registro de eventos, un paso a la vez. Los pasos pequeños mantienen el contexto breve y el diff legible.

#Los comandos de chat importantes

Aider ofrece decenas de comandos que comienzan con una barra oblicua; basta con unos pocos para trabajar. La regla general: lo que no has añadido al chat no se puede modificar, pero el mapa del repositorio permite al modelo saber que existen otros archivos.

/add et /drop

Agregan o eliminan archivos del chat. Eliminar archivos ya inútiles libera contexto, lo cual es muy importante con un modelo local.

/read-only

Añade un archivo únicamente como referencia: el modelo lo lee sin poder editarlo. Útil para un archivo de convenciones o un contrato de interfaz.

/ask, /code, /architect

Cambian el modo de chat, para un mensaje o de forma permanente con /chat-mode.

/run et /test

/run lance une commande shell et peut en verser la sortie dans le chat ; /test lance la commande de test et ajoute la sortie au chat si elle échoue, ce qui déclenche une correction.

/diff et /undo

/diff montre les changements depuis votre dernier message ; /undo annule le dernier commit s'il a été fait par Aider.

/tokens

Indica el número de tokens utilizados por el contexto actual: consultarlo es un hábito que conviene adquirir para entender por qué un modelo local «olvida».

/map

Muestra el mapa del repositorio enviado al modelo.

#Los modos de chat: code, ask, architect

Aider distingue cuatro modos de chat. El modo code, el predeterminado, modifica tus archivos. El modo ask permite hablar sobre el código sin modificarlo nunca. El modo architect utiliza dos modelos: un modelo arquitecto propone la solución y, después, un modelo editor la traduce en modificaciones precisas de archivos. El modo help responde a preguntas sobre el propio Aider. No existe un modo intermedio llamado "paired"; la combinación de un modelo potente y uno rápido se configura con las opciones --model y --editor-model.

El flujo recomendado en la documentación consiste en alternar /ask y /code: se discute el enfoque en modo ask y luego se cambia al modo code, donde un simple «go ahead» basta para ejecutar el plan acordado. Es una versión más fluida del modo architect con un solo modelo. Para un modelo local de tamaño medio, suele ser el mejor equilibrio: evitas cargar dos modelos en memoria y mantienes el control del plan.

El modo architect se justifica para modelos que razonan bien pero editan mal. Requiere dos solicitudes en lugar de una: actívalo solo si el modo code produce regularmente diffs inválidos.

#Git, tu red de seguridad

Aider se basa en Git para hacer que cada error sea reversible. En cada edición, hace un commit de los cambios con un mensaje descriptivo, generado por el modelo débil a partir del diff y de la conversación, siguiendo el estilo de los commits convencionales. Antes de tocar un archivo con modificaciones pendientes de commit, primero hace un commit de las modificaciones existentes: tu trabajo y el de la IA permanecen separados en el historial. Los commits que crea llevan la mención «(aider)» en el nombre del autor, lo que permite localizarlos.

La consecuencia es un gran número de commits pequeños. La buena práctica consiste en hacer que Aider trabaje en una rama dedicada, revisar los cambios y luego agrupar los commits en uno antes de fusionar. Conviene conocer dos opciones: --no-auto-commits desactiva la creación automática de commits y --git-commit-verify vuelve a activar los hooks pre-commit, que la herramienta omite por defecto con --no-verify. Si tu equipo se apoya en estos hooks, esta opción lo cambia todo.

git switch -c ai/endpoint-users
aider src/api.py
# ... relire, tester, puis :
git rebase -i main

#Ejecutar tus pruebas dentro del ciclo de trabajo

Este es el ajuste que transforma a Aider de un generador de código en una herramienta que se corrige. Con --test-cmd y --auto-test, ejecuta tu suite de pruebas después de cada modificación; si el comando devuelve un código de salida distinto de cero, lee la salida e intenta corregir el problema. El principio es el mismo para el linter, con --lint-cmd, y Aider ejecuta por defecto el linter sobre los archivos que edita.

aider --test-cmd "pytest -x -q" --auto-test --lint-cmd "ruff check"

Dos precauciones. El comando de prueba debe ser rápido: con un modelo local, cada ciclo cuesta ya varias decenas de segundos de generación. Y debe mostrar errores con un código de salida no nulo, de lo contrario Aider cree que todo va bien.

#Lo que falla con un modelo local y cómo superarlo

Errores de formato de edición

El modelo devuelve una modificación que la herramienta no puede aplicar. Cambia a un modelo más grande o prueba el modo architect. La documentación de Aider dedica una página de solución de problemas a estos errores.

Olvido de contexto

Síntoma: el modelo ignora un archivo que acabas de añadir. Causa probable: ventana demasiado pequeña o contexto saturado. Solución: /tokens, eliminar los archivos innecesarios con /drop y después ampliar el contexto.

Archivos demasiado largos

Un archivo de varios miles de líneas satura un contexto local. Divídelo o pide una modificación en una función concreta.

Peticiones vagas

«Mejora este código» genera diffs impredecibles. Especifica el archivo, la función y el comportamiento esperado.

Error de límite de tokens

Aider indica cuándo un modelo supera sus límites y sugiere acciones: pedir cambios más pequeños, dividir los archivos, cambiar de modelo.

#Aider o un agente en el editor

Aider está dirigido a quienes trabajan en el terminal y quieren un historial Git limpio. Si prefieres quedarte en VS Code, Cline ofrece una experiencia equivalente con validación paso a paso; si buscas un agente de terminal más autónomo, OpenCode es una opción. La elección no depende de la calidad del modelo, que es la misma, sino del lugar donde quieras revisar los diffs.

• Aider + Ollama: el flujo de trabajo completo en el terminal
• Mejor LLM local para programar
• Comprender la ventana de contexto
• Cline + Ollama en VS Code
• OpenCode + Ollama en el terminal
• Revisar código con un LLM local antes de hacer un commit

• Fuente: documentación de Aider para Ollama
• Fuente: los modos de chat de Aider
• Fuente: integración Git de Aider
• Fuente: lint y pruebas en Aider
• Fuente: Devstral en la biblioteca Ollama