Los modelos de inteligencia artificial son cada vez mejores programando. Podemos pedir a ChatGPT, Claude, Gemini o cualquier otro modelo que escriba una función, encuentre un error o nos explique cómo implementar determinada característica.
Pero existe una diferencia importante entre generar código y trabajar como un programador sobre un proyecto real.
Para lo segundo necesitamos algo más que un buen modelo. Necesitamos darle acceso al proyecto, permitirle abrir archivos, modificarlos, ejecutar comandos, lanzar pruebas, consultar los errores y volver a intentarlo.
Ahí aparecen los coding harnesses.
¿Qué es un coding harness?
La palabra inglesa harness significa literalmente «arnés». En informática se utiliza desde hace tiempo para denominar una infraestructura que envuelve a otro sistema y permite controlarlo, ejecutarlo o comprobar su funcionamiento. Por ejemplo, existe el concepto de test harness para los entornos destinados a ejecutar pruebas.
Un coding harness es la infraestructura que rodea a un modelo de inteligencia artificial y le proporciona las herramientas y el entorno necesarios para trabajar sobre un proyecto de software.
Podemos simplificarlo así:
LLM + herramientas + entorno + contexto + bucle de ejecución = coding harness
El LLM sigue siendo el cerebro que razona. El harness proporciona, por decirlo de alguna manera, las manos, los ojos y el espacio de trabajo.
Un coding harness puede permitir al modelo:
- leer y modificar archivos;
- explorar un repositorio completo;
- utilizar una terminal;
- ejecutar programas;
- instalar dependencias;
- trabajar con Git;
- lanzar tests;
- consultar errores;
- compilar proyectos;
- utilizar herramientas externas;
- mantener contexto sobre lo que está haciendo;
- y repetir todo este proceso hasta alcanzar un resultado.
Esta última característica es especialmente importante.
Del «escribe este código» al «resuelve este problema»
Imaginemos que queremos añadir autenticación mediante Google a una aplicación.
En un chat convencional podríamos pedir:
Añade autenticación con Google a esta aplicación.
El modelo nos devolvería código e instrucciones. Nosotros tendríamos que localizar los archivos, copiar el código, instalar las dependencias, ejecutarlo y comprobar si funciona.
Con un coding harness el proceso puede ser muy diferente:
Analizar proyecto → localizar archivos relevantes → modificar código → instalar dependencias → ejecutar → detectar errores → corregir → ejecutar tests → revisar cambios.
Por tanto, cambia también la naturaleza de nuestras instrucciones.
Ya no tenemos necesariamente que decirle cómo programar algo. Podemos decirle qué resultado queremos conseguir.
Y dejar que el agente determine los pasos necesarios.
Modelo, agente y harness no son lo mismo
Aquí aparece una confusión habitual.
Un modelo es el sistema que razona y genera las respuestas: GPT, Claude, Gemini, etc.
Un agente utiliza ese modelo para perseguir un objetivo mediante diferentes acciones.
El harness es la infraestructura que permite al agente ejecutar esas acciones sobre un entorno real.
Simplificando mucho:
Modelo → piensa
Agente → decide qué hacer
Harness → permite hacerlo
Las fronteras entre estos conceptos no siempre son perfectamente claras porque muchas aplicaciones empaquetan las tres capas dentro del mismo producto.
Pero distinguirlas ayuda a entender por qué dos agentes que utilizan exactamente el mismo modelo pueden obtener resultados sorprendentemente diferentes.
El modelo importa, pero también importa muchísimo todo lo que ocurre alrededor del modelo.
¿Para qué sirve un coding harness?
Su aplicación más evidente es el desarrollo de software, pero dentro de esa categoría existen muchos usos.
Puede encargarse de implementar funcionalidades completas, corregir errores, refactorizar código, escribir tests, actualizar dependencias, analizar repositorios desconocidos, realizar migraciones, generar documentación técnica o investigar por qué una aplicación ha dejado de funcionar.
También resulta especialmente interesante para trabajos largos.
Podemos encargar una tarea relativamente compleja y permitir que el agente trabaje durante bastante tiempo realizando sucesivos ciclos de:
razonamiento → acción → comprobación → corrección.
Esto acerca bastante más la experiencia a delegar una tarea a otro desarrollador que a mantener una conversación con un chatbot.
Las ventajas
La primera ventaja es evidente: reduce muchísimo la intervención humana necesaria para ejecutar una tarea de programación.
No tenemos que copiar continuamente código entre el chat y nuestro editor.
Pero hay otras ventajas probablemente más importantes.
Conoce el proyecto
Un buen harness puede explorar el repositorio y comprender su estructura antes de modificar nada.
Esto permite que las soluciones tengan en cuenta el código existente en lugar de generar ejemplos aislados.
Puede comprobar su propio trabajo
Esta es posiblemente una de sus mayores ventajas.
Un LLM puede generar código que parece perfectamente correcto y, sin embargo, contener errores.
Si dispone de terminal y herramientas de ejecución puede comprobarlo:
escribir → ejecutar → observar → corregir.
El feedback del mundo real entra en el bucle.
Puede trabajar durante más tiempo
Las tareas complejas pueden dividirse en subtareas y ejecutarse progresivamente.
Algunos harnesses incorporan además mecanismos avanzados para gestionar el contexto, utilizar subagentes o delegar partes del problema.
Permite trabajar a un nivel de abstracción superior
En lugar de decir:
Abre
auth.php, modifica la función X y añade estas líneas.
podemos acercarnos a:
Implementa inicio de sesión mediante Google manteniendo el sistema actual de usuarios.
Estamos definiendo el objetivo, no necesariamente la implementación.
Los inconvenientes
Dar más autonomía a un agente también introduce nuevos problemas.
Puede equivocarse a mayor escala
Un chatbot que genera diez líneas incorrectas produce un problema pequeño.
Un agente con acceso a cientos de archivos puede realizar muchas modificaciones incorrectas antes de que nos demos cuenta.
Cuanta más autonomía concedemos, más importante resulta disponer de Git, tests, permisos adecuados y mecanismos de revisión.
Consume más recursos
Un agente autónomo puede realizar muchas llamadas al modelo durante una única tarea.
Analizar, ejecutar, comprobar y corregir repetidamente implica normalmente mayor consumo de tokens, tiempo y dinero que realizar una consulta puntual.
El contexto sigue siendo un problema
Los proyectos grandes contienen mucha más información de la que un modelo puede manejar simultáneamente.
Por eso una parte importante del diseño de los nuevos harnesses está precisamente en decidir qué información debe conocer el modelo en cada momento.
Gestionar bien el contexto puede ser casi tan importante como disponer de un modelo potente.
La autonomía necesita límites
No siempre queremos que una IA pueda ejecutar cualquier comando, modificar cualquier archivo o acceder a cualquier servicio.
Un buen harness necesita mecanismos de permisos, aislamiento y supervisión.
¿Por qué no utilizar simplemente ChatGPT, Claude o Gemini?
Porque el problema no es únicamente la capacidad de generar código.
Un modelo puede saber perfectamente cómo resolver un problema y, aun así, carecer de capacidad para hacerlo por sí mismo.
Necesita herramientas.
Es parecido a contratar a un excelente arquitecto y dejarlo encerrado en una habitación sin ordenador, planos, documentación ni posibilidad de visitar el edificio.
Puede saber qué habría que hacer.
Otra cosa es poder hacerlo.
El harness conecta la capacidad intelectual del modelo con un entorno de trabajo real.
¿Un coding harness está pensado para utilizarse solo?
Sí.
Muchos coding harnesses pueden utilizarse directamente como nuestra interfaz de programación.
Nosotros hablamos con el agente y este trabaja sobre el repositorio:
Usuario → Coding Agent/Harness → Proyecto
Esta arquitectura tiene mucho sentido cuando nuestra actividad principal es programar.
Herramientas como Claude Code, Codex CLI, OpenCode y otros agentes especializados se aproximan, con arquitecturas diferentes, a esta filosofía.
Pero existe otra posibilidad que me parece todavía más interesante.
El coding harness como especialista de otro agente
Supongamos que utilizamos un agente generalista como OpenClaw o Hermes.
Estos agentes pueden encargarse de muchas cosas diferentes: investigar información, utilizar servicios externos, ejecutar automatizaciones, gestionar información, comunicarse mediante Telegram y realizar multitud de tareas.
También pueden programar.
Pero que puedan hacerlo no significa necesariamente que deban ser nuestra mejor herramienta para cualquier tarea de programación.
Podemos construir una arquitectura diferente:
Usuario → Hermes/OpenClaw → Coding harness → Proyecto
En este escenario, Hermes u OpenClaw funcionan como orquestadores.
Cuando reciben una tarea general pueden resolverla directamente. Pero cuando detectan que el problema requiere trabajar seriamente sobre un repositorio pueden delegarlo a un agente especializado.
Por ejemplo:
Actualiza mi web para que los artículos relacionados aparezcan automáticamente al final de cada entrada.
El agente generalista puede interpretar la petición, identificar que requiere programación y delegarla al coding harness.
El harness recibe entonces una tarea mucho más concreta:
Analiza este repositorio, implementa artículos relacionados respetando la arquitectura existente, ejecuta las pruebas necesarias y devuelve los cambios realizados.
Cuando termina, devuelve el resultado al agente principal.
Tendríamos algo parecido a:
Usuario
↓
OpenClaw / Hermes
├── correo
├── investigación
├── automatizaciones
├── redes sociales
├── documentos
└── programación → Coding harness
Esta arquitectura convierte al coding harness en una especie de especialista dentro de un equipo de agentes.
¿Cuál de las dos arquitecturas es mejor?
Depende del uso.
Si prácticamente todo nuestro trabajo consiste en desarrollar software, utilizar directamente un coding harness probablemente sea lo más sencillo.
Pero si estamos construyendo un asistente personal o profesional capaz de realizar tareas muy diferentes, tiene bastante sentido utilizar un agente generalista como puerta de entrada y agentes especializados para determinadas actividades.
El usuario no tendría que decidir necesariamente qué herramienta utilizar.
Simplemente pediría:
Haz esto.
Y el agente principal decidiría cómo hacerlo y a quién delegarlo.
Es una arquitectura muy parecida a la de una empresa.
El director de una organización no necesita ser el mejor programador, abogado, contable o diseñador. Necesita saber qué especialista debe intervenir en cada problema y coordinar su trabajo.
Un ejemplo reciente: Prime Agent
Un proyecto interesante dentro de esta evolución es Prime Agent, desarrollado por Prime Intellect.
Se presenta como un agente orientado a coding workflows y tareas autónomas de larga duración, con especial atención a la gestión del contexto y al trabajo iterativo sobre problemas complejos.
Lo interesante de proyectos como Prime Agent no es únicamente preguntarnos si programan mejor o peor que determinado modelo.
La pregunta relevante empieza a ser:
¿Qué infraestructura necesita un modelo para trabajar de forma autónoma durante mucho tiempo sin perder el contexto ni desviarse del objetivo?
Ese es precisamente uno de los problemas que los nuevos harnesses intentan resolver.
Y probablemente veremos mucha evolución en este terreno.
El harness puede acabar siendo tan importante como el modelo
Durante los últimos años hemos comparado continuamente modelos:
GPT contra Claude. Gemini contra GPT. Un modelo nuevo contra el anterior.
Pero a medida que sus capacidades aumentan, otra capa empieza a adquirir mucha importancia: la infraestructura que construimos alrededor del modelo.
Qué herramientas tiene.
Cómo selecciona el contexto.
Cómo almacena información.
Cómo comprueba sus resultados.
Cómo divide los problemas.
Cómo utiliza otros agentes.
Qué permisos recibe.
Y cómo se recupera cuando algo sale mal.
Por eso es perfectamente posible que dos agentes utilizando el mismo modelo tengan rendimientos radicalmente diferentes.
La inteligencia ya no está únicamente en el modelo.
Parte de ella está en el sistema que construimos alrededor.
De asistentes a equipos de agentes
Los coding harnesses pueden parecer inicialmente herramientas exclusivamente destinadas a programadores.
Pero representan algo bastante más amplio.
Estamos pasando de utilizar la inteligencia artificial mediante una conversación:
persona → modelo → respuesta
a utilizar sistemas capaces de actuar:
persona → agente → herramientas → acciones → comprobación → resultado
Y el siguiente paso probablemente sea una estructura todavía más especializada:
persona → agente generalista → agentes especialistas → herramientas → mundo real
En esa arquitectura, un coding harness no tiene necesariamente que sustituir a OpenClaw, Hermes o cualquier otro agente generalista.
Puede convertirse simplemente en el programador del equipo.
Y quizá esa sea una forma más interesante de entender hacia dónde están evolucionando los agentes de inteligencia artificial.