Componentes de un agente de programación

• Un agente de programación es un sistema compuesto por un bucle de control y un harness de software centrado en un LLM, que repite la escritura, ejecución y retroalimentación de código
• El agent harness se encarga de la gestión de contexto, acceso a herramientas, composición de prompts y control de estado; el coding harness, especializado en tareas de programación, gestiona el repositorio, las pruebas y la revisión de errores
• Un agente de programación opera con seis componentes: contexto en tiempo real del repositorio, caché de prompts, acceso a herramientas, gestión de contexto, memoria de sesión y delegación a subagentes
• Incluso con el mismo LLM, el rendimiento y la experiencia de usuario cambian mucho según la calidad del diseño del harness, y un buen harness ofrece un entorno de desarrollo continuo y consciente del contexto
• Mini Coding Agent es un ejemplo mínimo implementado en Python puro de esta estructura, y se diferencia de OpenClaw en su especialización para programación y en su alcance operativo

---

Componentes de un agente de programación

• Un agente de programación es un sistema compuesto por un bucle de control centrado en un LLM y un software harness que lo envuelve, con una estructura que repite la escritura, modificación, ejecución y retroalimentación de código
• Un LLM es básicamente un modelo de predicción del siguiente token, y un modelo de razonamiento (reasoning model) es un LLM entrenado para realizar más razonamiento intermedio y verificación
• Un agente es un bucle de control que repite llamadas al modelo, uso de herramientas, actualización de estado y decisión de finalización para alcanzar un objetivo
• El agent harness es la estructura de software que envuelve ese bucle y se encarga de la gestión de contexto, acceso a herramientas, composición de prompts y control de estado
• El coding harness es una forma especializada para trabajo de código, que gestiona el contexto del repositorio, la ejecución de código, las pruebas y la revisión de errores

Relación entre LLM, modelos de razonamiento y agentes

• Un LLM puede compararse con el motor, un modelo de razonamiento con un motor reforzado, y el agent harness con el sistema que controla ese motor
• Tanto los LLM como los modelos de razonamiento pueden realizar tareas de programación por sí solos, pero en un entorno real de desarrollo se necesita gestionar contextos complejos como exploración del repo, búsqueda de funciones, ejecución de pruebas y análisis de errores
• El coding harness maximiza el rendimiento del modelo y ofrece una experiencia de programación mucho más potente que una simple interfaz de chat

El papel del coding harness

• Es una capa de software que envuelve al modelo y realiza ensamblado de prompts, exposición de herramientas, seguimiento del estado de archivos, ejecución de comandos, gestión de permisos, caché y almacenamiento de memoria
• Incluso con el mismo LLM, el rendimiento y la experiencia de usuario cambian mucho según el diseño del harness
• Por ejemplo, un modelo open-weight como GLM-5 puede ofrecer un rendimiento similar al de Codex o Claude Code si se integra en un harness de ese nivel
• OpenAI ha mantenido ejemplos de modelos de posprocesamiento separados por harness, como GPT-5.3 y GPT-5.3-Codex

6 componentes clave de un agente de programación

• 1. Contexto en tiempo real del repositorio (Live Repo Context)

  • El agente debe reconocer el estado actual del repositorio Git, la rama, la documentación y los comandos de prueba
  • Instrucciones como “arregla las pruebas” cambian según la estructura y el contexto del repo, así que antes de trabajar se recopila un resumen del repositorio
  • Esto evita empezar desde cero cada vez y permite asegurar una base estable de trabajo (stable facts)

• 2. Estructura del prompt y reutilización de caché (Prompt Shape and Cache Reuse)

  • Como el resumen del repo, la descripción de herramientas y las instrucciones generales no cambian con frecuencia, se almacenan en caché como “prefijo estable del prompt (stable prompt prefix)”
  • En lugar de reconstruir el prompt completo en cada solicitud, solo se actualizan las partes cambiadas
  • En sesiones repetidas, esto reduce el desperdicio de cómputo y mantiene la consistencia de las respuestas

• 3. Acceso y uso de herramientas (Tool Access and Use)

  • En vez de limitarse a proponer comandos, el modelo puede ejecutar comandos reales mediante el conjunto de herramientas definido por el harness
  • Cada herramienta tiene formatos de entrada y salida claros, y límites definidos, y antes de ejecutarse pasa por validación y proceso de aprobación
  • Por ejemplo: “¿es una herramienta conocida?”, “¿los argumentos son válidos?”, “¿la ruta de trabajo está dentro del workspace?”
  • Con esto mejoran la seguridad y la confiabilidad; se reduce la libertad del modelo, pero aumenta la utilidad práctica

• 4. Minimizar la expansión del contexto (Minimizing Context Bloat)

  • En sesiones largas, lecturas repetidas de archivos, logs y salidas de herramientas pueden provocar problemas por exceso de longitud del prompt
  • El harness lo gestiona con dos estrategias
    • Clipping: resumir textos largos, logs y notas a una longitud determinada
    • Summarization: comprimir y resumir el historial antiguo de la conversación
  • Los eventos recientes se conservan con detalle, mientras que la información antigua se deduplica y comprime
  • Como resultado, la calidad del contexto impacta más en el rendimiento real que la calidad del modelo

• 5. Memoria de sesión estructurada (Structured Session Memory)

  • El agente separa el estado en memoria de trabajo (working memory) y transcripción completa de la conversación (full transcript)
  • El registro completo incluye todas las solicitudes, respuestas y salidas de herramientas, y permite reanudar la sesión
  • La memoria de trabajo guarda en forma resumida la información importante del momento, como la tarea actual, archivos clave y notas recientes
  • La transcripción compactada (compact transcript) sirve para reconstruir el prompt del modelo, y la memoria de trabajo para mantener la continuidad de la tarea

• 6. Delegación con subagentes acotados (Delegation With Bounded Subagents)

  • El agente principal crea subagentes para procesar tareas auxiliares en paralelo
  • Por ejemplo, puede separar como subtareas la ubicación de la definición de un símbolo, el contenido de un archivo de configuración o la causa de una falla en pruebas
  • Los subagentes heredan solo el contexto necesario y están restringidos con límites como solo lectura o profundidad de recursión limitada
  • Tanto Claude Code como Codex admiten subagentes y definen sus límites por alcance de tarea y profundidad de contexto

Resumen de componentes

• Los seis componentes están estrechamente conectados entre sí, y la calidad del diseño del harness determina la eficiencia con la que se aprovecha el modelo
• Un coding harness bien diseñado ofrece un entorno de apoyo al desarrollo mucho más continuo y consciente del contexto que un simple chat con LLM
• Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) es un ejemplo mínimo implementado en Python puro de esta estructura

Comparación con OpenClaw

• OpenClaw se parece más a una plataforma general de agentes que a un asistente dedicado exclusivamente a programación
• Puntos en común:
  • Uso de archivos de prompts e instrucciones dentro del workspace (AGENTS.md, TOOLS.md, etc.)
  • Incluye funciones de archivos de sesión JSONL, compresión de conversaciones y gestión de sesiones
  • Puede crear sesiones auxiliares y subagentes
• Diferencias:
  • Los agentes de programación están optimizados para explorar repositorios, editar código y ejecutar herramientas locales
  • OpenClaw se centra más en la operación de agentes de largo plazo entre múltiples canales y workspaces

Apéndice: anuncio de nuevo libro

• Ya terminó de escribir Build A Reasoning Model (From Scratch) y actualmente está disponible en versión de acceso anticipado (Early Access)
• La editorial está trabajando en el diseño con el objetivo de publicarlo en verano
• El libro se centra en un enfoque para comprender los mecanismos de razonamiento de los LLM implementándolos directamente

[GN⁺]

Comentarios en Hacker News

• Un context largo sigue siendo caro, y si hay demasiada información innecesaria se genera ruido
  Por eso creo que la generación basada en specs es mejor que la programación conversacional
  Ossature, que hice yo, toma el enfoque opuesto. Primero escribes una spec que describe el comportamiento; luego, antes de generar código, revisa faltantes o contradicciones y genera un build plan en TOML que especifica a qué secciones de la spec y a qué archivos hace referencia cada tarea
  El LLM solo ve las partes necesarias y no hay acumulación del historial de conversación. Todos los prompts y respuestas se guardan en disco, así que la trazabilidad queda asegurada automáticamente
  Últimamente, con este enfoque hice un emulador de CHIP-8 completamente a partir de specs, y también hay proyectos de ejemplo

  • Últimamente pienso mucho que a los agentes de programación les falta una fuente central de verdad
    Antes, todo el equipo sabía qué estaba construyendo, pero ahora el agente vuelve a empezar desde cero cada vez
    Por eso veo el flujo chat → spec → code como el futuro. La etapa spec → code debería funcionar sin intervención humana
    Si la especificación es ambigua, debería preguntarle claramente al humano y luego generar el código en base a eso
    Ahora mismo se repiten solicitudes ambiguas y el humano tampoco aprende por qué pasa eso. La “memory” o los archivos del agente no son más que parches temporales
  • Yo también estoy construyendo algo parecido. Aún no es público, pero es un motor de workflow centrado en specs
    En vez de conversación, le da al LLM un context proyectado del código y de la spec, y arma el context de forma distinta en cada etapa
    Así evita el drift causado por el context acumulado, y es mi código, no el LLM, el que controla el workflow
    Me pareció interesante la idea de usar TOML como artifact para pasar entre etapas, así que probablemente la tome como referencia
  • Pienso igual. El Agent A solo modifica la spec, y el Agent B compila viendo únicamente la spec
    El usuario solo tiene que revisar el diff que creó el Agent A, y se libera de la validación repetitiva del código
    La clave es preservar siempre la intención (intent). Hay que guardar la especificación y el contexto tal cual
    Costará 2 o 3 veces más, pero a largo plazo creo que será más eficiente
  • Los workflows basados en chat son agotadores y pierden mucha información
    Creo que un enfoque basado en specs es mucho mejor. Me da curiosidad cómo interviene la persona: si edita la spec y la auditoría en paralelo, cuál es la tasa de éxito al generar código y si planean aplicarlo también a código existente
  • Yo también intento empezar por la spec y luego mejorar iterativamente el código con la combinación Claude Code + Cucumber
    Me interesa saber en qué se diferencia Ossature de ese enfoque

• Sorprende que hayan logrado extraer el potencial del LLM solo con un state machine simple y un enfoque basado en bash

  • Por eso estoy creando mi propio agente de programación aislado
    Hoy el ecosistema de agentes está lleno de funciones excesivas y malas decisiones
    Hace 10 años se decía que herramientas así requerían responsabilidad, pero ahora estamos en una etapa confusa donde se mezclan el miedo y el hype
  • Al final, la clave es la ingeniería de prompt/context
    El modelo ya tiene el conocimiento, pero para llevarlo a acciones reales importa mucho cómo diseñas el context
    Parece prometedor traducir la solicitud del usuario al nivel de un desarrollador experimentado y conectar las herramientas necesarias
    Incluso los modelos open source pueden competir bastante bien con un agente bien optimizado y un poco de tuning
  • Si ves la filtración de Claude Code, queda claro que su estructura no es simple
    Hace falta un harness complejo, pero gracias a eso el LLM puede funcionar de forma determinista como herramienta
  • Muchos agentes CLI creen que simplemente dar acceso a bash no alcanza, así que están metiendo a la fuerza todo tipo de funciones en una JavaScript TUI
  • En vez de bash, usar Python me resultó más útil
    En lugar de pipelines, puedes armar libremente la lógica que quieras

• El ejemplo es conciso y claro
  No uso agentes de programación, pero este artículo ayuda a entender la esencia de los agentes de programación
  Muestra muy bien cómo incluso un código útil de apenas 1k LOC puede convertirse en un caos de 500k LOC

• Ya mucha gente está conectando modelos abiertos como GLM-5 a Claude Code o Codex CLI para usarlos
  La documentación oficial de GLM también lo recomienda

  • No está al nivel de Opus, pero la combinación de GLM y Qwen3.5-plus es más que suficiente para proyectos personales

• El artículo me impresionó. Yo hice un agente no orientado a programación basado en email, y el principio es parecido
  En cada ciclo de emails el context vuelve a empezar, así que el problema de acumulación de context se resuelve de forma natural
  Es importante equilibrar qué context poner en el prompt inicial y cuál separar como herramienta
  También hay que considerar el caching y el costo en tokens
  Lo detallé en una entrada de mi blog

• No me gusta la palabra “harness”. Me pregunto si no habrá una expresión mejor

  • Se usa mucho con el sentido de shim que administra un programa, como en “test harness” o “fuzzing harness”
  • Irónicamente, hoy todo se volvió “app”, pero justo a una app para ejecutar LLM no la llaman “app”
  • Al final, “harness” no es más que una forma elegante de decir scaffolding
  • Entonces también hubo respuestas diciendo que propusieran una palabra alternativa

• La tool output truncation es muy efectiva para reducir la inflación del context
  Yo armo el context sobre SQLite y, cuando hace falta, restauro llamadas de herramientas truncadas usando el ID del mensaje
  Los experimentos relacionados están resumidos en la documentación

• Ejecutar Claude Code con otros modelos es algo común
  También aparece en este documento de ejemplo
  Pero por mi experiencia, no llegan al nivel de los modelos de Anthropic

  • Según el proyecto, hasta con modelos baratos como MiMo V2 Pro se puede hacer entre 70% y 80%, pero en muchos casos Sonnet es muy superior
    Hay apenas como un 5% de casos donde Opus realmente vale lo que cuesta
    A mí OpenCode me parece muchísimo mejor que Claude Code, así que compré créditos de la API de OpenRouter
    OpenCode ya es suficientemente potente solo con comandos personalizados y definiciones simples de agentes
    Si defines el workflow con cosas como AGENTS.md o ROADMAP.md, alcanza para la mayoría de los proyectos
    Más que un harness complejo, creo que una estructura flexible responde mejor a los cambios de los modelos modernos
  • Me pregunto si los modelos de Anthropic son mejores simplemente por la calidad del modelo, o si también influye la optimización del harness

• El avance de los agentes de programación viene más de mejorar la estructura circundante (scaffolding) que del modelo en sí
  Cuando ya tienes herramientas, context del repositorio y una máquina de estados simple, el cuello de botella pasa a ser la calidad del context

• El artículo fue potente. Yo también suelo explicar los agentes de programación con la analogía del motor y el auto
  Si quieres experimentar con los componentes básicos, vale la pena mirar OpenHands software-agent-sdk