Debate sobre el harness de OpenAI y Anthropic: modelos más potentes, apuestas de ingeniería opuestas
Los ingenieros de OpenAI han reabierto una disputa relevante con Anthropic: los modelos de IA más potentes deberían necesitar harnesses más ligeros, aunque las tareas exigentes siguen beneficiándose de una supervisión más intensa.
Ese debate sobre el harness de OpenAI y Anthropic no se limita a los prompts ni a las preferencias de interfaz. Abarca el software que rodea a un modelo, incluidas las herramientas, la memoria, los permisos, la planificación, la evaluación y la aprobación humana.
OpenAI sostiene que un andamiaje excesivo puede codificar limitaciones que el siguiente modelo ya no tendrá. Los experimentos recientes de Anthropic llegaron a una conclusión más condicional. Los mejores modelos eliminaron parte de la orquestación, pero los planificadores y evaluadores independientes siguieron siendo valiosos cuando las tareas se acercaban a los límites del modelo.
El desacuerdo afecta a mucho más que Codex y Claude Code. Las empresas están convirtiendo modelos generales en agentes que editan repositorios, operan navegadores, analizan documentos y coordinan proyectos prolongados. Cada control adicional puede mejorar la fiabilidad, pero también añade latencia, complejidad y otra suposición que puede quedar obsoleta.
Por tanto, la pregunta central no es si los harnesses importan. El trabajo de ingeniería de ambas empresas demuestra que sí. La cuestión es si el progreso desplaza el valor hacia el modelo, hacia el harness o repetidamente entre ambas capas.
Qué cambiaron realmente OpenAI y Anthropic
Ambas empresas tratan ahora el harness de agentes como una capa que define el producto, pero discrepan sobre cuánta inteligencia debería contener esa capa.
Un harness de agentes es el entorno de ejecución que conecta un modelo con herramientas, contexto, memoria, bucles de retroalimentación y controles de usuario. El modelo genera decisiones. El harness determina qué información ve, qué acciones puede realizar y cómo se detectan los errores.
La postura de OpenAI quedó clara en informaciones de agosto sobre su esfuerzo por expandir los agentes más allá del desarrollo de software. Sus ingenieros describieron una buena ingeniería de harnesses como proporcionar a un modelo las herramientas y la información precisas que necesita, sin rodearlo de reglas innecesarias.
El ingeniero Nick Gershenson dijo a TechCrunch que conjuntos elaborados de lógica condicional y herramientas pueden producir ganancias a corto plazo. Sin embargo, sostuvo que un nuevo modelo puede volver obsoletas esas incorporaciones en cuestión de meses. Su dirección preferida es una interfaz contenida que permita a un modelo capaz resolver por sí mismo una mayor parte del problema.
Ese principio recuerda la bitter lesson, el influyente argumento de Rich Sutton sobre cómo la computación general supera a los sistemas construidos en torno a un conocimiento humano extenso. Aplicada a los agentes, la lección favorece modelos de capacidad amplia frente a flujos de trabajo diseñados manualmente para cada fallo previsto.
OpenAI no ha abandonado la ingeniería de harnesses. Su propio relato sobre la ingeniería de Codex describe los repositorios, la documentación, las pruebas, los bucles de retroalimentación y los planes legibles por máquinas como infraestructura esencial. La empresa informó de una media de 3,5 pull requests por ingeniero al día en un proyecto interno.
La distinción radica en dónde quiere OpenAI que resida la complejidad. Sus ingenieros prefieren entornos comprensibles y retroalimentación clara en lugar de ramificaciones cada vez más elaboradas que dicten cómo debe razonar el modelo.
La investigación de Anthropic del 24 de marzo presentó una prueba de estrés diferente. El investigador Prithvi Rajasekaran utilizó un planificador, un generador y un evaluador para crear aplicaciones completas durante sesiones autónomas prolongadas.
El planificador traducía una solicitud breve en una especificación estructurada. El generador implementaba ese plan. El evaluador operaba la aplicación, comprobaba los criterios acordados y devolvía defectos para su corrección.
La comparación inicial de Anthropic descubrió que una ejecución con un solo agente producía una aplicación cuya función central de juego no funcionaba. El harness multiagente entregó un resultado más amplio y funcional, aunque persistían defectos.
Esto no demostraba que una mayor complejidad siempre gane. Posteriormente, Anthropic eliminó la descomposición a nivel de sprint cuando Claude Opus 4.6 gestionó el trabajo prolongado de forma más coherente. Sin embargo, el planificador y el evaluador siguieron detectando funciones ausentes o superficiales.
Por tanto, el acontecimiento es a la vez una convergencia y un desacuerdo. OpenAI y Anthropic simplifican los harnesses cuando los modelos absorben responsabilidades anteriores. Difieren sobre la rapidez con la que los desarrolladores deberían confiar en esa transferencia.
Por qué el debate sobre el harness de OpenAI y Anthropic importa ahora
La presión surge porque los agentes están pasando de tareas de programación acotadas a trabajos donde el éxito es más difícil de definir y el fracaso más difícil de revertir.
La programación ofreció el primer entorno favorable para los agentes. Los repositorios contienen archivos estructurados, los compiladores exponen errores y las pruebas suelen producir señales claras de aprobado o suspendido. Un harness puede convertir esas señales en otro intento del modelo.
El trabajo general del conocimiento ofrece menos comprobaciones fiables. Un memorando estratégico puede parecer coherente mientras se apoya en supuestos débiles. Una hoja de cálculo puede calcular correctamente y, aun así, responder a la pregunta empresarial equivocada. Un agente puede terminar una presentación pulida sin advertir que sus evidencias están desactualizadas.
OpenAI está ampliando su enfoque de agentes a esos entornos menos estructurados. Ese movimiento presiona a la empresa para preservar la simplicidad asociada con modelos más potentes mientras añade los controles que exigen los usuarios comunes.
Anthropic afronta la presión opuesta. Claude Code construyó gran parte de su atractivo alrededor del progreso visible, la interacción frecuente y la participación del usuario. Ese enfoque puede parecer más seguro, pero las preguntas y aprobaciones repetidas aumentan la carga de trabajo del operador.
La rivalidad refleja dos instintos de producto. OpenAI ha perseguido a menudo la experiencia de asignar un objetivo y recibir un resultado terminado. Anthropic, por lo general, ha expuesto una mayor parte del proceso de razonamiento intermedio mediante planes, alternativas y solicitudes de permisos.
Ningún instinto es universalmente mejor. La autonomía resulta atractiva cuando el objetivo está claro y la verificación es barata. La colaboración cobra valor cuando las preferencias no están expresadas o las consecuencias son difíciles de medir.
Esto explica por qué una interfaz puede cambiar la calidad aparente de un modelo idéntico. Un harness controla la selección de contexto, las descripciones de herramientas, el comportamiento de reintento, el acceso a archivos y el momento de la intervención del usuario. Esas decisiones moldean cada acción que realiza el modelo.
Los creadores de frameworks independientes han observado la misma dependencia. LangChain informó de que los perfiles de harness específicos de cada modelo produjeron mejoras de entre 10 y 20 puntos en un subconjunto de tau2-bench frente a su configuración predeterminada. Sus perfiles de harness ajustan prompts, herramientas y middleware para distintos comportamientos de modelo.
Ese resultado cuestiona una versión simple de la tesis de OpenAI. Si el harness fuera solo una muleta temporal, modificarlo no debería crear grandes diferencias de rendimiento mientras el modelo subyacente permanece fijo.
Sin embargo, también respalda la crítica de OpenAI a la abstracción innecesaria. LangChain no encontró una única arquitectura cada vez más complicada que mejorara todos los modelos. Descubrió que modelos diferentes respondían a configuraciones diferentes.
La presión práctica recae sobre los equipos de producto. Deben decidir si optimizar estrechamente para un proveedor o mantener una capa portable entre varios modelos.
La optimización cercana puede ofrecer mejores resultados inmediatos. También puede crear dependencia de herramientas, prompts y comportamientos de contexto específicos de cada proveedor. La portabilidad limita esa dependencia, pero un harness genérico puede dejar sin aprovechar la capacidad del modelo.
Estas decisiones cobran mayor importancia a medida que los agentes reciben permisos más amplios. Un asistente de programación que sugiere un parche tiene un papel acotado. Un agente que lee comunicaciones, edita documentos compartidos y activa sistemas empresariales cruza varios límites de confianza.
Por ello, los equipos que evalúan estos productos deberían mirar más allá de los benchmarks de modelos. Necesitan pruebas sobre la combinación completa de modelo y harness bajo permisos, datos y condiciones de fallo realistas.
OpenAI quiere que el modelo lidere
El argumento de OpenAI a favor de un harness más ligero sostiene que los desarrolladores deberían exponer el entorno con claridad y dejar que el modelo aporte la mayor parte del comportamiento adaptativo.
Esta postura no implica eliminar las pruebas, los permisos ni la gestión del contexto. Significa resistirse a procedimientos de razonamiento construidos manualmente que compensan limitaciones que previsiblemente desaparecerán.
La experiencia de OpenAI con la primera aplicación web de Codex ayuda a explicar esa convicción. La empresa apostó inicialmente por que un modelo completara tareas con una intervención mínima del usuario. El enfoque más interactivo de Claude Code de Anthropic demostró estar mejor alineado con lo que los modelos podían hacer de forma fiable en ese momento.
OpenAI añadió posteriormente más oportunidades para que los usuarios orientaran Codex. Un ingeniero reconoció que el producto anterior se había adelantado a lo que su modelo y su harness podían respaldar.
Ese historial importa porque muestra el peligro en ambos sentidos. Un harness puede contener demasiada lógica rígida. También puede asumir una competencia del modelo superior a la que los usuarios reciben realmente.
El enfoque actual de OpenAI intenta evitar otro desajuste mediante entornos más claros y una retroalimentación más sólida. Su relato interno de ingeniería destaca la documentación estructurada, las reglas de repositorio, los planes y las comprobaciones automatizadas.
Estos elementos son más ligeros que un flujo de trabajo que prescribe cada paso de razonamiento. Sin embargo, siguen representando una ingeniería extensa. El harness delega el juicio mientras facilita la inspección del éxito.
El enfoque también encaja con las ambiciones de producto de OpenAI. Un agente general para el lugar de trabajo no puede depender de que los diseñadores predigan cada secuencia que un usuario podría solicitar. El espacio de tareas posibles es demasiado amplio.
Un sistema liderado por el modelo puede elegir herramientas y revisar planes a medida que cambian las condiciones. Esa flexibilidad resulta atractiva cuando los usuarios pasan de la investigación a las hojas de cálculo, los mensajes, el código y las presentaciones dentro de una misma tarea.
Sin embargo, un harness mínimo transfiere más responsabilidad al modelo. El modelo debe detectar la ambigüedad, solicitar la información faltante y reconocer cuándo una acción merece confirmación.
Estos comportamientos no están garantizados únicamente por la capacidad general. Un modelo puede mejorar al ejecutar instrucciones sin mejorar en la misma medida al detectar un objetivo defectuoso.
La experiencia del usuario agrava ese riesgo. Ethan Mollick, profesor de Wharton que estudia la IA en el lugar de trabajo, ha contrastado los sistemas que intentan completar el trabajo de inmediato con aquellos que muestran comparaciones y solicitan comentarios.
El diseño más autónomo reduce la fricción cuando el agente interpreta correctamente el objetivo. Cuando no lo hace, los usuarios pueden descubrir el error solo después de una larga cadena de trabajo coherente pero mal dirigido.
Esto vuelve central la calidad del contexto. Un harness ligero funciona mejor cuando proporciona información concisa, relevante y actualizada. Un contexto grande sin filtrar puede ocultar las prioridades incluso cuando el modelo admite una ventana de contexto extensa.
Para los trabajadores del conocimiento, organizar esas evidencias sigue siendo un problema de ingeniería independiente. Una base de conocimientos con capacidad de búsqueda puede reducir el ruido de recuperación antes de que un agente empiece a actuar.
La tesis de OpenAI es más sólida para tareas con una densa retroalimentación automática. Los compiladores, las suites de pruebas, los linters y las comprobaciones del navegador permiten a un agente evaluar el progreso sin un juicio humano constante.
Se debilita cuando la finalización depende del gusto, la historia organizacional o expectativas no registradas. Un modelo no puede inferir evidencia que nunca entra en su contexto.
Por ello, OpenAI está haciendo una apuesta calculada. A medida que los modelos mejoren, resolverán internamente una mayor parte de la planificación y la recuperación. Los diseñadores de harnesses deberían preservar la generalidad en lugar de congelar las limitaciones de los modelos de ayer en el producto de mañana.
Anthropic afirma que el trabajo más difícil aún necesita más estructura
La evidencia de Anthropic sobre harnesses más robustos muestra que los modelos más potentes no eliminan la orquestación; desplazan su límite útil hacia tareas más difíciles.
El harness de larga duración de Anthropic partió de dos debilidades recurrentes. Los modelos perdían coherencia durante trabajos extensos y evaluaban su propio resultado con demasiada generosidad.
El primer problema se refería al contexto. Las tareas largas acumulan decisiones, resultados de herramientas, errores e implementaciones parciales. Incluso cuando una ventana de contexto puede contener ese material, su organización afecta lo que el modelo detecta.
Anthropic utilizó reinicios de contexto con archivos de traspaso estructurados. Un reinicio proporcionaba a una nueva sesión del agente un estado de trabajo limpio, al tiempo que preservaba el progreso esencial y los siguientes pasos.
El segundo problema era la autoevaluación. El mismo modelo que producía una aplicación a menudo aceptaba resultados débiles, especialmente cuando la calidad dependía del criterio de diseño.
Anthropic separó la creación de la revisión. Su evaluador utilizó criterios explícitos y automatización del navegador para comprobar la funcionalidad. El generador recibía hallazgos concretos e intentaba realizar correcciones.
El primer harness completo amplió una solicitud de juego de una sola frase hasta convertirla en 16 funciones distribuidas en diez sprints. Su evaluador aplicó contratos detallados a cada sprint, incluidos 27 criterios para una fase del editor de niveles.
Anthropic informó de que el resultado multiagente ofrecía funcionalidades centrales operativas que faltaban en el intento con un solo agente. Sin embargo, requirió considerablemente más tiempo de ejecución, orquestación y uso del modelo.
Ese equilibrio hace que el experimento sea más útil que una simple victoria en un benchmark. Muestra lo que una estructura adicional puede aportar, al tiempo que revela por qué los equipos no pueden añadir evaluadores indiscriminadamente.
Anthropic repitió después el proceso con un modelo más potente. Opus 4.6 sostuvo la compilación principal durante más de dos horas sin la anterior descomposición por sprints.
Esto respaldó la observación central de OpenAI. Una capacidad antes proporcionada por el harness se había trasladado al modelo, haciendo innecesaria parte de la infraestructura de apoyo.
El evaluador aún encontró lagunas importantes. Identificó funciones centrales de audio que existían solo como elementos superficiales de interfaz o marcadores de posición. El generador abordó después varias de esas omisiones.
La conclusión de Anthropic no fue que cada tarea necesite tres agentes. El evaluador generó su mayor valor cuando el trabajo se situaba cerca del límite de lo que el generador podía completar de forma fiable.
Ese límite es dinámico. Una nueva versión del modelo lo desplaza hacia afuera. Una tarea más exigente vuelve a desplazarlo hacia adentro.
Esto produce una interpretación distinta de la lección amarga. Los modelos generales sustituyen soluciones hechas a medida para los problemas de ayer, pero también hacen alcanzables objetivos antes impracticables.
Cuando los equipos intentan esos objetivos, aparecen nuevos modos de fallo. El harness no desaparece. Sigue la frontera de capacidad.
La posición de Anthropic también reconoce que la evaluación forma parte del producto. Un sistema que genera más resultados no es automáticamente más útil. Alguien o algo debe determinar si ese resultado cumple el requisito real.
Para los desarrolladores, las suites de pruebas pueden aportar buena parte de ese juicio. En trabajos de diseño, investigación y gestión, los criterios a menudo deben formularse antes de que actúe el agente.
Una arquitectura de planificador y evaluador hace explícitas esas expectativas. También puede amplificar criterios deficientes. Un evaluador aplicará el indicador medible que reciba, incluso cuando ese indicador no capture lo que valoran los usuarios.
Por tanto, los harnesses más robustos crean su propio problema de gobernanza. Más componentes significan más prompts, permisos, registros, traspasos y rutas de fallo que mantener.
La evidencia de Anthropic respalda una estructura selectiva, no una complejidad permanente. Elimine lo que un modelo más potente ya puede resolver y reinvierta el esfuerzo de ingeniería donde la verificación aún produzca una mejora significativa.
La prueba entre modelo y harness sigue sin resolverse
Ninguna de las dos partes ha demostrado que su arquitectura preferida gane en todos los modelos, tareas, presupuestos y niveles de riesgo.
El debate entre OpenAI y Anthropic sobre los harnesses se apoya en gran medida en experimentos internos y observaciones de productos. Estas fuentes revelan decisiones de ingeniería, pero no ofrecen una comparación controlada entre Codex y Claude Code.
El relato de OpenAI refleja sus propios modelos, repositorios y prácticas de equipo. Los ejemplos de Anthropic utilizan modelos Claude en tareas seleccionadas de creación de aplicaciones. Cada empresa eligió el entorno y los criterios de éxito.
Incluso la comparación detallada de Anthropic modificó varias variables a la vez. El sistema completo añadió planificación, evaluación, descomposición, ejecución más larga y más llamadas al modelo. El resultado no puede aislar qué componente produjo cada mejora.
Posteriormente, la empresa utilizó la eliminación de componentes para entender esa cuestión. Sin embargo, sus conclusiones seguían procediendo de una pequeña colección de demostraciones, en lugar de una replicación independiente amplia.
Los benchmarks de terceros ayudan, pero introducen complicaciones adicionales. Un harness puede rendir bien porque el benchmark se parece a su flujo de trabajo preferido. Otra configuración puede optimizar el uso de tokens, la tasa de aprobación, la latencia o la capacidad de recuperación.
La misma puntuación también puede ocultar riesgos operativos diferentes. Un agente podría fallar de forma visible y detenerse. Otro podría producir un resultado plausible pero incorrecto que supere las comprobaciones automatizadas.
La investigación sobre sistemas de programación en producción trata cada vez más al modelo y al harness como una unidad combinada. Un reciente estudio de código fuente examinó 11 harnesses de programación, incluidos Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode y OpenHands.
Esa diversidad debilita la idea de un único harness óptimo. Estos sistemas difieren en gestión del contexto, puntos de extensión, planificación, aislamiento y ejecución de herramientas porque sus diseñadores se dirigen a usuarios diferentes.
La portabilidad presenta otra cuestión sin resolver. Algunos informes citaron una comparación en la que el harness de código abierto Pi superó a Codex utilizando el mismo modelo de OpenAI.
Un resultado así sugiere que el proveedor del modelo no construye automáticamente el mejor entorno para cada tarea. No establece que Pi gane de forma generalizada, ya que la configuración del benchmark y del sistema sigue siendo decisiva.
Los harnesses abiertos pueden exponer trazas, uso de tokens y detalles de configuración que los productos propietarios ocultan. Esa transparencia ayuda a los equipos a diagnosticar fallos y cambiar de proveedor.
Los harnesses controlados por proveedores reciben acceso temprano a capacidades específicas del modelo. Sus desarrolladores pueden ajustar el sistema a comportamientos no documentados e implementar actualizaciones coordinadas.
Los incentivos comerciales importan. Tanto OpenAI como Anthropic se benefician cuando los clientes usan sus modelos a través de sus propias interfaces. Poseer el harness fortalece la distribución y puede aumentar los costes de cambio mediante contexto almacenado, integraciones y flujos de trabajo aprendidos.
Eso no vuelve falsas sus afirmaciones de ingeniería. Significa que los clientes deberían separar la evidencia técnica de la estrategia de plataforma.
El coste es otra incertidumbre, incluso sin comparar cifras públicas de precios. La planificación y evaluación multiagente consumen tokens y tiempo adicionales. Una tasa de finalización más alta puede justificar esa sobrecarga cuando el fallo es costoso.
Lo contrario se aplica al trabajo rutinario y reversible. Ejecutar un evaluador sobre cada edición menor puede consumir más recursos que corregir el error ocasional.
La seguridad complica aún más la tesis del harness más ligero. Los mejores modelos pueden ejecutar secuencias de acciones más largas y utilizar herramientas con mayor eficacia. Esas mejoras aumentan las consecuencias de instrucciones malinterpretadas.
Los límites de permisos, los registros de auditoría, el sandboxing y las confirmaciones son funciones del harness. Una mayor capacidad puede aumentar su importancia, incluso mientras reduce la necesidad de estructuras de planificación.
Por tanto, los equipos deberían rechazar las pruebas unidimensionales. Una evaluación útil debe medir la finalización de tareas, los defectos ocultos, el tiempo de revisión humana, el consumo de recursos y la recuperación tras un fallo.
También debería comparar configuraciones bajo el mismo modelo. De lo contrario, un equipo podría comprar un modelo más capaz cuando un cambio de contexto o de herramienta habría resuelto el problema.
La evidencia actual respalda una regla condicional. Utilice el harness más ligero que cumpla un umbral de fiabilidad definido y, después, añada estructura cuando los fallos observados lo justifiquen.
Esa regla suena a compromiso, pero genera un trabajo operativo exigente. Los equipos necesitan evaluaciones repetibles, inspección de trazas y configuraciones versionadas para saber cuándo un componente sigue siendo útil.
Sin esa evidencia, “más ligero” se convierte en fe en el próximo modelo. “Más pesado” se convierte en folclore acumulado codificado como prompts y ramificaciones de flujo de trabajo.
Tres señales decidirán qué enfoque gana
La siguiente fase se decidirá mediante evidencia comparativa, no por la descripción preferida de su arquitectura que haga cada empresa.
La primera señal es el rendimiento al intercambiar harnesses. Los investigadores y creadores de frameworks necesitan pruebas controladas que mantengan constantes el modelo, la tarea, el acceso a herramientas y los límites de recursos.
Si los harnesses de terceros superan repetidamente las interfaces de los proveedores utilizando el mismo modelo, el valor se está desplazando hacia la orquestación. Ese resultado debilitaría la creencia de que el progreso de los modelos absorbe de forma natural la mayor parte de la diferenciación de producto.
Si las diferencias de rendimiento se reducen entre harnesses bien diseñados, la tesis de OpenAI gana respaldo. Sugeriría que los modelos más potentes necesitan menos intervenciones especializadas y pueden operar mediante entornos más simples y estandarizados.
La segunda señal es cómo Anthropic y OpenAI simplifican sus propios sistemas después de cada lanzamiento de modelo. Anthropic ya ha mostrado una versión de esta prueba al eliminar la descomposición por sprints de los flujos de trabajo de Opus 4.6.
Observe qué componentes desaparecen después. La planificación, los reinicios de contexto, la evaluación independiente y las aprobaciones frecuentes representan cada uno una hipótesis diferente sobre los límites del modelo.
Eliminar un componente sin reducir la calidad de la tarea refuerza el caso del harness más ligero. Trasladar ese componente a una clase de trabajo más difícil respalda la interpretación de Anthropic sobre una frontera móvil.
La tercera señal es la adopción fuera de la ingeniería de software. Los agentes de programación se benefician de repositorios, pruebas y retroalimentación digitalizada. El trabajo del conocimiento contiene señales más débiles y preferencias más implícitas.
Un agente guiado por el modelo parecerá convincente si las personas aceptan el trabajo completado sin correcciones extensas. Un harness colaborativo parecerá más sólido si los usuarios necesitan sistemáticamente vistas previas, comparaciones y puntos de aprobación.
La métrica de adopción más útil no será el número de tareas iniciadas. Será la proporción completada correctamente después de tener en cuenta la revisión humana y el retrabajo.
Los desarrolladores también deberían seguir la gravedad de los fallos. Un harness que completa menos tareas pero se detiene de forma segura puede ser preferible a uno que termina más mientras comete errores difíciles de detectar.
Los compradores empresariales deberían exigir evaluaciones con sus documentos, permisos y flujos de trabajo. Las clasificaciones públicas no pueden representar definiciones de corrección específicas de cada organización.
Los trabajadores del conocimiento pueden realizar una versión más simple de ese proceso. Empiecen con una tarea familiar y reversible, y comparen el resultado del agente con una referencia humana establecida.
Registren dónde el modelo carecía de contexto, eligió la herramienta equivocada o necesitó orientación subjetiva. Estas observaciones revelan si la siguiente intervención corresponde a instrucciones, recuperación de información, reglas de aprobación o revisión independiente.
El debate sobre los harnesses de OpenAI y Anthropic no terminará con una empresa eligiendo una capa ligera y la otra construyendo una más robusta. Ambas ya están añadiendo y eliminando componentes a medida que cambian los modelos y las tareas.
La ventaja duradera será para los equipos capaces de medir esos cambios con rapidez. Sabrán qué restricciones siguen evitando fallos y cuáles simplemente preservan supuestos de un modelo anterior.
Para quienes despliegan agentes, la acción inmediata es sencilla: prueben conjuntamente el modelo y el harness, inspeccionen trazas reales y definan qué significa el éxito antes de conceder una autonomía más amplia. Los modelos más potentes modifican el límite de la ingeniería, pero no eliminan la necesidad de localizarlo.
