Qué hace diferente a un agente CLI de código de otro
Pídele a un agente CLI de código que arregle un test que falla y no te va a responder con una sugerencia. Lee la salida del test, abre el archivo, edita una línea, vuelve a correr el test y avisa cuando pasa. Ese bucle es el producto, no la ventana de chat.
El modelo que hay dentro del bucle se lleva la mayor parte de la atención, y también es la parte que cambia más rápido: los proveedores meten modelos nuevos cada pocos meses, y varios agentes te dejan elegir. Lo que se queda fijo es el harness que envuelve al modelo: qué herramientas puede usar, cómo gestiona el contexto, qué puede ejecutar sin preguntar, y dónde se ejecutan esos comandos. Dos agentes con el mismo modelo por dentro pueden comportarse de forma muy distinta por eso. El harness es lo que en realidad estás eligiendo.
Cómo funciona el bucle agéntico
Quita el marketing y todo agente CLI de código corre el mismo ciclo:
- El modelo recibe tu petición más el contexto que el harness haya montado: archivos abiertos, salida reciente de la shell, instrucciones del proyecto.
- En vez de limitarse a escribir texto, el modelo puede emitir una tool call: “ejecuta este comando de shell”, “escribe estos bytes en este archivo”, “busca este patrón”.
- El harness ejecuta esa llamada de verdad, sobre tu filesystem o tu shell reales, y devuelve el resultado al contexto del modelo.
- El modelo lee el resultado y decide qué hacer a continuación: llamar a otra herramienta, o responderte a ti.
Esto se repite hasta que el modelo decide que la tarea está terminada. No necesita un plan cerrado antes de actuar. Ejecuta un comando, lee qué pasó y ajusta, que es también por qué un agente puede consumir docenas de tool calls en una tarea que al final resultó simple.
Nada de esto necesita una nueva arquitectura de modelo. Necesita un modelo bueno eligiendo qué herramienta llamar y cuándo parar, y un harness que le dé herramientas que valga la pena llamar.
Qué herramientas tiene realmente un agente de código
La lista de herramientas integradas es corta y poco espectacular: leer un archivo, escribir o editar un archivo, ejecutar un comando de shell, buscar en el código por nombre de archivo o por contenido, y en muchos agentes, traer una URL o manejar un navegador. Refactorizar, depurar, escribir tests, leer un stack trace: todo eso es el modelo componiendo estas primitivas, no una función aparte que haya construido el proveedor.
Las decisiones de diseño que importan están en los detalles. ¿“Editar un archivo” exige una coincidencia exacta de texto contra el contenido actual, más seguro y fácil de revisar, o el modelo puede sobrescribir el archivo entero, más rápido y más fácil de romper? ¿“Ejecutar un comando de shell” se ejecuta directamente, o dentro de un sandbox que bloquea el acceso a red y las escrituras fuera del proyecto? Pon el mismo modelo detrás de respuestas distintas a esas dos preguntas y obtienes agentes que no se parecen en nada.
Cómo gestionan los agentes de código un contexto más grande que la ventana
Una base de código real no cabe en una ventana de contexto, y una sesión larga produce mucha más salida de herramientas de la que nadie pegaría en un prompt. Los agentes combinan varias técnicas para lidiar con esto:
- Lectura selectiva. El agente busca el archivo o la función relevante en vez de cargar todo el repositorio, el mismo instinto que tienes cuando haces
grepantes decat. - Compactación. Cuando la conversación pasa un umbral de tamaño, el harness resume los turnos anteriores en una forma más corta y sigue trabajando desde ahí, cambiando detalle por espacio.
- Subagentes. Una tarea grande se divide en tareas más pequeñas, cada una enviada a una llamada de modelo nueva con solo el contexto que necesita. Solo el resultado vuelve a la conversación principal.
- Retrieval. Algunos agentes indexan el código y usan el mismo patrón de retrieval que hay detrás de RAG para traer solo los fragmentos relevantes para la pregunta actual. Otros se saltan el índice y confían solo en la búsqueda.
La compactación es la que muerde. Un detalle de temprano en la sesión, como un flag que mencionaste una sola vez, puede caerse del resumen. Si un agente empieza a ignorar algo que le dijiste hace una hora, esa suele ser la causa, y una sesión nueva con los datos clave repetidos lo arregla.
Qué puede ejecutar un agente de código sin pedir permiso
El harness decide hasta dónde llega el agente antes de parar y preguntar. En un extremo, cada edición de archivo y cada comando de shell espera tu aprobación. Seguro, y lento: el agente te interrumpe constantemente. En el otro extremo, el agente corre en un entorno con sandbox y nadie vigilando, lo que encaja con trabajo en segundo plano como arreglar un test inestable y abrir un pull request mientras haces otra cosa.
La mayoría del uso diario está en medio. Las acciones de solo lectura, como buscar y abrir archivos, pasan automáticamente. Cualquier cosa destructiva o que salga hacia fuera, como borrar un archivo o hacer push a un remoto, espera un sí.
Esto es una política que aplica el harness, no una propiedad del modelo. El mismo modelo es cuidadoso o temerario según lo que se le permita hacer sin supervisión.
Cómo el MCP le da nuevas herramientas a un agente de código
Las herramientas integradas cubren el filesystem y la shell, pero el trabajo real muchas veces necesita más: consultar una base de datos interna, o abrir un ticket en tu issue tracker. El Model Context Protocol (MCP) es el estándar abierto que da esto sin que cada proveedor de agentes tenga que escribir una integración a medida para cada servicio.
Un servidor MCP describe las herramientas que ofrece y cómo llamarlas. Cualquier agente compatible con MCP puede conectarse, listar esas herramientas y llamarlas exactamente igual que a las suyas propias. El agente no necesita código específico para ese servicio: lee las descripciones de las herramientas y decide cuándo son útiles, de la misma forma que decide cuándo correr grep.
El coste es contexto. En muchos agentes, las descripciones de herramientas de cada servidor conectado ocupan espacio en la ventana en cada turno, así que una docena de servidores que usas poco hacen que cada petición pese más. Conecta solo los que el proyecto necesita.
Qué hacen los archivos AGENTS.md y CLAUDE.md
Casi todos los agentes buscan un archivo de instrucciones en markdown en la raíz de tu repositorio y lo leen antes de hacer nada. AGENTS.md es la convención neutral entre proveedores; algunas herramientas usan su propio nombre, como CLAUDE.md. Ahí escribes lo que el modelo no puede deducir del código: qué comando corre los tests, y qué directorios son generados y no se deben tocar a mano. Cualquier cosa que el agente tendría que adivinar, y adivinar mal, va aquí.
Muchos agentes también leen archivos de instrucciones en subdirectorios, así que un monorepo puede tener un archivo raíz más uno más específico por cada paquete. Si un archivo más profundo sobrescribe al raíz o se suma a él varía según la herramienta, así que revisa la documentación de la que uses.
Diez líneas en este archivo evitan que el agente tenga que redescubrir tu comando de tests cada sesión.
Cómo comparar agentes CLI de código
Cuando el bucle y la lista de herramientas son iguales en todos lados, las listas de features dejan de decir mucho. Estas cuatro preguntas sí separan las herramientas de formas que cambian tu día a día:
| Pregunta | Qué significa para ti |
|---|---|
| ¿Dónde corre: terminal, IDE o segundo plano? | Un agente de terminal vive en tu shell y funciona junto a cualquier editor. Un agente de IDE se conecta a la vista de diff y al historial de undo de tu editor. Un agente en segundo plano trabaja sin supervisión a partir de una descripción de tarea y te entrega un pull request, lo que encaja más con trabajo de backlog bien definido que con depuración interactiva. |
| ¿El harness es open source o propietario? | Un harness abierto como OpenCode o Aider puedes apuntarlo a cualquier modelo al que tengas acceso por API, incluyendo uno que corras en local con Ollama, y puedes leer exactamente qué hace. Un harness propietario suele estar ajustado para los modelos propios de su proveedor y necesita menos configuración. |
| ¿Cómo pagas: API por token o suscripción? | La facturación por token sigue el uso, así que las sesiones autónomas largas cuestan más. Una suscripción pone un tope a lo que gastas pero añade límites de uso y te ata a los modelos de un proveedor. |
| ¿Qué tan profundo es el sandbox? | Algunos agentes ejecutan comandos directamente en tu máquina; otros siempre corren dentro de un contenedor o una VM, el mismo tipo de aislamiento que dan los contenedores Docker. La ejecución directa no necesita configuración y es la opción más arriesgada para algo que dejas corriendo sin supervisión. |
Clasifica el modo, no la marca. Un mismo proveedor suele ofrecer una herramienta de terminal, una extensión de editor y un modo en la nube que abre pull requests; tanto Claude Code como OpenAI Codex funcionan así. Los valores por defecto de permisos y sandbox cambian entre esos modos, así que juzga el que de verdad vayas a usar.
Cómo elegir un agente CLI de código para tu flujo de trabajo
Sáltate los leaderboards. Los puntajes de benchmark se mueven cada pocas semanas y dicen poco sobre tu repositorio. Responde dos preguntas en su lugar: ¿quieres el agente en tu terminal o en tu editor?, y ¿quieres que trabaje sin supervisión en segundo plano o en un bucle contigo aprobando cada paso? Esas respuestas reducen el campo a dos o tres candidatos.
Después escribe un AGENTS.md para tu proyecto, dale a cada candidato la misma tarea real de tu backlog, y quédate con el que produzca el diff que mergearías con menos cambios.