Agentes de IA en desarrollo de software: arquitectura, loops y lo que cambia realmente en el trabajo de un dev

Qué es un agente: más allá del chatbot

La confusión más habitual es tratar "agente de IA" como sinónimo de "LLM con más contexto". No lo es.

Un agente es la combinación de cuatro componentes que operan en un loop: un modelo de lenguaje como núcleo de razonamiento, un conjunto de herramientas (tools) que le dan acceso a sistemas externos, un mecanismo de memoria que persiste información entre pasos, y un loop de ejecución que itera hasta completar el objetivo o alcanzar un criterio de parada.

El patrón que articula ese loop se llama ReAct (Reason, Act, Observe), formalizado por Yao et al. (2023) y hoy la base sobre la que se construyen la mayoría de los frameworks agénticos. El modelo razona sobre el estado actual, decide una acción, la ejecuta, observa el resultado y vuelve a razonar. No es un pipeline estático de pasos predefinidos. Es un bucle que se ajusta en runtime.

loop:
  thought  = llm.reason(state, tools, memory)
  action   = llm.select_tool(thought)
  result   = tool.execute(action.params)
  memory.update(result)
  if llm.is_goal_reached(state):
    break

La diferencia crítica respecto a RAG estático: un sistema RAG hace una sola recuperación y genera. Un agente puede hacer N recuperaciones, evaluar la relevancia de cada resultado, reformular la query si no tiene suficiente contexto y solo entonces generar. Opera hasta tener lo que necesita.

Anatomía de un agente: las tres superficies de configuración

Hay tres lugares donde se define el comportamiento de un agente. Entender cada uno es necesario para construir agentes que funcionen en producción.

System prompt. Define el rol, las restricciones y el scope del agente. Un system prompt vago produce comportamiento impredecible. Un system prompt preciso produce comportamiento auditable. La especificidad aquí no es opcional: es la principal palanca de control. Un buen system prompt define qué hace el agente, qué no hace, qué tools puede invocar y en qué orden, y cuáles son sus criterios de éxito. Cuanto más específico, más predecible y auditable el comportamiento en producción.

Tool schema. Define las capacidades externas del agente mediante JSON Schema. El modelo no ejecuta nada directamente: razona sobre qué tool invocar, con qué parámetros, y el runtime hace la ejecución. Separar razonamiento de ejecución es lo que permite auditar, limitar y controlar el comportamiento del agente.

{
  "name": "read_file",
  "description": "Lee el contenido de un archivo del repositorio.",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "Ruta relativa al archivo desde la raíz del repo"
      }
    },
    "required": ["path"]
  }
}

Política de autonomía. Qué puede hacer el agente sin confirmación humana y qué requiere aprobación explícita. Un agente que lee y analiza puede operar de forma completamente autónoma. Un agente que escribe en el repo o despliega necesita checkpoints humanos. Definir esta frontera antes de construir (no después) es lo que distingue una arquitectura agéntica de un sistema que se dispara solo.

Configuración de entorno: CLAUDE.md y context window sobre el codebase

Para agentes que operan sobre un repositorio real, la configuración del entorno de proyecto es tan importante como el system prompt.

El fichero CLAUDE.md en la raíz del repositorio actúa como system prompt de proyecto: describe la estructura de directorios, las convenciones de código, los comandos relevantes y el contexto de negocio que el agente necesita para operar de forma coherente. No es documentación para humanos. Es contexto estructurado para el agente: qué comandos ejecutan los tests, qué convenciones de estilo aplican, qué criterios definen un PR aprobable. Sin ese fichero, el agente opera sin contexto de proyecto y el comportamiento es genérico. Con él, opera con el mismo conocimiento de entorno que un dev experimentado del equipo.

La context window sobre el codebase define qué parte del repositorio es visible para el agente en cada momento. Para repos grandes, cargar todo el codebase es inviable. La solución estándar es combinar un índice semántico (embeddings del código) con recuperación bajo demanda mediante la tool read_file. El agente recupera solo lo que necesita para cada tarea.

Casos reales en dev: dónde los agentes aportan valor hoy

Hay cuatro patrones de uso que ya están en producción en equipos de software.

Revisión de PRs. El agente recibe el diff, accede al contexto relevante del codebase, ejecuta los tests, verifica convenciones y genera un informe estructurado. Opera sobre el repo real, no sobre fragmentos. A diferencia de un reviewer humano, no se cansa en el PR número 12 del día.

Generación de tests desde specs. El agente lee la especificación de una feature, analiza el código de implementación y genera los tests unitarios e de integración correspondientes. El output no es perfecto, pero reduce drásticamente el tiempo de scaffolding.

Refactorización de legacy. El agente analiza un módulo, identifica deuda técnica según criterios definidos en el system prompt (complejidad ciclomática, duplicación, cobertura) y propone los cambios. Con una política de autonomía bien definida, puede hacer los cambios directamente y abrir un PR.

Documentación desde código. El agente recorre el codebase, lee las funciones y genera o actualiza la documentación inline y los READMEs. El tipo de tarea más predecible y donde la autonomía total tiene menos riesgo.

El dato que conviene entender bien

La narrativa habitual sobre agentes de IA en desarrollo dice que reducen el tiempo de implementación entre un 40% y un 70%. Es un rango que circula mucho y que merece matiz.

El estudio más riguroso publicado hasta la fecha (un RCT con 16 desarrolladores senior trabajando en sus propios repositorios, METR, julio 2025) encontró que el uso de herramientas de IA en early 2025 aumentó el tiempo de completar tareas un 19%. Los desarrolladores esperaban una reducción del 24%. La percepción y la realidad divergieron de forma significativa.

Ese dato no invalida los agentes. Lo contextualiza. El mismo estudio señala que los agentes autónomos ya son capaces de implementar correctamente la funcionalidad core de issues reales en varios repositorios. El mismo estudio advierte que muchos desarrolladores preferirían no trabajar sin IA incluso en condiciones controladas, lo que genera sesgo de selección hacia abajo en la medición del speedup real.

Lo que sí es consistente en todos los estudios (METR, 2025; DORA, 2025; Sarkar, 2025): los agentes desplazan el trabajo del dev hacia arriba en la cadena. Menos tiempo ejecutando, más tiempo definiendo, prompting, revisando y validando. Sarkar (2025), usando datos de Cursor sobre producción real de software, documenta que los workers con más experiencia delegan más trabajo a agentes, hacen menos preguntas y aceptan el output a mayor tasa que los junior. La habilidad de usar agentes bien es, en sí misma, una habilidad que se aprende.

El dev no desaparece. Cambia de rol: de ejecutor a arquitecto y validador. Eso requiere entender la arquitectura agéntica lo suficientemente bien para diseñar el system prompt correcto, definir las tools adecuadas y saber cuándo intervenir.

Para cerrar

Un agente bien construido no es un LLM con más acceso. Es un sistema con estado, herramientas, políticas de autonomía y un loop de ejecución que puede operar durante minutos o horas sobre un entorno real.

Construir uno que funcione en producción requiere exactamente lo mismo que cualquier sistema de software: diseño explícito, criterios de parada claros y observabilidad sobre lo que ocurre dentro del loop.

En IOX usamos este stack en proyectos reales. Si estás evaluando introducir agentes en tu flujo de desarrollo, hablamos.