Un bucle de agente de programación local: Aider, Ollama, árboles de trabajo de Git y reversión fácil.

Comience por el camino de regreso y elija el modelo más tarde. Un agente de programación local se hace útil cuando puede completar un bucle pequeño y delimitado: localizar un defecto, realizar un cambio modesto, ejecutar la verificación correspondiente y dejar un diferencial que pueda ser guardado o descartado.

La pila conservadora para ese bucle asume que ya existe un repositorio bajo Git con una orden de prueba específica:

• Agente: Aider
• Ejecución del modelo: Ollama, que sirve un modelo en la máquina local
• Aislamiento: un trabajo de Git
• Búsqueda: rg, ejecutado desde la raíz del repositorio
• Validación: cualquier orden de prueba específica que ya tenga el repositorio
• Recuperación: git diff, seguido de un commit o git restore

Solo el agente y el entorno de ejecución local son nuevos. Todo lo demás son herramientas habituales de repositorios, y la configuración no debería convertirse en una segunda plataforma de desarrollo.

Los roles son sencillos. Ollama sirve al modelo. Aider opera dentro de un repositorio Git. Un worktree proporciona su propio punto de extracción para la tarea, generalmente en una rama dedicada, y git restore permite volver a insertar cambios no confirmados en archivos específicos. Este patrón es intencionalmente limitado, orientado a trabajos en repositorios que deben mantenerse revisables y reversibles. No se trata de un estándar de referencia, ni afirma que estas herramientas superen a las alternativas en todos los casos. Los comandos, los nombres de los modelos y el comportamiento de aprobación también varían según las versiones instaladas y la configuración local.

Un ciclo que una persona puede revisar

La salida del agente debe ser una pequeña unidad de progreso que un desarrollador pueda inspeccionar. Un acceso amplio y sin supervisión a una máquina es lo opuesto a eso.

La secuencia:

1. Crear un árbol de trabajo aislado.
2. Encontrar la implementación y su prueba existente.
3. Definir un resultado y sus límites.
4. Solicitar un plan antes de realizar cualquier edición.
5. Aprobar el plan o ajustarlo.
6. Leer la diferencia entre versiones.
7. Ejecutar la verificación del proyecto.
8. Cometer los cambios o restaurarlos.

Las barreras relevantes son de tipo procedural: nada se edita antes de que se apruebe el plan, y ningún cambio se mantiene antes de leer la diferencia entre versiones y realizar la prueba. Solo se les puede llamar controles técnicos si el agente instalado y la configuración del servidor pueden aplicarlos realmente. La velocidad solo es valiosa cuando los resultados son fáciles de verificar y deshacer.

Un ejemplo: nombres de visualización en blanco

Imaginemos un servicio de TypeScript que acepta nombres de visualización en blanco, aunque la API debería rechazarlos. El repositorio cuenta con un archivo de prueba específico y scripts de npm para la validación.

La tarea no consiste en limpiar la validación. Dice lo siguiente:

Rechazar nombres de visualización que contengan solo espacios en blanco, actualizar el archivo de pruebas existente, mantener la API pública sin cambios y ejecutar la prueba correspondiente.

Eso le proporciona al agente un comportamiento, un límite y una verificación.

Dar al cambio su propio proceso de revisión

Desde el proceso de revisión principal:

git worktree add -b fix/display-name-validation ../service-display-name-fix
cd ../service-display-name-fix

Un worktree es un segundo directorio de trabajo adjunto al mismo repositorio. La orden anterior crea ../service-display-name-fix en la rama fix/display-name-validation y deja el directorio principal disponible para otro trabajo.

A partir de aquí, las ediciones, los resultados de las pruebas y el diff pendiente permanecen separados del directorio principal. Si el experimento resulta inútil, sus archivos pueden restaurarse o el worktree eliminarse después de verificar su estado.

Encuentre primero el código y las pruebas

Utilice el propio vocabulario del repositorio para definir el alcance:

rg -n "displayName|display name" src test

Digamos que la búsqueda devuelve:

src/users/validateProfile.ts
test/users/validateProfile.test.ts

El límite ahora es concreto. El agente necesita esos dos archivos y la orden que los valide; además, una invitación vaga para explorar todo el repositorio no aporta nada.

Iniciar Aider con el modelo local de Ollama

Antes de este paso, confirme que Git, Aider, Ollama y rg estén instalados y que el entorno de ejecución de Ollama esté disponible en esta máquina. El modelo elegido también debe funcionar con las versiones instaladas de Aider y Ollama. Aider documenta un proveedor de Ollama: asegúrese de que el modelo deseado exista en Ollama y, a continuación, inicie Aider desde el directorio de trabajo utilizando el prefijo ollama_chat/ en el nombre del modelo.

ollama pull <installed-model>
aider --model ollama_chat/<installed-model>

Sustituya <installed-model> por la etiqueta que realmente utiliza Ollama. La misma etiqueta aparece en ambos comandos, ya que Ollama sirve ese modelo y Aider lo selecciona por su nombre.

Aider puede hacer un seguimiento de sus cambios a través de Git. Inícielo en el worktree, lea la diferencia después de cada edición y deje la decisión de hacer un commit en manos humanas.

También incluye comandos dentro de la chat, un mapa del repositorio, opciones de configuración y controles de límite de contexto. Estos ayudan con la navegación, pero ninguno de ellos establece el alcance ni verifica si una corrección es correcta.

Hacer que el primer paso sea un plan

Restrinja el contexto del agente a los archivos relevantes, utilizando el flujo de trabajo para agregar archivos documentado para la versión instalada de Aider, y no el staging de Git. Luego proporcione una instrucción con un resultado esperado, las rutas permitidas y un comando de validación:

Task: Fix whitespace-only display names being accepted.

Files in scope:
- src/users/validateProfile.ts
- test/users/validateProfile.test.tsConstraints:
- Preserve the public API.
- Do not edit generated files, lockfiles, deployment configuration, or unrelated tests.
- First, explain the current behavior, name the files you would change, and propose the smallest fix.
- Do not edit files until I approve the plan. Treat this as a required review step, and use any available approval controls in your local agent configuration to enforce it where possible.Validation:
- Run: npm test -- validateProfile
- Report the exact command run, files changed, test result, and any unresolved assumption.

Una instrucción como esta evita varios fallos comunes: tareas que se vuelven excesivamente extensas, ediciones fuera de los caminos previstos, y parches que no incluyen forma alguna de validarlos.

Rechace los planes generales desde el principio

Una buena primera respuesta debería seguir este plan:

1. Inspect src/users/validateProfile.ts to confirm how displayName is validated.
2. Inspect test/users/validateProfile.test.ts for the existing validation-test pattern.
3. Add a failing test for a whitespace-only displayName.
4. Make the smallest validation change required to reject that input.
5. Run npm test -- validateProfile.

Antes de aprobar cualquier modificación, pregúntese:

• ¿El plan indica la implementación y las pruebas previstas?
• ¿Está limitado a un único comportamiento?
• ¿Se especifica qué cambio de validación propone?

Deténgase si menciona una migración de esquema, una instalación de dependencias, una actualización de archivo de bloqueo o cambios en endpoints no relacionados. En su lugar, defina mejor la tarea en lugar de aprobar una expansión que solo suene razonable.

La diferencia y el resultado de la prueba son el producto

Una vez aprobado el plan, repita siempre la misma secuencia de revisión.

Observe únicamente los archivos acordados

git diff -- src/users/validateProfile.ts test/users/validateProfile.test.ts

Aquí el resultado esperado es una sola prueba nueva para entrada en blanco, además de un ajuste en la implementación que la satisfaga. La forma en que se aplica ese ajuste depende del contrato de validación existente en el repositorio, por lo que hay que asegurarse de que solo se rechace la entrada que quede en blanco tras el procesamiento y de que los nombres de visualización válidos pasen sin cambios.

Búsquese qué puede ocultar un resumen de sesión:

• la API pública modificada a pesar de que la instrucción lo prohibía
• archivos modificados fuera de la lista acordada
• un reformato que no tiene relación con el error
• una nueva prueba que pasa sin llegar a reproducir el comportamiento deseado
• un ajuste de validación que también rechaza nombres legítimos

El diferencial y el resultado de la prueba son los entregables. El resumen elaborado por el agente sirve como guía para la lectura, pero no demuestra nada sobre su corrección.

Ejecutar la verificación específica

<repository-focused-test-command>

Sustituya el marcador de posición por la sintaxis de comandos y selección de archivos que realmente utiliza el repositorio.

Aider puede analizar y probar automáticamente después de los cambios en el código. Esto podría acortar los ciclos de retroalimentación, pero el comando propio del repositorio sigue siendo la fuente autorizada.

Mantener o descartar el cambio intencionadamente

Si la diferencia y el resultado de la prueba parecen correctos:

git status
git add src/users/validateProfile.ts test/users/validateProfile.test.ts
git commit -m "Reject whitespace-only display names"

Si no lo hacen:

git restore src/users/validateProfile.ts test/users/validateProfile.test.ts

Al no haber una fuente indicada, git restore recupera los dos archivos mencionados desde HEAD, descartando únicamente las ediciones no confirmadas en esos archivos. Verifique git status para conocer los cambios preparados, los archivos no rastreados o las modificaciones en otras ubicaciones antes de considerar que el experimento ha sido descartado.

Cuando toda la rama sea prescindible, elimine el worktree una vez que se haya verificado su estado y se hayan guardado todos los elementos que valga la pena conservar:

git worktree remove ../service-display-name-fix

Git gestiona los directorios de trabajo vinculados a través de sus comandos worktree. La recuperación es un proceso normal, y es lo que hace que sea seguro repetir experimentos con un agente sencillo.

Límites: sistema de archivos, permisos, contexto

Inicio desde la raíz del repositorio

Ejecuta el agente en el directorio del proyecto o en su worktree dedicado. Intentar iniciarlo desde un directorio personal con la esperanza de que una instrucción imponga límites no funciona.

El directorio de trabajo proporciona un alcance por defecto, pero no aplica ninguna restricción. Lo que realmente puede alcanzar el agente está determinado por los permisos del sistema operativo, la configuración de las herramientas y cualquier entorno aislado que esté en uso.

Aprobar los efectos secundarios de forma intencionada

La escritura de archivos, la instalación de dependencias, el acceso a credenciales, el uso de red y los cambios en la infraestructura deben requerir siempre una aprobación deliberada. Cuando el agente o el host no pueden garantizarlo, trátelo como un paso de revisión manual y no lo presente como un control técnico. Verifique qué controles existen antes de confiar en ellos.

OWASP enumera la inyección de comandos como un riesgo que puede hacer que una aplicación con LLM realice acciones no deseadas o divulgue información.

Un punto de partida práctico:

• Permitir la lectura de archivos en el repositorio previsto.
• Requerir aprobación antes de realizar escrituras.
• Requerir aprobación antes de ejecutar comandos de shell con efectos secundarios.
• Hacer que el acceso a la red sea opcional.
• Mantener los secretos fuera del contexto habitual del agente.

Esto ayuda a controlar el alcance de los efectos negativos. No emite juicios sobre si el agente es fiable o no.

Mantenga la configuración simple y visible

Aider lee configuraciones en formato YAML, archivos de entorno y ajustes de claves API. La configuración compartida del proyecto debe ser visible, mínima y separada de los datos confidenciales; además, las credenciales nunca deben incluirse en un archivo de instrucciones del repositorio. Es mejor evitar acumular valores predeterminados globales que nadie pueda inspeccionar ni explicar posteriormente.

Proporciona el contexto necesario para la tarea

El mapa del repositorio ayuda a Aider a comprender la estructura del códigobase, mientras que el contexto limita la cantidad de información que puede procesarse en una sola solicitud. Para realizar una corrección específica, proporciona la tarea, los archivos relevantes, la orden de validación y cualquier regla del proyecto relacionada con el cambio. Incluir archivos generados, documentos adicionales o commits antiguos e irrelevantes suele solo generar desorden.

Un contrato de proyecto para trabajos repetitivos

Si el mismo flujo de trabajo se repite una y otra vez, almacena un archivo de instrucciones ya guardado, un prompt reutilizable o una plantilla de tarea junto al código:

Project contract

Goal:
- [Describe one bounded outcome.]Scope:
- You may edit: [paths]
- Do not edit: [paths, generated files, secrets, deployment configuration]Conventions:
- Follow: [formatter, naming, architecture rules]
- Preserve: [public APIs, compatibility constraints]Validation:
- Run: [exact test, lint, type-check, or build command]
- Report: commands run, files changed, failures, and unresolved assumptionsDefinition of done:
- The requested behavior is implemented.
- Relevant checks have run, or the reason they could not run is stated.
- The final response summarizes the diff and any follow-up work.

El formato no es importante. Lo que cuenta es que las restricciones estén visibles.

Modos de fallo y próximos pasos más pequeños

Búsqueda demasiado amplia. Deténgase, reduzca la lista de archivos y vuelva a comenzar con rutas o símbolos obtenidos de una búsqueda realizada manualmente.

Una propuesta de refactorización demasiado extensa. Divida la solicitud en puntos que puedan probarse. Un solo test fallido, un único comportamiento o un límite de refactorización son mejores que una imposición arquitectónica.

Ediciones fuera del alcance. Rechace el parche, restaure los archivos no relacionados e indique las rutas prohibidas en la siguiente solicitud.

Solicitud de comando inseguro. Pregunte qué cambia y por qué es necesario antes de aprobarlo.

Verificación fallida. Pida un diagnóstico antes de permitir más ediciones, y exija conocer el fallo, su causa probable y el próximo experimento más sencillo.

Inferencia local lenta. Primero reduzca la tarea y el contexto. Solo después evalúe otro modelo o configuración de ejecución. No se realiza ninguna comparación de rendimiento aquí, y cualquier comparación posterior debe registrar la latencia medida, el modelo, el tiempo de ejecución y el hardware.

Un agente más rápido que genera diferencias mayores y más difíciles de revisar no ha mejorado el flujo de trabajo.

Ajuste una cosa a la vez

Cuando la búsqueda, la planificación, las diferencias, las pruebas y la recuperación se comporten de manera predecible, ajuste una sola variable por ronda. Cambie el modelo si la calidad de la salida es el cuello de botella. Cambie la estrategia de contexto si el código relevante sigue pasando desapercibido. Relaje la configuración predeterminada de aprobación solo una vez que varias tareas pequeñas y bien delimitadas hayan demostrado que el prompt nunca protegió nada aquí, y aun así mantenga las diferencias, pruebas y posibilidades de reversión disponibles. Añada la automatización por último, una vez que se pueda confiar en la orden de validación.

La configuración de Aider es sensible a la versión, por lo que vale la pena revisar sus páginas de configuración e historial de versiones antes de reutilizarla. Compare cada comando, identificador de modelo y opción de configuración con las versiones de Aider y Ollama realmente instaladas en la máquina actual.

La regla de decisión es sencilla: mantener una herramienta o configuración solo si mejora la finalización de tareas, la posibilidad de revisión o la capacidad de recuperación.