El software después de la IA: comienza la era del harness
(tomtunguz.com)- El fin de la era del software marca el inicio de la era del harness, y el SaaS que operaba con flujos de trabajo fijos y bases de datos administradas está siendo reemplazado por una IA dotada de inteligencia
- La IA es poderosa, pero está sin domesticar, como un caballo salvaje; para aprovechar su fuerza se necesita una domesticación sistemática
- El harness para agentes de IA se define por 7 componentes clave alrededor de un LLM central, y cada uno determina la confiabilidad y el rendimiento a nivel de producción
- En una era en la que todas las empresas pueden acceder a los mismos modelos, no gana el modelo en sí, sino quien mejor diseña y opera el harness (best rider)
- Miles de mercados separados que los grandes laboratorios no priorizan siguen siendo una oportunidad para las startups
El significado de la era del harness
- La IA está reemplazando con inteligencia al SaaS basado en flujos de trabajo fijos y a las bases de datos administradas, redefiniendo el paradigma del software
- Se compara la IA con un mustang: poderosa pero indómita, imposible de usar tal cual, y el proceso de domesticarla es precisamente el harness
- La esencia de esa domesticación es una arquitectura que coloca al LLM en el centro y distribuye radialmente 7 componentes a su alrededor
Los 7 componentes del harness para agentes de IA
-
1. Context & Memory (contexto y memoria)
- Los modelos de propósito general requieren búsqueda personalizada según el caso de uso (bespoke retrieval); un sistema de búsqueda de contexto para un radiólogo no puede ser igual al de un asistente legal
- La memoria de corto plazo ("qué estaba haciendo el agente hace 45 segundos"), la búsqueda masiva de imágenes (radiología y generación visual) y la búsqueda por palabras clave en decenas de miles de millones de documentos requieren sistemas distintos según el caso
- Junto a la capa de búsqueda se ubica una base de datos de contexto, que funciona como un "libro de recetas" sobre cómo opera realmente el negocio
- Los procedimientos operativos estándar (SOP) que la gente lleva en la cabeza al llegar a trabajar son precisamente esa receta
- La captura inicial y su evolución conforme cambian las personas y los procesos son la esencia de la base de datos de contexto
-
2. Tools & Action (herramientas y acción)
- Las herramientas son el medio por el cual el agente influye en el mundo exterior; si las recetas de la base de datos de contexto indican qué hacer, las herramientas son los ingredientes y utensilios para hacerlo realidad
- Los harness modernos exponen herramientas mediante un registry, validan los argumentos entregados por el modelo, despachan la llamada, hacen pasar las tareas sensibles por compuertas de aprobación y procesan los resultados dentro del bucle del agente
- MCP está emergiendo como el tejido conectivo para la conexión de herramientas
- La calidad del harness se define por cuántas herramientas puede exponer de forma segura y qué tan limpiamente maneja los fallos
-
3. Orchestration & Loop (orquestación y bucle)
- El bucle del agente sigue la estructura think → act → observe → repeat
- La planificación, la descomposición de tareas, los subagentes, los reintentos y las condiciones de detención determinan cómo se ejecuta el trabajo
- Debe mejorar con el uso, y el patrón de ciclo cerrado que aprende de cada ejecución es un factor de diferenciación entre proveedores
-
4. State & Persistence (estado y persistencia)
- En grandes empresas donde muchas personas usan el sistema al mismo tiempo, la resiliencia es indispensable
- Si el harness se cae en el paso 7 de una tarea de 10 pasos, debe reanudar desde el paso 8, no empezar desde cero
- El sistema de archivos, los checkpoints, los hilos de sesión y los almacenes de artefactos son mecanismos para evitar la pérdida de trabajo
-
5. Sandbox & Compute (sandbox y cómputo)
- Cada agente necesita un espacio de trabajo aislado (sandbox)
- Un workspace Unix aislado, salida de red (egress) controlada y credenciales almacenadas fuera del modelo garantizan seguridad, confidencialidad y velocidad a gran escala
-
6. Observability & Governance (observabilidad y gobernanza)
- "Lo que no se puede ver no se puede confiar": rastrear cada paso, registrar cada llamada a herramientas, ejecutar evals como pruebas de regresión y añadir human-in-the-loop en las decisiones de mayor riesgo es lo que convierte una demo en un sistema de producción
- Los guardrails hacen cumplir políticas y los evals detectan regresiones antes que los clientes
-
7. Cost & Workflow Optimization (optimización de costos y flujos de trabajo)
- El séptimo componente es el juicio arquitectónico (architectural judgment)
- Implica decidir qué debe resolverse de forma determinista o no determinista, elegir el modelo adecuado para cada etapa (de frontera, mediano, pequeño o fine-tuned) y decidir si el conocimiento debe vivir en habilidades o en memoria
Un nuevo mapa competitivo
- El resultado es una nueva dinámica competitiva del software, que no se aplica por igual a todas las categorías
- Los mercados que priorizan los grandes laboratorios (principales centros de investigación en IA) se benefician de la rapidez de ejecución y el control directo del modelo
- Pero, aparte de esos, miles de mercados independientes siguen abiertos para las startups
- En una era en la que todas las empresas pueden usar los mismos modelos, ganan los "best riders"; es decir, la capacidad de diseñar y operar el harness se vuelve la ventaja competitiva central
9 comentarios
pies tan ligero que lo uso mucho como herramienta de agente. Además, como también quería conectar Claude Code y Gemini, hicepi-shell-acpy lo estoy usando muy bien. He creado varias skills y las uso, y mientras más lo pruebo, más me convence que lo mejor es ajustarlo totalmente a mi estilo. Cuando voy a usar directamente Claude Code, Codex y similares, activo el modo YOLO y apago todas las herramientas integradas hasta dejarlas al nivel depi. Las funciones nuevas, las desactivo de inmediato, como si las clavara de un martillazo.Yo eliminé todas las configuraciones de harness que tenía.
A medida que el modelo avanza, el harness termina funcionando como un factor que limita su rendimiento.
Una configuración de harness mal hecha produce resultados incluso peores.
Las configuraciones de harness que ya existían en la 4.7 o anteriores ya no tienen sentido en la 4.8,
y en GPT 5.5 solo estorban.
Los componentes del arnés mencionados en el texto no son cosas que se resuelvan simplemente porque aumente la inteligencia del LLM.
Si se refiere al arnés de la época en que su definición era poco clara, creo que podría ser así, pero si hablamos del arnés descrito en el texto, parece más bien un área que habrá que seguir gestionando de forma continua en el futuro.
Más que un problema de inteligencia, los modelos también están desarrollando, aparte de la inteligencia, capacidades de uso como la orquestación y las herramientas. De hecho, el campo de la orquestación era una de las partes clave de Harness, pero ahora ya incluso soporta eso. Entonces, en este momento, si hubiera orquestación hecha en casa y orquestación oficial, ¿cuál sería la correcta de usar?
Estoy de acuerdo. Tenemos que desarrollar la respuesta juntos.
Hay una publicación oficial sobre harnessing anunciada en el sitio web de OpenAI. Comparte experiencias y consejos sobre cómo usaron harnessing dentro de OpenAI. Eso significa que incluso OpenAI usa harnessing en sus proyectos internos. Harnessing claramente es necesario y tiene un impacto directo en la calidad final de la implementación. Sobre todo, puede reducir hasta la mitad los tokens necesarios para implementar un resultado de la misma calidad. Si puedes obtener tanto rendimiento como mejor precio, no hay razón para no usarlo.
En Opus 4.8 se agregó
ultracode effort, y esto resuelve mejor lo que antes hacía el modo harness manual del desarrollador. Por lo tanto, creo que en este momento es mejor eliminar la parte de orquestación del modo harness que estaban usando.Estoy de acuerdo. Yo también saqué en 4.8 la orquestación artesanal para 4.7 y el forzar una planificación demasiado verbosa porque terminaban estorbando.
Eso sí, en un codebase de cientos de miles de líneas mantenido durante años, el verdadero valor del harness no está en la orquestación sino en la capa que ultracode no puede reemplazar (grafo de conocimiento, convenciones del dominio, invariantes de validación), así que dejé esa capa de contexto y paralelicé con workflow solo los tramos realmente independientes.
En cambio, si es un proyecto nuevo, creo que ultracode sí encaja sin necesidad de un harness. Al final, más que "quitarlo vs dejarlo", parece un tema que depende de la antigüedad del codebase y del nivel de acoplamiento.
Sí. Es correcto. La parte que excluye la orquestación sigue siendo valiosa.