Dentro de Aider: sin herramientas para el modelo, todo lo decide el harness
Un repaso al código fuente de Aider 0.86.3.dev muestra un diseño opuesto al de Codex: el modelo no tiene herramientas, escribe texto y el harness encuentra las ediciones y las aplica.
Aider y Codex se parecen por fuera: escribes, el modelo edita tu código. Por dentro son diseños opuestos. En Codex el modelo tiene herramientas y explora el repositorio por su cuenta; en Aider no tiene ninguna. Un análisis del código fuente de la versión 0.86.3.dev, commit 5dc9490, sigue el recorrido de un mensaje desde que entra hasta que acaba como cambio en disco.
Un objeto por modo
main() construye un único Coder y hace un bucle sobre coder.run(). Cada formato de edición es una subclase de Coder con sus propios prompts y su parser, no un flag. Cuando cambias a /ask o /architect, el código lanza SwitchCoder y main construye un Coder nuevo a partir del viejo, copiando ficheros, historial y coste. Si además cambia el formato de edición, el historial se resume antes: el propio comentario del código avisa de que el formato viejo "confundiría al LLM nuevo", que intentaría imitarlo.
Qué ve el modelo
La petición se monta en ChatChunks con un orden fijo: system prompt, ejemplos, ficheros de solo lectura, el repo map, el historial, los ficheros editables, el turno actual y, al final, un recordatorio de las reglas del formato. Las partes estables van primero y las volátiles al final, de modo que la caché de prompt conserva un prefijo largo. Los ficheros editables quedan después del historial, así que el modelo lee la versión más reciente justo al lado de la petición. Los bloques de contexto se disfrazan de conversación: un mensaje del tipo "aquí están los ficheros" seguido de un "Ok." inventado del asistente. El resumen del historial vuelve igual, como mensaje de usuario que empieza por "I spoke to you previously about...". Todo va a litellm con temperatura 0 por defecto, y los errores reintentables retroceden desde 0,125 segundos, doblando hasta pasar de 60.
Sin herramientas, a propósito
La clase base fija functions = None y el límite de reflexión justo al lado: max_reflections = 3. Tres coders usaron en su día llamadas a funciones JSON para editar, pero están fuera del registro y dos lanzan "Deprecated" al construirse. La única razón que da el repositorio es una nota del changelog de la v0.7.0: los experimentos iniciales mostraban que usar funciones hacía a 3.5 menos competente para programar. Así que el modelo escribe las ediciones como texto entre vallas y Aider las localiza con expresiones regulares.
Esto cambia qué significa "agéntico". Codex itera hasta que el modelo deja de pedir herramientas; el único bucle de Aider es la reflexión: tras un turno, si Aider detecta un problema, lo manda como siguiente mensaje de usuario, como mucho tres veces. Cuentan como problema una edición que no parsea o no encaja, un fichero del repositorio que el modelo nombra y no está en el chat, errores de lint y errores de test. Los cuatro comparten el mismo presupuesto de tres. El segundo es la forma que tiene el modelo de "abrir un fichero": no puede llamar a una herramienta de lectura, así que lo nombra en su respuesta. Aider lo detecta, te pregunta si lo añade y repite el turno. La comprobación corre antes de aplicar cualquier edición, así que una edición válida en esa misma respuesta se descarta: el return temprano llega antes de que se llame a apply_updates(). La persona es la puerta donde Codex tendría una llamada a herramienta.
El formato por defecto es SEARCH/REPLACE: el modelo cita las líneas a cambiar y luego las que van en su lugar. El parser es laxo a propósito, acepta entre cinco y nueve caracteres de marca y busca hasta tres líneas por encima de un bloque para colocarlo.
Para quien opera asistentes de código la diferencia no es cosmética. Un diseño sin herramientas delega en el harness la verificación: el modelo no ejecuta nada por su cuenta y cada acción pasa por confirmación humana. El precio es un bucle corto, tres intentos, y una dependencia total del parser de texto, que es justo donde fallan los formatos abiertos. El análisis está hecho leyendo el código, no ejecutándolo, así que las conclusiones sobre el caching son inferencias del autor, no medidas.
