Hay una confusión que se está volviendo especialmente frecuente a medida que proliferan las herramientas de programación asistida por inteligencia artificial.

Un usuario prueba una plataforma como Verdent, Cursor, Cline o Codex. Selecciona un determinado modelo —por ejemplo, un GPT de OpenAI— y obtiene unos resultados extraordinarios.

La conclusión parece lógica:

«Si esta herramienta utiliza GPT y funciona así de bien, cualquier otra herramienta que utilice ese mismo GPT debería funcionar aproximadamente igual».

Pero no.

Y entender por qué no es así permite comprender una de las transformaciones más importantes que está viviendo actualmente la inteligencia artificial.

La cuestión esencial es esta:

El modelo de inteligencia artificial y el agente que lo utiliza son dos cosas diferentes.

El modelo importa muchísimo. Pero alrededor del modelo existe toda una infraestructura que determina qué información recibe, qué puede hacer, cuándo puede hacerlo, cómo comprueba lo que ha hecho y qué sucede después de cada acción.

Esa infraestructura suele denominarse agent harness, agentic harness, scaffolding, runtime agentic u, ocasionalmente, simplemente orquestación del agente.

Y puede marcar una diferencia enorme.

De hecho, dos herramientas pueden utilizar exactamente la misma familia de modelos y producir experiencias radicalmente distintas.

El error de pensar que «la IA» es solamente el modelo

Durante los primeros años de la IA generativa era bastante razonable identificar el producto con el modelo.

Escribíamos una pregunta.

El modelo recibía el texto.

El modelo generaba una respuesta.

Fin.

El esquema era aproximadamente:

Usuario → Modelo → Respuesta

En ese escenario, comparar modelos tenía muchísimo sentido.

GPT frente a Claude.

Una versión de GPT frente a otra.

Un modelo pequeño frente a uno grande.

Pero los agentes modernos funcionan de una manera muy diferente.

Cuando pedimos a un agente de programación:

«Añade autenticación mediante Google a esta aplicación, adapta la base de datos, actualiza el frontend y asegúrate de que los tests siguen pasando».

el modelo normalmente no recibe simplemente esa frase y devuelve varios archivos terminados.

Entre nuestra petición y el resultado final puede haber decenas o incluso centenares de operaciones.

El sistema puede:

  1. inspeccionar la estructura del repositorio;

  2. buscar determinados archivos;

  3. leer configuraciones;

  4. localizar cómo funciona actualmente la autenticación;

  5. identificar las dependencias utilizadas;

  6. consultar documentación;

  7. diseñar una estrategia;

  8. modificar varios archivos;

  9. ejecutar comandos;

  10. instalar una dependencia;

  11. arrancar la aplicación;

  12. ejecutar los tests;

  13. detectar un error;

  14. volver a inspeccionar el código;

  15. corregirlo;

  16. ejecutar nuevamente los tests;

  17. comprobar tipos;

  18. revisar el git diff;

  19. detectar una modificación innecesaria;

  20. corregirla;

  21. y solo entonces informar al usuario.

El modelo es fundamental durante todo ese proceso.

Pero el modelo no es todo ese proceso.

Modelo, agente y harness: tres conceptos que conviene separar

Podemos empezar con tres definiciones.

1. El modelo

El modelo es el sistema de inteligencia artificial propiamente dicho.

GPT, Claude o Gemini son familias de modelos.

Simplificando muchísimo, podríamos considerar al modelo como el componente capaz de:

  • interpretar lenguaje;

  • comprender código;

  • razonar;

  • generar texto;

  • generar código;

  • decidir entre alternativas;

  • y, si ha sido preparado para ello, solicitar la ejecución de determinadas herramientas.

Es el motor cognitivo del sistema.

Pero por sí solo no tiene por qué saber qué archivos existen en nuestro ordenador, ni poder modificar una base de datos, ni ejecutar npm test, ni observar el resultado visual de una página web.

Para eso necesita algo más.

2. Las herramientas

Un agente puede recibir acceso a determinadas tools o herramientas.

Por ejemplo:

  • leer un archivo;

  • escribir un archivo;

  • buscar texto dentro del repositorio;

  • listar directorios;

  • ejecutar un comando en terminal;

  • consultar Git;

  • navegar por Internet;

  • controlar un navegador;

  • consultar una base de datos;

  • llamar una API;

  • acceder a GitHub;

  • utilizar herramientas proporcionadas mediante MCP;

  • obtener logs;

  • ejecutar tests.

El modelo puede decidir:

«Necesito ver package.json».

Pero hace falta una infraestructura que convierta esa intención en una operación real, lea el archivo y devuelva su contenido al modelo.

Después el modelo podría pensar:

«Aquí utilizan Laravel Sanctum. Necesito inspeccionar las rutas».

Otra herramienta recuperará las rutas.

El resultado regresará al modelo.

Y continuará el proceso.

Ahí empieza realmente el comportamiento agéntico.

3. El agent harness

El término harness es difícil de traducir elegantemente al castellano.

Literalmente puede significar arnés, aunque aquí resulta mucho más útil entenderlo como:

la infraestructura que envuelve al modelo y permite convertirlo en un agente operativo.

Cursor, de hecho, describe actualmente un coding agent mediante tres elementos:

  1. instrucciones;

  2. herramientas;

  3. modelo.

Y señala que su agente orquesta esos elementos y adapta instrucciones y herramientas a los diferentes modelos que soporta.

OpenAI utiliza explícitamente el término harness al explicar Codex y describe su agent loop como la lógica encargada de orquestar la interacción entre el usuario, el modelo y las herramientas.

Por tanto, ya podemos sustituir nuestro antiguo esquema:

Usuario → Modelo → Respuesta

por algo bastante más parecido a esto:

Usuario → Harness → Modelo → Herramientas → Resultado → Modelo → Nuevas herramientas → Verificación → Modelo → … → Resultado final

Y esos puntos suspensivos son precisamente donde sucede buena parte de la magia.

Una analogía: el modelo es el motor, no el automóvil

Una forma sencilla de entenderlo es imaginar un motor.

Supongamos que tenemos exactamente el mismo motor.

Lo instalamos primero en un automóvil con:

  • una mala transmisión;

  • neumáticos deficientes;

  • una electrónica rudimentaria;

  • una suspensión mediocre;

  • refrigeración insuficiente.

Después instalamos ese mismo motor en otro automóvil con:

  • transmisión perfectamente ajustada;

  • control electrónico sofisticado;

  • excelentes neumáticos;

  • aerodinámica optimizada;

  • suspensión avanzada;

  • telemetría en tiempo real.

¿Son iguales porque llevan el mismo motor?

Evidentemente no.

El motor seguirá condicionando enormemente las prestaciones máximas.

Pero el automóvil es un sistema.

Con los agentes ocurre exactamente lo mismo.

El modelo puede ser extraordinariamente inteligente y, sin embargo, encontrarse dentro de un sistema que le proporciona poco contexto, malas herramientas o una estrategia deficiente.

También puede ocurrir lo contrario: un magnífico harness puede conseguir que un modelo determinado rinda extraordinariamente bien porque le presenta los problemas adecuados, en el momento adecuado y con las herramientas adecuadas.

Por eso una comparación del tipo:

«Los dos utilizan GPT»

nos dice bastante menos de lo que parece.

¿Qué contiene realmente un buen agent harness?

Aquí aparece la parte interesante.

No existe un único diseño universal, pero un agente moderno puede incluir muchas capas distintas.

Podemos representarlo conceptualmente así:

Resultado = Modelo + Contexto + Herramientas + Orquestación + Memoria + Entorno + Verificación + Permisos + UX

No es una fórmula matemática real, naturalmente.

Pero sí una excelente manera de pensar sobre estos sistemas.

Veamos cada elemento.

1. Las instrucciones invisibles: el system prompt

Cuando escribimos:

«Corrige este error».

no somos necesariamente los únicos que estamos hablando con el modelo.

La plataforma puede haber colocado antes unas instrucciones internas muy extensas.

Es el denominado system prompt o conjunto de instrucciones del sistema.

Puede decirle cosas como:

  • inspecciona el repositorio antes de modificarlo;

  • no asumas que conoces la arquitectura;

  • busca primero las instrucciones del proyecto;

  • ejecuta tests después de cada modificación relevante;

  • no cambies APIs públicas innecesariamente;

  • utiliza determinadas herramientas para búsquedas;

  • no finalices mientras haya comandos pendientes;

  • revisa el estado de Git;

  • verifica el resultado antes de responder.

OpenAI publicó, por ejemplo, instrucciones utilizadas por una versión inicial de Codex donde aparecían explícitamente comportamientos relacionados con Git, ejecución de tests y comprobación de resultados.

Por tanto:

tu prompt no es necesariamente el prompt completo que recibe el modelo.

La calidad de esas instrucciones internas puede cambiar mucho el comportamiento.

2. Context engineering: decidir qué debe saber el modelo

Uno de los grandes errores consiste en pensar que cuanto más contexto introduzcamos, mejor.

No necesariamente.

Un repositorio puede contener:

  • 500 archivos;

  • 5.000 archivos;

  • 50.000 archivos;

  • documentación;

  • dependencias;

  • binarios;

  • código generado;

  • logs;

  • tests;

  • configuraciones.

Introducirlo indiscriminadamente dentro del contexto del modelo sería caro, lento y posiblemente contraproducente.

El trabajo realmente sofisticado consiste en determinar:

¿Qué necesita saber el modelo ahora?

Eso es context engineering.

Anthropic lo define precisamente como el problema de configurar el conjunto de información disponible para que el modelo produzca el comportamiento deseado, tratando el contexto como un recurso limitado que hay que administrar cuidadosamente.

Un buen agente puede comenzar viendo únicamente la estructura del proyecto.

Después buscar:

authentication

Encontrar cuatro archivos relevantes.

Leer dos.

Descubrir una referencia a otro servicio.

Leer ese servicio.

Consultar el esquema de base de datos.

Y construir progresivamente una imagen mental del sistema.

Eso es muy diferente de decir al modelo:

«Aquí tienes 200.000 tokens de código. Arréglalo».

3. Exploración del repositorio

Un buen agente necesita saber cómo investigar antes de actuar.

Esto parece trivial, pero no lo es.

Ante un bug, una estrategia podría ser:

Buscar el texto del error.

Otra:

Buscar la función relacionada.

Otra:

Analizar primero el flujo completo que produce el error.

Otra:

Ejecutar el programa y reproducirlo antes de tocar nada.

La elección importa.

Aquí la calidad del modelo interviene, por supuesto, pero también las herramientas que el harness pone a su disposición y las instrucciones que recibe para utilizarlas.

Cursor documenta herramientas para:

  • buscar archivos;

  • leerlos;

  • buscar dentro del código;

  • editar;

  • ejecutar comandos;

  • navegar por Internet;

  • controlar un navegador.

Cline expone igualmente operaciones para lectura y escritura de archivos, búsquedas, ejecución en terminal, navegador y herramientas MCP.

Un modelo sin esas capacidades podría explicar cómo arreglar un programa.

Un modelo con ellas puede intentar arreglarlo realmente.

4. El agent loop: observar, pensar, actuar, volver a observar

Esta es probablemente la diferencia conceptual más importante entre un chatbot y un agente.

Un chatbot tradicional hace aproximadamente esto:

Pregunta → razonamiento → respuesta

Un agente trabaja mediante un bucle:

Objetivo

↓

Observar

↓

Decidir

↓

Actuar

↓

Observar el resultado

↓

Decidir nuevamente

↓

Actuar nuevamente

↓

Verificar

↓

Continuar o finalizar

OpenAI denomina precisamente agent loop a esta lógica central dentro de Codex.

Esto introduce una propiedad importantísima:

El agente puede aprender de las consecuencias de sus propias acciones.

Por ejemplo:

Modelo: «Creo que debo cambiar esta función».

Harness: modifica el archivo.

Modelo: «Ejecuta los tests».

Harness: ejecuta npm test.

Terminal:

3 tests failed

Modelo: interpreta los errores.

Modelo: «Mi modificación ha roto esta dependencia. Debo cambiar el enfoque».

Harness: modifica nuevamente el código.

Modelo: «Repite los tests».

Terminal:

126 tests passed

Eso es fundamentalmente diferente de pedir una respuesta única a un LLM.

5. La capacidad de verificar

Este punto está enormemente infravalorado.

Un modelo puede escribir código excelente.

Pero escribir código que parezca correcto y demostrar que funciona realmente son cosas diferentes.

Los mejores sistemas agénticos intentan cerrar ese espacio.

Pueden ejecutar:

  • tests unitarios;

  • tests de integración;

  • compiladores;

  • linters;

  • comprobación de tipos;

  • builds;

  • consultas HTTP;

  • inspección de logs;

  • pruebas visuales;

  • navegadores.

Cursor, por ejemplo, documenta que su Agent puede ejecutar comandos y utilizar el navegador para comprobar cambios visuales.

OpenAI explica igualmente que Codex puede leer y modificar archivos y ejecutar tests, linters y type checkers, proporcionando además evidencias verificables de determinadas acciones.

La diferencia puede ser enorme.

Agente A

Escribe código.

Dice:

«Listo. He solucionado el problema».

Agente B

Escribe código.

Ejecuta tests.

Falla.

Corrige.

Ejecuta tests.

Pasan.

Ejecuta el linter.

Aparece otro problema.

Corrige.

Compila.

Arranca la aplicación.

Comprueba el resultado.

Dice:

«Listo».

Los dos pueden estar utilizando el mismo modelo.

Pero solamente uno de los dos ha construido un proceso capaz de cerrar el bucle de verificación.

6. La gestión de errores

El verdadero comportamiento de un agente aparece muchas veces cuando algo sale mal.

Imaginemos:

npm run build

devuelve un error.

¿Qué ocurre entonces?

Un harness rudimentario podría simplemente mostrar el error al usuario.

Uno más sofisticado puede:

  1. capturar la salida;

  2. decidir qué parte es relevante;

  3. introducirla nuevamente en contexto;

  4. pedir al modelo que la interprete;

  5. localizar los archivos relacionados;

  6. modificar el código;

  7. repetir el comando.

Es decir:

error → información → razonamiento → corrección → nueva prueba

El fracaso deja de ser necesariamente el final de la ejecución.

Pasa a convertirse en otra observación dentro del bucle.

7. Memoria y estado

Otra cuestión compleja es decidir qué debe recordar el agente.

Durante una tarea extensa pueden acumularse enormes cantidades de información:

  • conversación;

  • contenido de archivos;

  • resultados de búsquedas;

  • salidas de terminal;

  • documentación;

  • decisiones anteriores;

  • errores;

  • planes;

  • diffs.

Pero el contexto del modelo no es infinito.

Los sistemas necesitan decidir qué conservar, qué resumir y qué descartar.

Cline, por ejemplo, dispone actualmente de mecanismos para iniciar una nueva tarea llevando consigo un contexto resumido de la anterior y también de comandos orientados a comprimir el historial preservando la información relevante.

Esto puede parecer un detalle interno.

No lo es.

En trabajos largos puede ser la diferencia entre que el agente siga recordando:

«No podemos modificar esta API porque la consume la aplicación móvil».

o que esa restricción desaparezca silenciosamente de su contexto veinte minutos después.

8. Planificar antes de ejecutar

Algunos agentes diferencian entre pensar y hacer.

Cline dispone de modos Plan y Act: en el primero puede explorar y diseñar una estrategia sin modificar archivos, mientras que en el segundo ejecuta la solución conservando el contexto de la planificación.

Verdent documenta igualmente modos separados de planificación y ejecución.

Cursor ofrece también modos orientados a planificación además de su Agent.

¿Por qué puede ayudar?

Porque muchos errores de programación asistida por IA no son errores de sintaxis.

Son errores de estrategia.

El modelo empieza a modificar código demasiado pronto sin haber comprendido:

  • la arquitectura;

  • las dependencias;

  • los efectos laterales;

  • los requisitos implícitos.

Un harness que induzca deliberadamente una fase previa de comprensión puede obtener resultados muy diferentes utilizando exactamente el mismo modelo.

9. Permisos, sandbox y grados de autonomía

Un agente solamente puede hacer aquello que el entorno le permite.

Podemos darle:

  • acceso exclusivamente de lectura;

  • permiso para editar el repositorio;

  • terminal restringida;

  • terminal completa;

  • Internet;

  • navegador;

  • APIs externas;

  • GitHub;

  • servidores MCP;

  • credenciales;

  • acceso a infraestructura.

Cuanto mayor sea su capacidad de actuación, mayor puede ser su autonomía.

Pero también aumenta el riesgo.

Por eso el diseño de los permisos forma parte del producto.

Cursor, por ejemplo, incorpora diferentes controles sobre la ejecución de comandos y entornos restringidos.

Cline permite configurar grados de aprobación automática y advierte expresamente de los riesgos de conceder autonomía absoluta sobre archivos, comandos, navegador y herramientas externas.

Codex incorpora igualmente controles relativos a aislamiento, permisos, acceso de red y aprobación de acciones.

Por tanto, incluso la sensación subjetiva de que:

«Esta herramienta me da mucha menos lata».

puede depender parcialmente de cómo esté diseñado su sistema de permisos y aprobaciones.

10. El entorno de ejecución

Supongamos que el modelo ha escrito una solución perfecta.

Ahora necesita comprobarla.

¿Tiene Node instalado?

¿PHP?

¿Python?

¿Docker?

¿Las dependencias?

¿Las variables de entorno?

¿Una copia de la base de datos?

¿Puede arrancar el proyecto?

El entorno alrededor del agente resulta crucial.

OpenAI señala, por ejemplo, la importancia de proporcionar a Codex entornos de desarrollo configurados, documentación y sistemas de tests fiables.

Esto conduce a una conclusión muy interesante:

Para que un agente programe bien, no basta con mejorar la IA.

También debemos hacer que nuestro software sea comprensible y verificable por la IA.

Buenos tests.

Buenos comandos.

Documentación clara.

Logs útiles.

Arquitectura legible.

Entornos reproducibles.

Todo ello aumenta las capacidades prácticas del agente.

11. Los subagentes

Y todavía podemos añadir otra capa.

¿Por qué utilizar un único agente?

Un sistema puede tener un agente principal que delegue tareas.

Por ejemplo:

Orquestador

→ Agente explorador
→ Agente programador
→ Agente de seguridad
→ Agente revisor
→ Agente verificador

Cada uno puede trabajar con un contexto diferente.

Verdent documenta precisamente una arquitectura con un agente principal que analiza peticiones y distribuye trabajo entre subagentes especializados, incluyendo ejecución paralela y aislamiento de contextos.

Codex también está evolucionando hacia flujos multiagente con entornos y worktrees independientes.

Aquí el problema ya deja de parecerse a «hablar con ChatGPT».

Empieza a parecerse mucho más a dirigir un pequeño equipo digital.

Veamos ahora dos agentes utilizando hipotéticamente el mismo modelo

Supongamos que ambos utilizan exactamente el mismo GPT.

Les damos esta tarea:

«Los usuarios están cerrando sesión aleatoriamente. Averigua qué ocurre y soluciónalo sin romper las sesiones existentes».

Herramienta A: envoltorio sencillo

Envía al modelo:

  • nuestro prompt;

  • el archivo actualmente abierto;

  • quizá algunos archivos relacionados.

El modelo analiza el código y responde:

«El problema parece estar en la expiración del token».

Modifica dos funciones.

Fin.

Tiempo empleado: poco.

Resultado aparentemente convincente.

Pero no ha comprobado realmente la hipótesis.

Herramienta B: harness agéntico sofisticado

Recibe exactamente la misma petición.

Primero inspecciona el repositorio.

Encuentra:

  • backend;

  • frontend;

  • middleware de autenticación;

  • Redis;

  • tests;

  • configuración de sesiones.

Busca dónde se generan los tokens.

Después localiza dónde se validan.

Lee la configuración de Redis.

Encuentra una discrepancia entre:

  • duración del token;

  • duración de la sesión almacenada.

Antes de modificar nada ejecuta los tests actuales.

Todos pasan.

Modifica la configuración.

Añade un test que reproduce el problema.

Ejecuta los tests.

Uno falla.

Analiza por qué.

Descubre que existe además un proceso que renueva tokens pero no extiende correctamente el TTL de Redis.

Modifica ese proceso.

Ejecuta nuevamente los tests.

Todos pasan.

Ejecuta el linter.

Pasa.

Revisa el diff.

Comprueba que no haya modificaciones ajenas al problema.

Finalmente explica:

  • qué causaba el bug;

  • qué archivos ha modificado;

  • por qué;

  • qué pruebas ha realizado.

¿Qué modelo era mejor?

Ninguno.

Era el mismo.

Lo diferente era el sistema que había alrededor.

Y eso cambia por completo nuestra manera de evaluar las herramientas de IA.

Incluso «el mismo modelo» puede no significar exactamente lo mismo

Hay todavía otro problema.

Cuando dos plataformas muestran en un selector algo aparentemente idéntico:

GPT-X

eso tampoco garantiza necesariamente una ejecución idéntica.

Hay muchas variables adicionales.

Entre ellas:

La versión concreta del modelo

Los proveedores pueden actualizar modelos o utilizar snapshots diferentes.

El reasoning effort

Algunos sistemas permiten variar cuánto razonamiento dedicar a cada tarea.

Cline, por ejemplo, expone actualmente distintos niveles de reasoning effort en su CLI.

Las instrucciones del sistema

Como hemos visto, pueden ser radicalmente distintas.

Las herramientas

Un agente puede disponer de veinte herramientas y otro solamente de cinco.

La definición de esas herramientas

Incluso ofreciendo aparentemente la misma herramienta —por ejemplo, «buscar código»— su implementación puede ser completamente diferente.

El contexto suministrado

Un producto puede haber descubierto automáticamente diez archivos relevantes.

Otro quizá haya enviado solamente el archivo abierto.

La política de compactación

Cuando el contexto comienza a llenarse, una plataforma puede resumir inteligentemente la sesión y otra eliminar información distinta.

El número máximo de iteraciones

Un sistema puede permitir al agente continuar investigando.

Otro puede cortarlo después de determinadas llamadas.

Los límites económicos

Cada llamada al modelo cuesta recursos.

Una plataforma puede decidir utilizar veinte interacciones para resolver un problema mientras otra intenta hacerlo en cuatro.

Los permisos

Un agente puede ejecutar tests automáticamente.

Otro necesita detenerse y pedir autorización.

La latencia

Algunos sistemas pueden utilizar modelos distintos para determinadas operaciones internas o ejecutar trabajo en paralelo.

Es decir:

La etiqueta del modelo identifica una pieza importantísima del sistema, pero no describe el sistema completo.

Esto explica algunas experiencias aparentemente contradictorias

A veces ocurre algo desconcertante.

Probamos un modelo dentro de una herramienta y pensamos:

«Es espectacular».

Después utilizamos supuestamente el mismo modelo dentro de otra y pensamos:

«No parece ni la misma IA».

Probablemente no nos lo estamos imaginando.

Puede estar ocurriendo exactamente eso.

El modelo base puede ser similar, pero una plataforma:

  • ha encontrado mejor contexto;

  • dispone de mejores herramientas;

  • ejecuta más verificaciones;

  • utiliza instrucciones mejor adaptadas;

  • sabe cuándo continuar;

  • sabe cuándo detenerse;

  • administra mejor los errores;

  • conserva mejor el estado;

  • o simplemente interrumpe menos al usuario.

La experiencia resultante puede ser completamente distinta.

Cursor es especialmente explícito sobre esta cuestión

Resulta interesante que la propia documentación de Cursor formule actualmente esta distinción de manera bastante directa.

Describe un coding agent mediante:

modelo + tools + harness

y afirma que la calidad final depende de esos elementos y del contexto disponible. También señala que adapta su harness a los distintos modelos que soporta.

La implicación es enorme.

Supongamos:

GPT dentro de Cursor

y:

el mismo GPT dentro de otra plataforma

No estamos ejecutando necesariamente el mismo sistema.

Estamos utilizando:

GPT + harness de Cursor

frente a:

GPT + harness de la otra plataforma

Eso es exactamente lo que debemos comparar.

Codex tampoco es simplemente «GPT programando»

La misma idea aparece todavía más claramente en la descripción técnica de Codex.

OpenAI diferencia expresamente el modelo del Codex harness y describe el agent loop que gestiona las interacciones entre:

  • instrucciones;

  • modelo;

  • herramientas;

  • entradas;

  • resultados de las herramientas.

Además, el Codex actual incorpora elementos como:

  • terminal;

  • edición de archivos;

  • búsqueda web;

  • MCP;

  • diferentes políticas de aprobación;

  • Skills;

  • entornos aislados;

  • worktrees;

  • flujos multiagente.

Por tanto, utilizar un modelo GPT directamente mediante API y utilizar Codex no son experimentos equivalentes.

El modelo puede pertenecer a la misma familia.

El sistema completo no.

Cline ofrece un ejemplo todavía más revelador

Cline permite utilizar modelos de distintos proveedores, incluyendo OpenAI, Anthropic, Google y otros.

Esto hace especialmente visible la separación entre ambas capas:

Cline = harness

mientras que:

GPT / Claude / Gemini = modelos intercambiables dentro de ese harness.

De hecho, su SDK describe explícitamente componentes separados para el agent harness, el agent loop y la pasarela hacia los diferentes LLM.

Además añade capacidades propias del sistema, como:

  • Plan/Act;

  • ejecución de herramientas;

  • terminal;

  • navegador;

  • MCP;

  • gestión del contexto;

  • checkpoints.

Los checkpoints son un magnífico ejemplo de algo que no pertenece al modelo: Cline puede guardar estados del proyecto después de las acciones y permitir volver atrás sin perder necesariamente la conversación.

GPT no hace eso.

Cline alrededor de GPT sí puede hacerlo.

Y Verdent introduce además la orquestación multiagente

Verdent resulta interesante porque documenta explícitamente una arquitectura donde un agente principal puede dividir trabajo, delegarlo en subagentes y mantener contextos separados.

Además utiliza workspaces aislados para ejecutar trabajo en paralelo.

De nuevo:

esa capacidad no procede exclusivamente de que debajo exista GPT, Claude o Gemini.

Es una propiedad de la arquitectura del producto.

El modelo razona.

El harness organiza el trabajo.

¿Puede entonces un modelo «peor» superar a otro mejor?

Sí.

Con una precisión importante.

Puede superarlo dentro de una tarea y un sistema concretos.

Imaginemos:

Sistema A

Modelo extraordinario.

Pero:

  • poco contexto;

  • búsqueda mediocre;

  • sin tests automáticos;

  • pocas iteraciones;

  • herramientas limitadas.

Sistema B

Modelo ligeramente inferior.

Pero:

  • excelente exploración del repositorio;

  • contexto cuidadosamente seleccionado;

  • terminal;

  • tests;

  • navegador;

  • buenas instrucciones;

  • bucle de reparación;

  • verificación final.

En determinados trabajos, el segundo sistema puede perfectamente producir mejores resultados.

Esto no significa que el modelo sea irrelevante.

Todo lo contrario.

Un modelo superior puede:

  • comprender mejor arquitecturas complejas;

  • razonar durante más pasos;

  • cometer menos errores;

  • utilizar mejor las herramientas;

  • interpretar mejor los resultados;

  • escribir mejor código.

Pero el rendimiento real será algo parecido a:

capacidad del modelo × calidad del sistema que consigue explotarla

Otra vez: no es una ecuación matemática.

Pero representa bastante bien el problema.

Un Ferrari sin carretera no gana ninguna carrera

Podemos llevar la analogía todavía un poco más lejos.

Los benchmarks tradicionales intentan medir fundamentalmente la capacidad del modelo.

Eso sigue siendo útil.

Pero en el mundo agéntico estamos empezando a medir otra cosa:

¿Qué consigue hacer el sistema completo en condiciones reales?

Y ahí importa tanto el cerebro como la infraestructura.

Un modelo extremadamente potente dentro de un harness deficiente puede desperdiciar gran parte de su capacidad.

Un buen harness intenta que el modelo:

  • vea aquello que necesita ver;

  • pueda hacer aquello que necesita hacer;

  • reciba feedback de sus acciones;

  • y disponga de oportunidades para corregirse.

La verificación puede ser incluso más importante que generar el código correcto a la primera

Esto conduce a una idea contraintuitiva.

Quizá el mejor agente no sea necesariamente aquel que se equivoca menos al primer intento.

Puede ser aquel que detecta y corrige mejor sus propios errores.

Supongamos:

Agente A

Genera código correcto el 85 % de las veces.

No verifica.

Agente B

Genera código correcto inicialmente el 75 % de las veces.

Pero ejecuta tests, inspecciona errores y corrige con gran eficacia.

Si ese segundo proceso eleva el resultado final al 95 %, tendremos un sistema más fiable aunque su primera propuesta fuese peor.

La autonomía no consiste solamente en acertar.

Consiste también en:

observar, detectar, corregir y volver a intentar.

El harness también determina cuánto nos molesta el agente

Hay además una dimensión aparentemente trivial pero decisiva en productividad: la fricción.

Un agente puede interrumpir continuamente:

«¿Puedo leer este archivo?»

«¿Puedo ejecutar este comando?»

«¿Quieres que continúe?»

«¿Puedo modificar este otro archivo?»

Otro puede entender una política de permisos, operar durante diez minutos y volver diciendo:

«He encontrado el problema, lo he corregido y los 184 tests pasan».

Desde el punto de vista del usuario, la diferencia es brutal.

No necesariamente porque el segundo modelo sea más inteligente.

Puede que simplemente tenga:

  • mejores políticas de permisos;

  • mejor sandbox;

  • mejor clasificación del riesgo;

  • más autonomía;

  • mejor bucle de ejecución.

Este aspecto es importantísimo porque los agentes compiten también por algo muy escaso:

nuestra atención.

Un agente excelente no solamente produce buen código.

Necesita poca supervisión para producirlo.

De copiloto a trabajador digital

Todo esto ayuda también a entender la evolución que estamos viviendo.

La primera generación de herramientas de IA para programar era fundamentalmente:

autocomplete inteligente.

Después apareció:

chat sobre código.

Más tarde:

chat capaz de editar archivos.

Después:

agentes capaces de usar herramientas.

Y ahora estamos entrando en:

sistemas capaces de planificar, ejecutar, verificar, delegar y trabajar en paralelo.

El cambio conceptual es enorme.

Ya no preguntamos solamente:

«¿Qué código generaría esta IA?»

La pregunta empieza a ser:

«¿Qué trabajo completo puedo delegar a este sistema?»

Esto cambia también cómo debemos comparar Verdent, Codex, Cursor o Cline

Preguntar:

«¿Qué modelo utiliza?»

sigue siendo relevante.

Pero es solamente la primera pregunta.

Una evaluación seria debería preguntar también:

¿Cómo descubre el contexto?

¿Carga archivos completos?

¿Busca dinámicamente?

¿Indexa el repositorio?

¿Entiende dependencias?

¿Qué herramientas puede utilizar?

¿Terminal?

¿Git?

¿Navegador?

¿Internet?

¿MCP?

¿APIs?

¿Cómo administra el contexto?

¿Resume?

¿Compacta?

¿Crea tareas nuevas?

¿Aísla contextos?

¿Cómo verifica su trabajo?

¿Ejecuta tests?

¿Compila?

¿Usa navegador?

¿Analiza logs?

¿Qué autonomía tiene?

¿Cuándo necesita aprobación?

¿Qué puede hacer automáticamente?

¿Cómo maneja los errores?

¿Se detiene?

¿O investiga y vuelve a intentarlo?

¿Puede dividir trabajo?

¿Tiene subagentes?

¿Ejecución paralela?

¿Worktrees?

¿Conserva estado?

¿Tiene checkpoints?

¿Memoria?

¿Historial reutilizable?

¿Puede adaptarse al proyecto?

¿Reglas?

¿AGENTS.md?

¿Skills?

¿Prompts personalizados?

¿Cuánta supervisión humana requiere?

Esta última métrica puede acabar siendo una de las más importantes de todas.

Entonces, ¿cómo deberíamos hacer un benchmark real?

Supongamos que queremos comparar:

  • Verdent + GPT;

  • Codex;

  • Cursor + GPT;

  • Cline + GPT.

Hay dos experimentos diferentes que podríamos realizar.

Experimento 1: comparar modelos

Intentaríamos aislar al máximo el modelo.

Mismo prompt.

Mismo contexto.

Mismas herramientas.

Mismos límites.

Mismo reasoning effort.

Eso permite estudiar qué modelo razona mejor.

Pero no es necesariamente el experimento que más interesa al usuario final.

Experimento 2: comparar agentes

Aquí hacemos exactamente lo contrario.

Damos a todos:

  • el mismo repositorio;

  • el mismo objetivo;

  • el mismo punto inicial.

Y dejamos que cada producto utilice todo su arsenal.

Después medimos:

  • resultado correcto o incorrecto;

  • tiempo;

  • número de intervenciones humanas;

  • tests superados;

  • regresiones;

  • calidad del código;

  • capacidad para identificar el problema;

  • número de intentos;

  • coste;

  • cantidad de supervisión necesaria.

Eso ya no mide solamente GPT.

Mide:

GPT + harness + herramientas + contexto + orquestación + entorno.

Y para decidir con qué herramienta queremos trabajar cada día, probablemente sea esta segunda prueba la que más nos interesa.

El mejor modelo no implica automáticamente el mejor agente

Esta será probablemente una de las grandes fuentes de confusión durante los próximos años.

Podremos ver situaciones aparentemente paradójicas:

  • un modelo gana benchmarks pero rinde peor dentro de determinada herramienta;

  • el mismo modelo resulta fantástico en una plataforma y mediocre en otra;

  • un modelo más barato consigue resultados equivalentes gracias a una mejor orquestación;

  • una actualización del harness mejora enormemente un producto sin cambiar el modelo;

  • una actualización del modelo empeora temporalmente el comportamiento de un agente porque su harness todavía no está optimizado para él.

Nada de esto sería sorprendente.

Porque estamos dejando de consumir modelos aislados.

Estamos empezando a consumir sistemas construidos alrededor de modelos.

Y esta idea va mucho más allá de programar

Aunque los coding agents permiten verlo con especial claridad, el principio se aplica prácticamente a cualquier agente empresarial.

Un futuro agente financiero podría disponer de:

  • un GPT;

  • acceso al ERP;

  • ContaSOL;

  • bancos;

  • facturas;

  • AEAT;

  • reglas fiscales;

  • memoria empresarial;

  • calendario;

  • herramientas de cálculo;

  • procedimientos de verificación.

Otro podría utilizar exactamente el mismo GPT pero disponer solamente de:

  • una ventana de chat;

  • algunos PDFs.

¿Serían equivalentes?

Evidentemente no.

Un agente comercial podría integrar:

  • CRM;

  • email;

  • LinkedIn;

  • catálogo;

  • pricing;

  • historial del cliente;

  • analítica;

  • agenda.

Un agente de comunicación:

  • CMS;

  • redes sociales;

  • analítica;

  • calendario editorial;

  • generadores de imagen;

  • activos de marca.

Un modelo muy potente sin esa infraestructura seguirá siendo fundamentalmente una inteligencia a la que consultamos.

Un sistema bien orquestado puede convertirse en una inteligencia capaz de actuar dentro de una organización.

Y esa diferencia es mucho más profunda.

La próxima batalla puede estar tanto en el harness como en el modelo

Durante los últimos años hemos seguido apasionadamente la carrera entre modelos.

Más parámetros.

Más contexto.

Más razonamiento.

Más benchmarks.

Más velocidad.

Todo eso continuará siendo importantísimo.

Pero hay otra competición desarrollándose simultáneamente y quizá menos visible:

¿Quién consigue construir el mejor sistema alrededor de esos modelos?

Quién sabe proporcionarles el contexto correcto.

Quién diseña las mejores herramientas.

Quién consigue que trabajen durante más tiempo sin desviarse.

Quién verifica mejor.

Quién maneja mejor los errores.

Quién consigue coordinar varios agentes.

Quién reduce más la necesidad de supervisión humana.

En otras palabras:

La carrera ya no consiste solamente en construir cerebros más inteligentes. También consiste en construir mejores organizaciones alrededor de esos cerebros.

Una nueva forma de pensar la inteligencia artificial

Durante mucho tiempo hemos preguntado:

«¿Qué modelo utilizas?»

Probablemente tendremos que acostumbrarnos a formular una segunda pregunta:

«¿Dentro de qué sistema está trabajando ese modelo?»

Porque decir:

«Utiliza GPT»

puede acabar siendo tan poco descriptivo como decir que dos automóviles:

«Utilizan un motor de seis cilindros».

Es información importante.

Pero no suficiente para saber cómo se comportarán en carretera.

El modelo establece buena parte del potencial intelectual.

El harness determina cómo se convierte ese potencial en trabajo.

Y el producto final nace de ambos.

Modelo ≠ agente

Si hubiera que reducir todo este artículo a una sola idea sería esta:

Un modelo es una inteligencia. Un agente es un sistema que pone esa inteligencia a trabajar.

Entre ambos aparecen:

  • instrucciones;

  • herramientas;

  • contexto;

  • memoria;

  • permisos;

  • planificación;

  • ejecución;

  • observación;

  • verificación;

  • corrección;

  • coordinación.

Por eso Verdent utilizando GPT no tiene por qué comportarse igual que Cline utilizando GPT.

Ni Cursor utilizando GPT tiene por qué comportarse igual que Codex.

Ni siquiera tendría sentido asumir que dos productos que ofrecen exactamente el mismo modelo van a producir resultados equivalentes.

Lo verdaderamente relevante es el conjunto.

Podríamos expresarlo así:

MODELO
↓
aporta la capacidad de razonar

HARNESS
↓
decide cómo utilizar esa capacidad

HERRAMIENTAS
↓
permiten actuar sobre el mundo

FEEDBACK
↓
permite observar qué ha sucedido

VERIFICACIÓN
↓
permite detectar errores

AGENT LOOP
↓
permite intentarlo nuevamente

ORQUESTACIÓN
↓
permite convertir todo lo anterior en trabajo autónomo

Y de ahí emerge el agente.

La pregunta correcta ha cambiado

Cuando evaluemos la próxima generación de herramientas de inteligencia artificial quizá deberíamos dejar de preguntar únicamente:

«¿Cuál tiene el modelo más potente?»

y empezar a preguntar:

«¿Qué sistema consigue convertir mejor la inteligencia del modelo en trabajo terminado?»

Porque ahí está probablemente la verdadera medida de un agente.

Y también una de las claves de la siguiente fase de la inteligencia artificial:

la ventaja ya no estará únicamente en disponer de inteligencia, sino en saber orquestarla.