Después de que un artículo relacionado de AI Times abordara la 'teoría de la inutilidad del harness engineering en Big Tech', varios líderes tecnológicos intercambiaron opiniones al respecto. El reportaje indicaba que, tras Google, OpenAI también planteaba que los modelos de próxima generación podrían absorber una parte significativa de las funcionalidades del harness actual.
Este artículo se suma a esa discusión. Para comenzar con la conclusión: estoy de acuerdo con la previsión de que la mayoría del harness se volverá obsoleto. En mi propio artículo Harness Engineering Explicado Completamente — Nacimiento, Conceptos, Brechas y Futuro en Una Sola Página, escribí que los harnesses complejos creados para compensar las limitaciones del modelo se reemplazan rápidamente cuando el modelo mejora.
Sin embargo, creo que es peligroso generalizar esto como que todo el harness pronto será innecesario. El harness pierde de vista su esencia. El problema de que un modelo absorba funcionalidades es distinto del problema de que humanos y organizaciones deleguen trabajo a la IA mientras gestionan la responsabilidad.
Primero, debemos observar cómo circulan los términos clave
Sin embargo, como los términos tecnológicos con frecuencia se consumen de manera divergente en Corea que en el extranjero, realicé una verificación previa. De nuevo, debo separar las declaraciones originales, la discusión técnica real y el marco construido localmente.
Harness Engineering Explicado Completamente — Nacimiento, Conceptos, Brechas y Futuro en Una Sola Página es una comparación del consumo global versus local del término harness engineering.
| Categoría | Global | Corea |
|---|---|---|
| Liderazgo del discurso | El análisis público de ingenieros y profesionales prácticos es central. Textos y casos de practicantes como Hashimoto y Martin Fowler forman el eje. | Los artículos, resúmenes y explicaciones de medios, plataformas educativas e influyentes tecnológicos se difunden rápidamente. |
| Canales principales | GitHub, blogs técnicos, X (Twitter), estudios de casos oficiales | YouTube, Brunch, blogs, artículos |
| Materiales profundos | Como los estudios de casos de OpenAI y análisis de Martin Fowler, se examinan juntos el documento original, el código y la experiencia operativa. | La circulación se centra en traducciones y resúmenes, con una producción relativamente menor de casos de primera fuente. |
| Compartición de uso real | Empresas como Stripe con más de 1,000 PR procesados por semana y Salesforce publican cifras operativas y experiencias de fracaso. | Algunas empresas líderes como Toss y Channel Talk comparten experiencias de uso real, pero generalizar como patrón común en la industria es aún prematuro. |
De nuevo, es prudente ser cauteloso con la extrapolación, porque no hay evidencia clara de que 'harness is dead' o 'harness is useless' sean consignas ampliamente utilizadas en la esfera angloparlante. Es más preciso decir que hay discusiones sobre cómo la capacidad de herramientas del modelo mejora y parte del scaffolding se absorbe en el modelo o la plataforma, y la vida útil de las capas de coordinación complejas construidas manualmente puede acortarse. Tampoco he verificado directamente el comentario del vicepresidente Noam Brown hasta su fuente original; accedí a él a través de reportes domésticos e internacionales. Por lo tanto, examinaré el marco mismo de la 'teoría de inutilidad del harness' que se ha solidificado rápidamente en Corea.
El harness que desaparecerá y el que debe permanecer son diferentes
El harness que desaparecerá es claro. La necesidad de dividir los prompts en múltiples pasos, las reglas temporales para evitar defectos en modelos específicos, y los flujos de trabajo superficiales donde los humanos fuerzan un orden de ejecución de herramientas pueden ser absorbidos conforme el modelo mejora. Es correcto que este tipo de harness desaparezca.
Sin embargo, como subraya la síntesis del CEO de A2Sys, Dong-soo Lee, creo que es arriesgado generalizar esto a todo el harness. Resumiendo, lo siguiente:
- El harness de prompts y flujos de trabajo puede ser absorbido por el modelo. Estoy de acuerdo.
- El harness de ejecución de herramientas aborda permisos, aprobaciones y recuperación de fallos. ¿Realmente desaparecerá?
- El harness de runtime, memoria e infraestructura aborda contexto, caché, enrutamiento de modelos, costo, latencia y auditoría. Creo que es igualmente difícil verlo como harness que desaparecerá.
El núcleo del harness que mencioné en los capítulos 7 a 11 de 『Harness Engineering: Comenzando desde Cero en Ingeniería de Software de IA』 reside aquí. Los contratos establecen límites permisibles, la estructura y el aislamiento estrechan el alcance del cambio, y la trazabilidad y verificación conectan el objetivo original con el resultado real. La medición y operación manejan costo, autoridad, fallo y recuperación. El harness engineering en este alcance no es algo que se resuelve simplemente mejorando el modelo.
Por otro lado, la afirmación de que harness, loops y prompt engineering son heurísticas humanas también es correcta. Todo método comienza con heurística. Tipos, pruebas, CI, revisión de código, y separación de autoridades son todos métodos creados por humanos para manejar sistemas complejos. Pero lo más importante aquí es: ¿podemos delegar la transparencia y responsabilidad completamente a un modelo insignia? Si hemos asignado trabajo, entonces si se está ejecutando correctamente y tal como se pretendía, y que no hay responsabilidades que se crucen en incidentes, el IA no puede hacerlo por sí solo. Claro, podría haber una IA que supervise y corrija esto, pero entonces eso es harness.
Escribí esta posición en los comentarios de la publicación del profesor Han Sang-ki de la siguiente manera:
Creo que depende de cómo definamos harness engineering. Mientras exista la intención de las organizaciones y los desarrolladores, es difícil que desaparezca.
Conforme los modelos se vuelven más inteligentes, aumenta la posibilidad de que la IA complete de manera más elegante cosas completamente equivocadas. Por lo tanto, el harness no es un dispositivo para corregir defectos del modelo, sino un dispositivo operativo para fijar dirección y responsabilidad.
En operaciones reales, la frontera de responsabilidad va primero que la capacidad del modelo
Nextain avanza en trabajos con clientes de desarrollo a través de Discord. Y hoy, aquí he insertado un agente de Claude Code (en realidad, Claude Code instalado en un servidor) que participaba en el proyecto. El agente de Nextain que participó en el canal de Discord (de hecho, Claude Code instalado en un servidor) lee el canal y responde.
Junto con el canal estaba un operador no desarrollador que transmitió resultados de prueba, deficiencias y requisitos. Y mientras procesaba lo que podía procesar, cuando había que modificar un despliegue importante o un recurso que no debería tocarse, me preguntaba si tenía permiso.
Además, cuando lo implementé inicialmente, estaban un poco frustrados porque comenzaba a trabajar inmediatamente después de escuchar los requisitos. Así que di instrucciones sobre el proceso de trabajo. Cuando escuches requisitos, responde diciendo que los escuchaste, realiza análisis, establece un plan, luego reporta el plan nuevamente al canal de Discord, y procede con el trabajo. Y finalmente, cuando completes el trabajo, envía un informe final y, si surge algún problema en el camino, llámame (líder de desarrollo) para decidir lo que sea necesario preguntarme a través de Discord.
El núcleo de este harness es el proceso de desarrollo de Nextain y la autoridad de cada miembro. ¿Si fuera un modelo insignia, se daría cuenta automáticamente de la mejor forma de hacer el trabajo? ¿Realmente hay una forma mejor única? La consistencia del proceso organizacional y laboral es fundamentalmente harness. Esta frontera de responsabilidad es independiente de la capacidad del modelo. Conforme el modelo sea capaz de hacer más trabajo, la necesidad de separar claramente qué se puede hacer y dónde hay que detenerse se vuelve más rigurosa.
El problema en la práctica es la deriva y el costo
El problema que enfrentan los desarrolladores usando Codex y Claude en la práctica actual es todavía la deriva. Incluso cuando estrechas el objetivo, se desviará en otra dirección, hará cambios que se suponía no debía hacer, modificará las pruebas para pasar, y perderá las fronteras de la autoridad operativa. Conforme el modelo se vuelve más sofisticado, este problema puede ocultarse más suavemente.
En este punto, la respuesta "simplemente ejecuta más" es posible para Big Tech. Pueden extender el tiempo de razonamiento, crear más candidatos, descartar caminos fallidos, y adjuntar validación externa. Pero los desarrolladores en la práctica y las pequeñas startups que tienen que ahorrar cada centavo no pueden hacer eso. La realidad de las empresas coreanas también es la misma.
En los comentarios con el profesor Han Sang-ki vinculados arriba, el ex Secretario de Asesor Senior de Planificación del Futuro de la IA, Ha Jung-woo, mencionó "eficiencia de costo de token total". El harness no es un dispositivo para rechazar modelos insignia. Es un dispositivo de control de costos para usar modelos caros solo para decisiones verdaderamente necesarias, y separar trabajo repetible en modelos más pequeños, herramientas locales, scripts y verificadores determinísticos.
El logro reciente publicado por OpenAI en matemáticas también necesita separarse en dos puntos en el tiempo. Valoro altamente el primer logro relacionado con contraejemplos del problema de Erdős Unit Distance en el plano, porque demuestra la posibilidad de que la IA encuentre conexiones matemáticas diferentes de los enfoques existentes, mostrando la posibilidad de nuevos descubrimientos únicos de la IA.
Por otro lado, el test-time computing que se enfatizó posteriormente es una dirección de invertir más computación, búsqueda de candidatos, verificación e iteración en el tiempo de razonamiento. También es una tecnología importante. Pero si se describe solo como mejora de inteligencia pura de un modelo, la estructura de costos desaparece. Es una tecnología de cantidad bruta, pero es una tecnología particularmente favorable para Big Tech.
El harness es una línea de defensa contra costos y datos
La declaración "el modelo consumirá el harness" es provocadora. Pero la pregunta de quién usa ese modelo y a qué costo es un asunto separado. Conforme el modelo absorba más funcionalidades, el código del usuario puede simplificarse. Simultáneamente, puede volverse más dependiente de llamadas de modelo más pesadas y caras. La complejidad no desaparece; se traslada de la estación de trabajo del usuario a la capa de facturación del proveedor del modelo.
Lo mismo sucede con los datos. Para que un agente sea realmente útil, necesita ver documentos, código, cronogramas, correos, logs operativos, historiales de incidentes, flujos de aprobación y datos de clientes. En el momento en que el agente se convierte en una estación de trabajo, todo el trabajo del usuario se convierte en entrada.
Un buen harness envía solo el contexto necesario a modelos externos y mantiene el resto en la estación de trabajo del usuario. Enruta modelos, reutiliza caché, divide permisos y adjunta verificación reproducible. Por eso el harness es una línea de defensa de costos y una línea de defensa de datos.
Desde esta perspectiva, hay incluso una posibilidad de que empresas globales de modelos encuentren incómodo un harness fuerte del lado del usuario. Si el usuario primero procesa con modelos más pequeños y herramientas locales, y solo invoca el insignia en momentos necesarios, el volumen de llamadas y el contexto transmitido disminuyen. De hecho, esta no es una afirmación definitiva, sino un interés que naturalmente debería considerarse en una estructura industrial donde el costo de desarrollo, razonamiento, GPU y energía del modelo de frontera aumenta.
OpenAI y Anthropic están en la vanguardia de la competencia de harness a través de Codex y Claude Code. Mientras tanto, Google es tanto una empresa de modelos como un proveedor de nube. No puedo decir que cada empresa tenga exactamente los mismos intereses, pero la razón por la que es difícil escuchar este debate solo como predicción técnica pura es clara. Un buen harness reduce el deseo de Big Tech de 'trasladar la estación de trabajo al modelo para recopilar datos' y la dependencia del 'uso de insignia'.
Los loops no son el nuevo valor predeterminado
Lo mismo aplica a los loops. Yo uso loops, pero creo que para la mayoría de las misiones, es correcto no usar loops. Si es trabajo que se puede confiar a un desarrollador general y puede producir resultados apropiados, usar un buen modelo una vez correctamente probablemente sea más barato y rápido. Sorprendentemente, los casos donde los loops son efectivos son limitados.
El primero es la investigación y desarrollo. Trabajo donde no hay respuesta correcta, la hipótesis cambia según los resultados del experimento, y el siguiente experimento debe cambiar dinámicamente leyendo los resultados anteriores. Mi investigación interna de voz y canciones es así. En este caso, resultados experimentales y datos completos se revisan por múltiples IAs, continuidad con experimentos existentes, presencia de deriva, y necesidad del siguiente ciclo se juzgan. El criterio de finalización no es un resultado plausible, sino el juicio de que los indicadores no suben más. Como el objetivo es la convergencia de la exploración, los loops son apropiados.
El segundo es cuando se usan modelos pequeños en entornos limitados. Los LLM pequeños tienden a reducir objetivos y detenerse con "esto es suficiente". Pero en este caso, lo necesario no es un loop largo sino un dispositivo que cierre el objetivo y la condición de terminación. Es más cercano a la función goal de Claude Code que a un loop. Es un harness en lugar de un loop. Usar loops sin discreción en tareas diarias de usuarios generales se convierte en desperdicio de costos. Los loops se usan para convergencia de exploración, y el harness se usa para fijar objetivo y responsabilidad. Los dos no son relaciones substitutivas.
Naia intenta mantener la estación de trabajo del lado del usuario
Naia no rechaza modelos insignia. Planeamos usar el modelo insignia en la nube exhaustivamente en desarrollo. Debes usar buenos modelos.
Pero no planamos trasladar toda la estación de trabajo y datos a plataformas de Big Tech. Lo que Naia busca es una estructura que use juntos: local, P2P, open-weight, modelos pequeños, verificadores determinísticos, y harness de permisos explícitos. Usa insignias caras para decisiones necesarias, pero la estación de trabajo básica debe permanecer en manos del usuario.
Desde este punto, el desarrollo de modelos open-weight como DeepSeek, Qwen, Kimi, y GLM es importante. Es posible combinar modelos según propósito, proteger datos localmente, e invocar insignias cerradas solo cuando sea necesario. En Corea, las estrategias de modelo independiente de empresas como Upstage y Naver también tienen significado en este flujo. En lugar de seguir directamente el insignia de Big Tech global, una ruta que entrelace bien modelos open-weight, modelos independientes, harness especializados y contextos de negocios nacionales puede ser más práctica.
Los modelos pueden ser prestados. Pero no necesitas prestar la estación de trabajo y los datos también.
Conclusión: Lo necesario es discusión sobre nivel técnico, no teoría de inutilidad
El harness que desaparece desaparecerá. Las funcionalidades que absorba el modelo aumentarán. No hay razón para negar esto. Pero creo que las funcionalidades que absorbe el modelo, el sistema de ejecución que fija la intención organizacional y la responsabilidad, y el sistema operativo que protege los límites de costos y datos no desaparecerán. Si el sujeto que encarga trabajo a la IA es humano y el sujeto responsable de los resultados también es humano, entonces contrato, estructura, trazabilidad, verificación y operación no desaparecerán.
Espero que ahora dejemos de debatir palabras clave sobre si el harness está muerto o vivo. Me gustaría ver discusiones realmente centradas en tecnología como: qué poner dentro del modelo, qué mantener bajo el control del usuario y la organización, cómo verificar y revertir la deriva, y quién carga el costo de tokens y la exposición de datos.
Referencias y fuentes
Mis artículos y libros
- 『Harness Engineering: Comenzando desde Cero en Ingeniería de Software de IA』
- 「Harness Engineering Explicado Completamente — Nacimiento, Conceptos, Brechas y Futuro en Una Sola Página」
- 「Lanzamiento de Harness Engineering」
Catalizador directo de esta discusión
- AI Times, "Big Tech tras Google también adopta 'teoría de inutilidad del harness'... los modelos de próxima generación absorberán funcionalidades"
- AI Times, "[25 de junio] 'El modelo consumirá el harness'..."
- Publicación de Facebook del profesor Han Sang-ki y discusión en comentarios
- CEO de A2Sys Dong-soo Lee, "¿Teoría de inutilidad del harness? Mitad correcta, mitad incorrecta"
Documentos técnicos y fuentes originales
- OpenAI, "Learning to Reason with LLMs"
- OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
- OpenAI, "Introducing Codex"
- OpenAI, "Introducing OpenAI o3 and o4-mini"
- Google, "Gemini 2.0: our new AI model for the agentic era"
- "The Interplay of Harness Design and Post-Training in LLM Agents"
- "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
- "AutoHarness"
