Agentes de Código

El código es la herramienta definitiva

En artículos anteriores vimos agentes que llaman funciones predefinidas: buscar en la web, consultar una base de datos, verificar el clima. Esas herramientas son poderosas, pero son fijas . Alguien tuvo que anticipar cada capacidad que el agente podría necesitar y escribir una herramienta para ello. Un agente de clima no puede decidir repentinamente analizar un archivo CSV, porque nadie le dio una herramienta para analizar CSV. Un agente de código rompe esta limitación por completo: en lugar de llamar herramientas preconstruidas, escribe código para resolver problemas. El código puede expresar computación arbitraria, lo que significa que un agente de código puede construir cualquier herramienta que necesite sobre la marcha, siempre que pueda escribir el programa para hacerlo.

Pero los agentes de código hacen más que generar scripts independientes. Los más capaces operan sobre bases de código existentes : leen archivos fuente, comprenden la estructura del proyecto, escriben cambios en múltiples archivos, ejecutan pruebas, interpretan mensajes de error e iteran hasta que el código funciona. Esto es fundamentalmente diferente de pedirle a un modelo que escriba una función en una ventana de chat. Un agente de código está integrado en un entorno de desarrollo real con acceso al sistema de archivos, la terminal, control de versiones y el contexto completo de un proyecto de software.

¿Por qué es esta la forma más poderosa de agencia? Porque cada otro tipo de acción de agente — llamar una API, consultar una base de datos, transformar datos, ejecutar un cálculo — puede expresarse como código. Un agente de código con acceso a una terminal puede hacer cualquier cosa que un ingeniero de software pueda hacer desde su laptop. Puede instalar paquetes, escribir scripts, llamar APIs, procesar datos, construir y desplegar aplicaciones. El techo de lo que puede lograr está limitado solo por su capacidad de escribir programas correctos y su acceso al entorno adecuado.

El panorama de los agentes de código ha crecido rápidamente. Claude Code (Anthropic) es un agente basado en terminal que opera directamente sobre el sistema de archivos local. Codex CLI (OpenAI) toma un enfoque similar con ejecución aislada. Cursor Agent integra el agente dentro de un IDE. Devin (Cognition) se ejecuta en un entorno virtual completo con navegador, terminal y editor. A pesar de las diferentes interfaces y modelos, todos comparten el mismo patrón central: el bucle editar-probar .

El bucle editar-probar

¿Cómo funciona realmente un agente de código? Si has leído el artículo de ReAct en esta serie, ya conoces el patrón central: pensar, actuar, observar, repetir. Un agente de código aplica exactamente ese bucle a la ingeniería de software. El ciclo tiene cinco fases, y comprender cada una es crucial para entender por qué los agentes de código tienen éxito (y dónde fallan).

• 1. Leer: el agente busca en la base de código para encontrar archivos relevantes. Usa herramientas como grep, glob (coincidencia de patrones de archivos) y lectura de archivos para explorar la estructura del proyecto. Una base de código real podría tener miles de archivos — el agente no puede leerlos todos. Tiene que descifrar qué archivos importan para la tarea en cuestión, a menudo empezando con una búsqueda amplia y refinando. Aquí es donde reside la mayor parte del desafío de contexto: encontrar los 5 archivos correctos entre 5,000.
• 2. Planificar: después de leer el código relevante, el agente decide qué cambios hacer. ¿Qué archivos necesitan modificación? ¿Qué enfoque debería tomar? ¿Necesita crear nuevos archivos o solo editar los existentes? Este paso de planificación a menudo implica razonar sobre la arquitectura del proyecto — cómo dependen los módulos entre sí, cuáles son las convenciones, dónde se encuentran las pruebas.
• 3. Editar: el agente escribe o modifica código. Esto podría ser una corrección de bug de una línea, una nueva función o cambios en múltiples archivos. La edición en sí es el paso de acción del bucle ReAct.
• 4. Probar: el agente ejecuta el código o la suite de pruebas del proyecto para verificar si sus cambios funcionan. Este es el paso de observación: el agente obtiene retroalimentación concreta del mundo real (no del razonamiento propio del modelo) sobre si el código es correcto. Una suite de pruebas aprobada es evidencia fuerte de que el cambio funciona. Una prueba fallida es un mensaje de error preciso que señala qué salió mal.
• 5. Corregir: si las pruebas fallan, el agente lee la salida de error, razona sobre la causa del fallo, y vuelve al paso 3. Esta autocorrección iterativa es lo que distingue a un agente de código de un generador de código de un solo intento. Un modelo que genera código en una ventana de chat te da un intento — si está mal, tienes que depurarlo manualmente. Un agente de código depura sus propios errores, a menudo a lo largo de varias iteraciones, hasta que las pruebas pasan.

def code_agent_loop(task, codebase, max_iterations=10):
    """The core loop every code agent runs."""

    for i in range(max_iterations):
        # 1. READ — find relevant files
        relevant_files = search_codebase(codebase, task)

        # 2. PLAN — decide what to change
        plan = reason_about_changes(task, relevant_files)

        # 3. EDIT — write or modify code
        apply_changes(plan, codebase)

        # 4. TEST — run the test suite
        test_result = run_tests(codebase)

        if test_result.all_passed:
            return "Task complete"  # done!

        # 5. FIX — read the errors, loop back to step 3
        task = f"""Tests failed with:
{test_result.error_output}

Fix the failing tests."""

    return "Max iterations reached"

Las herramientas que necesita un agente de código son sorprendentemente simples. La mayoría de los agentes de código funcionan con solo cuatro o cinco capacidades centrales: lectura/escritura de archivos (para ver y modificar código fuente), búsqueda (grep, glob, o alguna forma de búsqueda en la base de código para encontrar archivos relevantes sin leer todo), ejecución de bash (para ejecutar pruebas, instalar paquetes y ejecutar comandos arbitrarios), y operaciones de git (para hacer commits de cambios, crear ramas y gestionar control de versiones). Eso es todo. Con esas cuatro herramientas, un agente de código puede hacer virtualmente cualquier cosa que un desarrollador humano hace desde la terminal.

La parte más difícil del bucle es el paso 1: encontrar el código relevante. Un desarrollador humano que ha trabajado en un proyecto durante meses tiene un modelo mental de dónde está todo. Un agente de código empieza desde cero cada vez. Tiene que navegar una base de código que nunca ha visto antes, descifrar la estructura del proyecto, y localizar los archivos y funciones exactos que necesitan cambiar. Por eso las herramientas de búsqueda en bases de código son tan críticas — y por eso los agentes que pueden explorar eficazmente un proyecto tienden a superar dramáticamente a los que no pueden.

Claude Code

Claude Code es el agente CLI de Anthropic para ingeniería de software. Se ejecuta en la terminal con acceso directo al sistema de archivos local, lo que significa que opera en la misma base de código en la que estás trabajando, en el mismo entorno donde construyes y pruebas tu código. Esto no es un sandbox basado en web ni una ventana de chat — es un agente integrado en tu flujo de trabajo de desarrollo.

La arquitectura es directa: un modelo Claude conectado a un conjunto de herramientas. El conjunto de herramientas central incluye:

• Read: leer cualquier archivo en el sistema de archivos. Soporta lectura de rangos de líneas específicos para archivos grandes, y puede incluso ver imágenes y PDFs.
• Edit: realizar ediciones dirigidas a archivos existentes especificando el texto exacto a reemplazar. Es una operación quirúrgica — el agente no reescribe el archivo completo, reemplaza secciones específicas.
• Write: crear nuevos archivos o reescribir completamente los existentes.
• Grep: buscar contenido de archivos usando patrones regex. Así es como el agente encuentra código relevante en un proyecto grande sin leer cada archivo.
• Glob: buscar archivos por patrón de nombre (por ejemplo, todos los archivos *.test.js ). Útil para comprender la estructura del proyecto.
• Bash: ejecutar cualquier comando de shell. Esta es la herramienta más poderosa — permite al agente ejecutar pruebas, instalar paquetes, usar git, iniciar servidores y ejecutar programas arbitrarios.

Una interacción típica se ve así: le das a Claude Code una tarea ("corrige la prueba fallida en auth.test.js" o "añade paginación al endpoint de API /users"). El agente entonces entra en el bucle editar-probar. Busca en la base de código para comprender la estructura del proyecto, lee los archivos relevantes, planifica su enfoque, hace cambios, ejecuta las pruebas e itera hasta que la tarea está completa. A menudo esto implica múltiples rondas de edición y pruebas, especialmente para tareas no triviales.

User: Fix the bug in the login endpoint — users are getting 500 errors.

Claude Code:
  [Grep] Searching for "login" across the codebase...
  → Found: src/routes/auth.js, src/middleware/session.js, tests/auth.test.js

  [Read] Reading src/routes/auth.js...
  → The login handler calls db.findUser(email) but doesn't handle null

  [Read] Reading tests/auth.test.js...
  → Test "should return 401 for unknown user" is failing with 500

  [Edit] Adding null check in src/routes/auth.js:
    if (!user) return res.status(401).json({ error: "Invalid credentials" });

  [Bash] Running: npm test
  → 23 passed, 0 failed

  Done. The bug was a missing null check — when a user wasn't found in
  the database, the code tried to access user.passwordHash, which threw
  a TypeError. Added a null check that returns 401 instead.

Varias capacidades hacen que Claude Code sea efectivo para tareas de software del mundo real:

• Ediciones multi-archivo: los cambios reales de software rara vez tocan un solo archivo. Añadir una funcionalidad podría requerir modificar un manejador de rutas, actualizar un esquema de base de datos, escribir una migración, añadir pruebas y actualizar documentación. Claude Code puede coordinar cambios en todos estos en una sola sesión.
• Corrección iterativa de pruebas: cuando las pruebas fallan, el agente lee la salida de error y hace correcciones dirigidas. Podría pasar por 3-5 rondas de ciclos de prueba-corrección para un cambio complejo, tal como lo haría un desarrollador humano.
• Operaciones de git: el agente puede crear commits, ramas y pull requests. Esto significa que puede entregar cambios listos para revisión de código, no solo parches crudos.
• Comprensión de proyecto vía CLAUDE.md: un archivo CLAUDE.md en la raíz de un repositorio le da al agente contexto persistente sobre el proyecto: comandos de compilación, convenciones de código, notas de arquitectura, y cualquier otra cosa que un nuevo desarrollador necesitaría saber. El agente lee este archivo al inicio de una sesión, tal como un nuevo miembro del equipo leyendo una guía de incorporación.
• Pensamiento extendido: para problemas complejos, el modelo puede razonar sobre el enfoque antes de tomar acción. Esto es especialmente valioso para tareas que requieren comprender las relaciones entre múltiples componentes o tomar decisiones arquitectónicas.
• Integración MCP: Claude Code puede conectarse a herramientas adicionales vía servidores MCP , extendiendo sus capacidades más allá del conjunto de herramientas integrado. Por ejemplo, conectarse a un servidor MCP de Jira le permite leer tickets y actualizar su estado, o un servidor MCP de base de datos le permite consultar datos de producción para diagnosticar problemas.

Codex CLI y otros agentes de código

Claude Code no es el único agente de código. El mismo patrón de bucle editar-probar aparece en un ecosistema creciente de herramientas, cada una con diferentes modelos, entornos y decisiones de diseño. Comprender el panorama ayuda a clarificar qué es común a todos los agentes de código versus qué es específico de cualquier producto individual.

Codex CLI (OpenAI) es arquitectónicamente similar a Claude Code: un agente basado en terminal que lee archivos, escribe código y ejecuta comandos. La diferencia clave es su énfasis en la ejecución aislada . En lugar de ejecutarse directamente en el sistema de archivos del host, Codex CLI ejecuta comandos en contenedores aislados. Es una concesión de seguridad: el aislamiento limita el daño de un agente que se comporta mal (no puede borrar accidentalmente tu directorio home), pero también significa que el agente tiene menos acceso directo al entorno de desarrollo completo. Usa modelos de OpenAI y soporta edición multi-archivo y ejecución de pruebas dentro de su sandbox.

Cursor Agent toma un enfoque diferente al integrar el agente dentro del Cursor IDE . La ventaja es el contexto: el IDE sabe qué archivos están abiertos, cómo se ve la estructura del proyecto, dónde está la terminal y qué errores reporta el linter. El agente puede ver todo esto y usarlo para tomar mejores decisiones. Cuando Cursor Agent hace cambios, aparecen directamente en el editor — puedes ver el diff en tiempo real, aceptar o rechazar ediciones individuales, y proporcionar retroalimentación sin cambiar a una terminal. La desventaja es que el agente está vinculado al entorno del IDE; no puede ejecutarse en pipelines de CI ni en escenarios de automatización headless como lo puede hacer un agente CLI.

Devin (Cognition, 2024) fue presentado como "el primer ingeniero de software de IA" y representa el extremo más autónomo del espectro. Devin se ejecuta en un entorno virtual completo con navegador web, terminal y editor de código. Puede planificar y ejecutar tareas de software de múltiples pasos de forma autónoma: leyendo descripciones de issues, explorando documentación en un navegador, escribiendo y probando código, y enviando pull requests. Su entorno le da capacidades que los agentes solo de terminal no tienen — por ejemplo, puede verificar visualmente un cambio de UI abriendo un navegador y verificando la página renderizada.

A pesar de sus diferencias, cada agente de código sigue el mismo patrón fundamental. Todos ejecutan el bucle editar-probar: leer código, comprender el problema, hacer cambios, ejecutar pruebas, corregir errores y repetir. Las diferencias están en el modelo (Claude, GPT, etc.), el entorno (terminal, IDE, máquina virtual), el conjunto de herramientas (edición de archivos, navegador, búsqueda), y el nivel de autonomía (humano en el bucle vs. completamente autónomo). El bucle en sí es universal.

Agent          Environment     Execution      Autonomy
─────────────  ──────────────  ─────────────  ──────────────────
Claude Code    Terminal/CLI    Local (host)   Human-in-the-loop
Codex CLI      Terminal/CLI    Sandboxed      Human-in-the-loop
Cursor Agent   IDE (Cursor)    Local (IDE)    Human-in-the-loop
Devin          Full VM         Sandboxed      Fully autonomous

SWE-bench: Midiendo el rendimiento de agentes de código

¿Cómo sabemos si un agente de código es realmente bueno? Generar código que se vea plausible es fácil — generar código que realmente funcione en proyectos reales es una prueba mucho más difícil. SWE-bench (Jimenez et al., 2024) proporciona exactamente esta prueba. Es un benchmark de issues reales de GitHub de repositorios populares de Python de código abierto como Django, Flask, scikit-learn, matplotlib y sympy. Cada tarea le da al agente un repositorio en un commit específico y una descripción de issue (escrita por un desarrollador real). El agente debe producir un parche — cambios de código reales — que resuelva el issue. El parche se evalúa ejecutando la propia suite de pruebas del repositorio: si las pruebas que estaban fallando ahora pasan (y las pruebas que estaban pasando siguen pasando), el issue se considera resuelto.

Este enfoque de evaluación es lo que hace a SWE-bench únicamente riguroso. No hay ambigüedad sobre si el agente "obtuvo la respuesta correcta" — la suite de pruebas es el juez. El agente no puede manipular la métrica produciendo diffs que se ven plausibles pero que en realidad no funcionan. O las pruebas pasan o no.

El benchmark viene en varias variantes:

• SWE-bench (full): 2,294 tareas extraídas de 12 repositorios de Python. Algunas son ambiguas o poco especificadas, haciendo que el conjunto completo sea ruidoso.
• SWE-bench Lite: un subconjunto curado de 300 tareas seleccionadas por claridad y autocontención. Cada tarea tiene una descripción de issue clara y una prueba que valida inequívocamente la corrección.
• SWE-bench Verified: un subconjunto de 500 tareas verificado por humanos donde los anotadores confirmaron que la descripción del issue es clara, la prueba es correcta y la tarea es resoluble con la información proporcionada. Esta es la variante más ampliamente reportada a partir de 2025.

A principios de 2025, el estado del arte en SWE-bench Verified se sitúa en el rango del 50-70%, con los agentes de mejor rendimiento resolviendo aproximadamente la mitad a dos tercios de los issues verificados. Para poner esto en perspectiva: ingenieros de software humanos a quienes se les dan estos mismos issues sin contexto previo sobre el repositorio los resuelven a tasas aproximadamente comparables. Estas no son tareas triviales — requieren comprender bases de código reales, navegar dependencias y escribir parches correctos.

¿Qué revelan los resultados sobre dónde son fuertes los agentes de código y dónde tienen dificultades?

• Fortalezas: correcciones de bugs localizadas (una verificación de null, un error de desfase por uno, un import faltante), adiciones de funcionalidades directas donde el patrón es claro a partir del código existente, y tareas donde la prueba fallida proporciona una señal clara de lo que necesita cambiar.
• Debilidades: tareas que requieren comprensión arquitectónica profunda ("refactorizar el sistema de autenticación para soportar OAuth2"), refactorizaciones multi-archivo donde los cambios tienen efectos en cascada, y tareas donde la descripción del issue es vaga o requiere conocimiento específico del dominio que no está en la base de código.

Más allá de SWE-bench, varios otros benchmarks miden diferentes aspectos de la capacidad de código. HumanEval (Chen et al., 2021) evalúa la generación de funciones independientes (164 problemas de Python con pruebas unitarias). MBPP (Austin et al., 2021) (Mostly Basic Python Problems) cubre 974 tareas básicas de programación. LiveCodeBench (Jain et al., 2024) usa problemas de programación competitiva publicados después de las fechas de corte de entrenamiento de los modelos, previniendo la contaminación de datos. Estos benchmarks evalúan la generación de código (escribir una función a partir de una descripción), mientras que SWE-bench evalúa la agencia de código (navegar una base de código real y producir un parche funcional). La distinción importa: un modelo puede obtener una puntuación perfecta en HumanEval mientras falla gravemente en SWE-bench, porque las dos tareas requieren capacidades fundamentalmente diferentes.

El futuro de los agentes de código

Los agentes de código han mejorado dramáticamente en poco tiempo — de resolver menos del 5% de las tareas de SWE-bench a principios de 2024 a más del 50% a principios de 2025. Pero siguen existiendo limitaciones significativas, y comprenderlas es esencial para usar agentes de código de manera productiva hoy.

La mayor limitación es el contexto . Incluso con ventanas de contexto que exceden un millón de tokens, un agente no puede mantener una base de código grande completa en memoria a la vez. Un proyecto de tamaño mediano podría tener 500,000 líneas de código en miles de archivos. El agente debe trabajar con una vista parcial, leyendo archivos según sea necesario, y esa vista parcial significa que puede perder dependencias importantes, convenciones o efectos secundarios que un desarrollador humano que ha trabajado en el proyecto durante meses conocería. Por eso los agentes de código son mejores en correcciones localizadas que en cambios arquitectónicos: una corrección local solo requiere comprender unos pocos archivos, mientras que un cambio arquitectónico requiere comprender todo el sistema.

Una limitación relacionada es la cobertura de pruebas . El bucle editar-probar solo funciona si la suite de pruebas realmente detecta los bugs que introduce el agente. Si un proyecto tiene cobertura de pruebas irregular, el agente puede hacer cambios que pasen todas las pruebas existentes pero rompan funcionalidad no probada. El agente no sabe lo que no sabe: no puede escribir pruebas para casos extremos que no ha considerado, y no puede verificar comportamiento que no está probado. En la práctica, los agentes de código funcionan mejor en bases de código bien probadas, y tienen dificultades en bases de código donde las pruebas son escasas o poco confiables.

También está el problema de las tareas de horizonte largo . Los agentes de código actuales sobresalen en tareas que le toman a un humano de 10 minutos a una hora: una corrección de bug, una funcionalidad pequeña, una refactorización de un solo módulo. Las tareas que toman días — implementar una funcionalidad compleja desde cero, migrar una base de código de un framework a otro, depurar un problema sutil de concurrencia — siguen estando en gran parte fuera de alcance. El contexto del agente se degrada en sesiones largas, pierde el rastro de decisiones anteriores, y la probabilidad de cometer un error compuesto aumenta con cada paso.

¿Hacia dónde se dirige esto? Varias direcciones son claras. Los agentes mejorarán en mantener sesiones de desarrollo de larga duración a medida que las ventanas de contexto crezcan y los mecanismos de memoria mejoren. Aprenderán a escribir pruebas para sus propios cambios en lugar de depender únicamente de las suites de pruebas existentes, cerrando la brecha de cobertura de pruebas. Desarrollarán mejor comprensión de repositorios construyendo modelos mentales persistentes de la arquitectura del proyecto (análogo a cómo un desarrollador humano construye familiaridad con una base de código con el tiempo). Y mejorarán en coordinarse con humanos — haciendo preguntas de clarificación, presentando opciones para decisiones arquitectónicas, y señalando cuando una tarea está más allá de su nivel de confianza en lugar de producir silenciosamente una mala solución.

Pero quizás la perspectiva más importante sobre los agentes de código hoy es sobre el flujo de trabajo . La configuración más productiva no es "agente solo" sino "humano + agente". El humano proporciona la dirección (qué construir), toma decisiones ambiguas (qué concesión elegir), revisa código crítico (seguridad, corrección en los límites), y maneja tareas que requieren conocimiento contextual profundo (depuración en producción, diseño de sistemas). El agente maneja el trabajo mecánico: encontrar los archivos correctos, escribir el código repetitivo, ejecutar las pruebas, corregir los errores tipográficos, gestionar el control de versiones. Esta división del trabajo permite al humano enfocarse en lo que es únicamente bueno — juicio, creatividad y razonamiento de alto nivel — mientras el agente maneja lo que él es únicamente bueno: ejecución incansable, sistemática y rápida de tareas bien especificadas.

La comparación con fine-tuning con LoRA es instructiva aquí. El fine-tuning le enseña a un modelo cómo hacer algo (una nueva habilidad, un nuevo formato de salida). La agencia de código le permite a un modelo hacer cosas con las habilidades que ya tiene. No necesitas hacer fine-tuning de un modelo para corregir bugs — necesitas darle las herramientas correctas y el bucle de retroalimentación correcto. Eso es lo que proporcionan los agentes de código: no nuevo conocimiento, sino una forma de aplicar el conocimiento existente a tareas de ingeniería de software del mundo real.

Quiz

Pon a prueba tu comprensión de los agentes de código, el bucle editar-probar y cómo se mide el rendimiento de los agentes.