En febrero de 2026, OpenAI publicó una entrada en su blog que, de forma silenciosa, redefinió lo que los ingenieros de software realmente hacen todo el día. El título constaba de solo tres palabras en español: "Ingeniería de Entornos" ( Harness Engineering ) .

El artículo describe cómo un pequeño equipo logró implementar un millón de líneas de código de producción sin escribir una sola línea a mano.

En su lugar, diseñe el entorno dentro del cual trabajaron sus agentes de inteligencia artificial: las restricciones, los bucles de retroalimentación, la estructura de la documentación y las reglas de dependencia. Los agentes escribieron el código; los humanos diseñaron el sistema que hizo que esos agentes fueran confiables.

En cuestión de semanas, Anthropic publicó tres artículos de ingeniería independiente (entornos efectivos, diseño de entornos y agentes gestionados) sobre el mismo concepto. ThoughtWorks formalizó un marco de trabajo, Red Hat escribió guías de implementación y Philipp Schmid, de Hugging Face, lo llamó "la disciplina más importante de 2026".

Una nueva disciplina de ingeniería se había materializado en tan solo 90 días.

Y ya está evolucionando más rápido de lo que cualquiera esperaba. Ayer mismo, Anthropic lanzó Opus 4.7, su tercera generación de modelos en menos de un año. Cada generación no solo mejoró el modelo, sino que simplificó el entorno de control. Componentes que eran pilares fundamentales en marzo se convirtieron en peso muerto para abril.

La disciplina tiene apenas 90 días de vida y ya está reescribiendo sus propias reglas.

Las cifras explican la urgencia.

LangChain ejecutó el mismo modelo en Terminal Bench 2.0 dos veces: una con su entorno antiguo y otra con el nuevo. Mismo modelo, diferente entorno. El puntaje saltó del 52,8% al 66,5%.

Vercel tomó el camino opuesto y eliminó el 80% de las herramientas de su agente. ¿El resultado? Un mejor rendimiento. Menos herramientas, restricciones más estrictas y resultados más sólidos.

Si 2025 fue el año en que los agentes de IA demostraron que podían escribir código, 2026 es el año en que descubrimos que el agente nunca fue la parte difícil. Lo difícil es el entorno de control ( arnés ).

Pero aquí es donde este momento se pone genuinamente interesante: han surgido tres corrientes principales con ideas esencialmente diferentes sobre lo que debería hacer un entorno de control. Están de acuerdo en el problema, pero no en la arquitectura. Y la elección entre ellas no es una simple discusión académica; determina cuánto vas a gastar, cuántos ingenieros vas a necesitar y si tus agentes producirán software funcional o alucinaciones costosas.

Este artículo analiza en detalle estos tres enfoques, te muestra cómo se ve cada uno en la práctica y te ofrece un marco de decisión para elegir el adecuado.

Qué es realmente un entorno de control ( Harness )

La definición más simple proviene de Sunit Parekh, de ThoughtWorks, en su artículo "Beyond Vibe Coding" (Más allá de programar por intuición):

$$\text{Agente} = \text{Modelo} + \text{Entorno de control}$$

El entorno de control es todo aquello que no es el modelo en sí. Son las restricciones que mantienen al agente en el camino correcto, los bucles de retroalimentación que detectan errores, la documentación que le indica al agente dónde está y qué se ha hecho hasta el momento, y las herramientas que tiene permiso para usar. Si quitas el entorno de control, lo que te queda es un modelo de lenguaje puro adivinando el camino a seguir en tu código base. Si agregas el entorno de control adecuado, obtendrás un sistema que produce código listo para producción.

El equipo de OpenAI recurrió a una metáfora ecuestre cuando le dio nombre en inglés ( Harness significa arnés o aparejo). Se trata de las riendas, la silla y el freno que guían a un animal poderoso pero impredecible en una dirección útil. No haces que el caballo sea más inteligente; diseñas el equipo que hace que su fuerza sea de utilidad.

Philipp Schmid ofreció una analogía más técnica que vale la pena interiorizar. Piénsalo como una computadora: el modelo es el procesador o CPU (la potencia bruta de procesamiento), la ventana de contexto es la memoria RAM (una memoria de trabajo limitada y volátil), el entorno de control es el sistema operativo (que gestiona qué ve la CPU y cuándo), y el agente es la aplicación que se ejecuta sobre todo ello.

Si tienes experiencia en finanzas o gestión de riesgos, hay una forma aún más directa de verlo: un entorno de control es un marco de cumplimiento. Es el conjunto de políticas, puntos de control y pistas de auditoría que garantizan que un sistema autónomo opere dentro de límites aceptables. Los equipos de cumplimiento normativo han estado construyendo esto durante décadas; el mundo de la IA simplemente le dio un nuevo nombre.

Cómo se ven estos elementos en la práctica

La mayoría de los artículos definen los entornos de control de forma abstracta y se despliegan ahí. Eso no es suficiente. Si vas a construir uno, necesitas ver cómo son las piezas en la realidad. Estos son los elementos clave que aparecen en casi todas las implementaciones importantes:

  • Archivos AGENT.md/ CLAUDE.md(un patrón universal con diferentes nombres): Son archivos en formato Markdown distribuidos por todo el código base que el agente lee al inicio de cada sesión. El equipo de Codex en OpenAI los llama AGENT.md, Claude Code de Anthropic los llama CLAUDE.mdy Cursor utiliza .cursorrules. El nombre cambia, pero el principio es el mismo. Contienen el contexto del proyecto, las convenciones de programación, las decisiones de arquitectura y las guías de "cómo hacemos las cosas aquí". El equipo de Sora Android en OpenAI mantuvo estos archivos en todo el repositorio. El agente los lee como si fuesen los documentos de inducción de un nuevo ingeniero que se une al equipo a mitad de un sprint . Se usa un archivo por cada módulo principal y se actualiza a medida que el proyecto evoluciona.
Ejemplo de un archivo AGENT.md- Módulo de Autenticación

Arquitectura

  • Flujo OAuth2 con PKCE, tokens almacenados en SharedPreferences encriptados.
  • Nunca almacene tokens en texto plano. Nunca registre los valores de los tokens en los logs.

Convenciones

  • Todos los errores de autenticación se gestionan a través de AuthErrorHandler.
  • Lógica de reintentos: 3 intentos con respaldo exponencial.

Estado Actual

  • Migración en progreso del formato de token v1 al v2 (ver número 247).

Listas de funciones en formato JSON (patrón de Anthropic): Cuando un agente construye una aplicación completa a lo largo de múltiples sesiones, cada nueva sesión comienza con una ventana de contexto en blanco. ¿Cómo sabe el agente qué está hecho y en qué trabajar a continuación? La respuesta de Anthropic es un archivo JSON que sirve tanto de especificación del proyecto como de seguidor de progreso. Cada entrada define una funcionalidad, sus pasos de verificación y un estado de aprobado o fallido. Para su demostración del clon de claude.ai, esta lista llegó a tener más de 200 funciones individuales, y todas comenzaban en estado "fallido".

El agente lee este archivo al principio de cada sesión, elige la función fallida de mayor prioridad, la implementa, la verifica con los pasos de prueba, la marca como "aprobada" y guarda los cambios ( commit ). Es una suite de pruebas y un tablero de proyectos unificados en un solo archivo, legible tanto por humanos como por agentes.

JSON

{
  "category": "authentication",
  "feature": "Restablecimiento de contraseña por correo electrónico",
  "verification": [
    "Hacer clic en 'Olvidé mi contraseña' en la página de inicio de sesión",
    "Ingresar el correo electrónico registrado",
    "Verificar la recepción del correo de restablecimiento en menos de 30 segundos",
    "Hacer clic en el enlace de restablecimiento e ingresar la nueva contraseña",
    "Confirmar que el inicio de sesión con la nueva contraseña es exitoso"
  ],
  "status": "failing"
}

¿Por qué se usa JSON y no Markdown? Anthropic descubrió que los modelos tienen "menos probabilidades de modificar o sobrescribir incorrectamente los archivos JSON en comparación con los de Markdown". Es un detalle pequeño, pero importante mucho cuando el agente trabaja de forma autónoma durante horas.

Rutinas de inicialización de sesión (patrón de Anthropic): Cada sesión de programación sigue la misma secuencia de inicio de 7 pasos: confirmar el directorio de trabajo, leer los historiales de Git y los archivos de progreso, consultar la lista de funciones para ver cuál es la tarea incompleta de mayor prioridad, iniciar el servidor de desarrollo, ejecutar una verificación básica de extremo a extremo, implementar esa única función y, finalmente, guardar los cambios con mensajes descriptivos y actualizaciones de progreso.

Esto no es opcional. Sin esta rutina, cada nueva sesión comenzaría desde cero y el agente perdería los primeros 20 minutos intentando descifrar qué se ha hecho hasta el momento.

  • Plantillas de tareas estructuradas (patrón de Red Hat): Antes de empezar a programar, el entorno de control analiza el código base real utilizando herramientas de análisis de código y servidores de lenguaje para producir un mapa de impacto preciso. Luego, genera una plantilla de tareas con rutas de archivos reales, nombres de símbolos reales, patrones existentes que se deben seguir y criterios de aceptación concretos. Sin suposiciones ni rutas de archivos inventadas.
  • Contratos de Sprint (patrón de Anthropic): Antes de que el agente generador comience a escribir código, negocia con un agente evaluador. El generador propone qué va a construir y cómo se verificará el éxito. El evaluador revisa la propuesta para asegurarse de que esté completa. Solo cuando ambos están de acuerdo comienza la implementación. Es una versión ligera de la revisión de diseño que los buenos equipos de ingeniería ya realizan, con la diferencia de que ambos participantes son agentes de IA.

El factor común

Si observamos estos elementos en conjunto, surja un patrón claro. Cada uno de ellos está diseñado para responder a la misma pregunta: "¿Qué necesita saber el agente antes de escribir una sola línea de código?"

Y la respuesta resulta ser: mucho. Necesita saber en qué parte del código base se encuentra, qué se ha hecho ya, qué se considera un "buen trabajo", qué áreas están fuera de los límites y cómo verificar su propio resultado. Eso no es inteligencia; es contexto. Y el contexto, al fin y al cabo, es el verdadero producto de la ingeniería de entornos.

Las Tres Corrientes Principales

El término "ingeniería de entornos" no nació de un comité ni de una conferencia magistral. Tres grupos se encontraron con la misma pared de forma independiente y cada uno construyó una escalera diferente para superarla.

1. OpenAI: "Teníamos un millón de líneas que nadie había escrito"

El equipo de Codex de OpenAI se enfrentaba a un problema de una escalada casi absurda. Estaban construyendo una aplicación de producción y los agentes estaban escribiendo la totalidad de la misma. No una parte; hacer. Un millón de líneas de código, cero escritas por manos humanas.

A esa escala, el enfoque tradicional de revisar cada línea de código deja de ser viable. No se pueden revisar un millón de líneas a mano. Lo que sí se puede hacer es diseñar el entorno de forma tan minuciosa que los agentes produzcan, de entrada, resultados que sean fáciles de auditar.

Su lección principal, aprendida de la manera difícil, fue: Dale al modelo un mapa, no un manual de instrucciones de mil páginas.

Establecieron flujos de dependencia estrictos (Tipos, luego Configuración, Repositorio, Servicio, Tiempo de ejecución y, finalmente, Interfaz de usuario) y los aplicaron mediante pruebas estructurales. Distribuyeron archivos AGENT.mdpor todo el código base como documentación y conectaron a los agentes directamente a las canales de integración y despliegue continuo (CI/CD) para que cada cambio se probara automáticamente.

La filosofía aquí es diseñar el entorno y luego dejar que el agente trabaje libremente dentro de él. El rol del ser humano es el de arquitecto, no el de programador.

La prueba de que funcionaba llegó con el desarrollo de Sora para Android. Cuatro ingenieros, 28 días y cerca de 5000 millones de tokens consumidos después, la aplicación alcanzó el puesto número 1 en la Play Store con una tasa del 99.9% libre de fallos ( crashes ). Codex gestionaba el 70% de las solicitudes de cambios ( pull request ) internas cada semana. Los ingenieros dedicaron su tiempo a la arquitectura de alto nivel, la planificación y la verificación; el agente hacía el resto.

2. Antrópico: "Nuestros agentes no paraban de elogiar su propio trabajo defectuoso"

El problema de Anthropic era más sutil y, en ciertos aspectos, más complejo. Estaban construyendo agentes de larga duración que necesitaban producir aplicaciones completas a lo largo de varias horas de trabajo autónomo. El modelo era bastante capaz, pero el problema reside en el control de calidad.

Cuando le pedían al agente que evaluara su propio resultado, este elogiaba con total seguridad su propio trabajo, incluso cuando, para un observador humano, la calidad era evidentemente mediocre. La autoevaluación no funcionaba; el agente era el alumno y el maestro a la vez, y se estaba calificando a sí mismo con la nota máxima.

Su solución se inspiró en las Redes Generativas Antagónicas (GAN): separar la parte que hace el trabajo de la que lo juzga. Esto dio lugar a una arquitectura de tres agentes:

  1. Un Planificador: Expande instrucciones cortas en especificaciones detalladas del producto.
  2. Un Generador: Implementa las funciones una etapa o sprint a la vez.
  3. Un Evaluador: Utiliza herramientas de automatización del navegador para interactuar con la aplicación activa como si fuera un usuario real, calificando cada entrega según criterios explícitos.

El hallazgo clave fue que resultaba mucho más viable entrenar a un evaluador independiente para que fuera escéptico que lograr que un generador fuera crítico con su propio trabajo.

No se detuvieron ahí. La arquitectura evolucionó de un sistema de dos agentes a uno de tres, y luego a un sistema completamente desacoplado que llaman "agentes gestionados", donde el cerebro (el modelo), el entorno de ejecución y el registro de la sesión son componentes independientes y reemplazables. Ese desacoplamiento redujo el tiempo para recibir el primer token en un 60% en el percentil 50 (P50) y en más de un 90% en el percentil 95 (P95).

La filosofía en este caso es: separa al ejecutor del juez, y haz que el juez sea difícil de impresionar.

3. ThoughtWorks: "Víamos los mismos fallos en 50 equipos de clientes diferentes"

ThoughtWorks llegó a la ingeniería de entornos desde un punto de partida totalmente distinto. Ellos no estaban construyendo un producto propio; Estaban observando cómo docenas de equipos de ingeniería en diversas industrias intentaban adoptar agentes de IA, y veían los mismos patrones de fracaso en todas partes.

Birgitta Böckeler, una ingeniería destacada con más de 20 años de experiencia, publicó en abril de 2026 el marco de trabajo más completo de los tres. Mientras OpenAI creaba un sistema y Anthropic una arquitectura, ThoughtWorks desarrolló una taxonomía.

Su marco clasifica los controles del entorno en dos ejes. El primer eje divide los controles entre preactivos ( feedforward , guías que anticipan el comportamiento del agente antes de la ejecución) y retroactivos ( feedback , sensores que observan los resultados y permiten la autocorrección). Ninguno funciona por separado: usar solo retroalimentación provoca errores repetitivos, y usar solo guías preactivas impide validar si las instrucciones realmente funcionan.

El segundo eje divide los controles en computacionales (verificaciones deterministas como los analizadores de código o linters , verificadores de tipos y suites de pruebas que se ejecutan en milisegundos) e inferenciales (análisis semántico realizado por otro modelo de lenguaje, que es más lento y costoso pero detecta cosas que el análisis de código tradicional pasa por alto).

A partir de ahí, organiza todo en tres categorías de regulación:

  • Mantenibilidad: La más madura, donde las herramientas de cobertura y análisis ya funcionan muy bien.
  • Adecuación arquitectónica: Para asegurar el cumplimiento de los patrones de diseño y los requisitos de rendimiento.
  • Comportamiento: La más difícil, donde se intenta verificar que el agente realmente hizo lo que se le pidió y no solo que el código se compile correctamente.

La filosofía aquí es: clasificar, sistematizar y dar a los equipos un vocabulario compartido para lo que están construyendo.

¿Por qué tomaron caminos diferentes?

Las tres corrientes crearon soluciones distintas porque partieron de problemas diferentes. OpenAI necesitaba lanzar productos a gran escala, Anthropic requería calidad en agentes autónomos y ThoughtWorks buscaba un marco de trabajo que sirviera para cualquier equipo, independientemente del agente o modelo que utilizaran.

Vale la pena recordar esto al evaluar qué enfoque se adapta mejor a tu situación. La pregunta no es cuál de las corrientes tiene la razón, sino cuál es el problema específico que tú necesitas resolver.

Comparativa de las Tres Arquitecturas

Ya conocemos el origen de cada corriente. Veamos ahora qué construyeron exactamente y, lo que es más importante, dónde falla cada arquitectura.

1. OpenAI/Codex: El entorno centrado en el ecosistema

El entorno de Codex funciona mejor cuando puedes hacer una gran inversión inicial en el diseño del espacio donde trabajarán tus agentes. La recompensa es una enorme autonomía posterior, pero el costo de configuración es considerable.

  • Cómo funciona: El entorno es el propio código base. Los archivos AGENT.mdaportan el contexto, las pruebas estructurales imponen las reglas arquitectónicas de forma mecánica y los flujos de trabajo en las canalizaciones de CI/CD validan cada cambio de manera automática. El agente trabaja de forma muy autónoma: abre solicitudes de cambios, responde a los comentarios de revisión, ejecuta pruebas, corrige fallos y realiza la integración cuando se cumplen los criterios. Los humanos no revisan cada línea de código; revisen las reglas que hacen que el código sea auditable.
  • Puntos fuertes: Proyectos de gran envergadura. Si gestionas un código base con cientos de millas de líneas, este enfoque escala muy bien porque los límites están integrados en la estructura del propio repositorio. Si añades un módulo nuevo con su correspondiente AGENT.md, el agente puede empezar a trabajar en él sin configuraciones adicionales. OpenAI estimó que lanzaron funciones en la décima parte del tiempo que habrían tomado programarlas a mano.
  • Puntos débiles: Da por sentado que puedes definir el entorno por completo antes de que el agente comience a trabajar. En proyectos que empiezan desde cero, donde la arquitectura aún se está definiendo, esto es complicado. Además, depende de muchas pruebas estructurales que verifiquen si el código es correcto, pero no si el diseño es bueno. Una función puede pasar todas las pruebas y seguir siendo una pésima opción de diseño.

2. Antrópico: El entorno multiagente

El enfoque de Anthropic cuesta más dinero por cada ejecución, pero detecta problemas que el modelo centrado en el ecosistema pasa por alto. Es una balanza entre calidad y velocidad; para aplicaciones donde un error en producción es más costoso que un proceso de desarrollo lento, es una opción que vale la pena evaluar.

Cómo funciona: Emplea tres agentes especializados. El Planificador toma una instrucción corta del usuario (de una a cuatro frases) y la transforma en una especificación completa del producto, enfocándose en los entregables y el diseño general, evitando detalles de implementación minuciosos que podrían encadenar errores. El Generador implementa las funciones una a una utilizando tecnologías estándar (como React, Vite, FastAPI, SQLite/PostgreSQL) y se evalúa a sí mismo antes de entregar el trabajo. El Evaluador usa automatización de navegadores (con herramientas como Playwright) para interactuar con la aplicación real, probando interfaces, puntos de conexión de API (endpoints) y estados de bases de datos.

Antes de empezar, el Generador y el Evaluador acuerdan un "contrato de sprint" que define qué se va a construir y cómo se medirá el éxito. Además, la capa de agentes gestionados desactiva el cerebro (el modelo y su entorno), las manos (los entornos de ejecución seguros o sandboxes ) y la sesión (un registro de eventos permanente). Si el cerebro falla, se recupera con el registro; si el entorno seguro falla, se reporta como un error de herramienta. Las credenciales de acceso nunca llegan a los entornos seguros donde se ejecuta el código del agente.

  • Puntos fuertes: Aplicaciones que exigen un alto nivel de calidad y precisión. El evaluador nota detalles que las pruebas automáticas no ven: elementos de la interfaz que aparecen en pantalla pero no se pueden usar, flujos de trabajo poco intuitivos o respuestas de API con datos correctos pero en formatos inadecuados. Las pruebas de Anthropic demostraron que un agente trabajando solo ($9 dólares, 20 minutos) entregaba una aplicación defectuosa, mientras que el entorno completo ($200 dólares, 6 horas) lograba software completamente funcional y con interfaces cuidadas.
  • Puntos débiles: Costo y tiempo. Este sistema es mucho más caro que usar un solo agente, y el evaluador requiere de mucho ajuste en sus instrucciones. Al principio, tiende a detectar fallos reales pero termina justificándolos para dar el visto bueno. Conseguir que sea verdaderamente estricto requirió varios ciclos de desarrollo.

La buena noticia es que a medida que los modelos mejoran, el entorno se simplifica. La versión basada en Opus 4.6 eliminó la división de sprints y pasó a una evaluación de un solo paso, reduciendo los costos de manera significativa en comparación con la versión anterior. Con el lanzamiento de Opus 4.7, esta tendencia se aceleró: ahora el modelo idea sus propias formas de verificar los resultados antes de reportar, escribe código más limpio y genera una tercera parte de los errores de herramientas que solía producir. Cada nueva generación reduce las tareas del evaluador.

3. ThoughtWorks: El entorno basado en taxonomía

ThoughtWorks no diseñó un sistema listo para instalar; Creó una forma de pensar sobre los entornos de control para que puedas diseñar el tuyo propio. Es el camino más útil si no estás usando las herramientas específicas de Codex o Claude, aunque requiere más trabajo para ponerlo en marcha.

Cómo funciona: Cada control se clasifica en dos dimensiones (Guía/Sensor y Computacional/Inferencial), lo que genera una matriz de cuatro cuadrantes:

  1. Guías computacionales (Preactivos): Sistemas de tipos, analizadores de código ( linters ), registros de decisiones arquitectónicas.
  2. Sensores computacionales (Retroactivos): Suites de pruebas, análisis de cobertura, pruebas de mutación.
  3. Guías inferenciales (Preactivos): Documentos de especificaciones, instrucciones de diseño, descripción de restricciones.
  4. Sensores inferenciales (Retroactivos): Revisores de código basados ​​en modelos de lenguaje, evaluadores de calidad semántica.Estos controles se distribuyen a lo largo del ciclo de vida del desarrollo: antes de la integración (revisiones rápidas y económicas), en la canalización posterior a la integración (validación completa), detección continua de desviaciones (monitoreo en segundo plano) y retroalimentación en tiempo de ejecución (alertas de objetivos de nivel de servicio).

Puntos fuertes: Equipos con proyectos y bases de código ya establecidos. Si ya cuentas con analizadores de código, pruebas y canalizaciones de CI/CD, este marco te ayuda a ver que ya tienes la mitad del camino recorrido. Te indica qué piezas te faltan y dónde te conviene invertir. También introdujo el concepto de "facilidad de entorno" ( Harnessability ): los lenguajes fuertemente tipados, las fronteras claras entre módulos y los marcos de trabajo bien estructurados hacen que el trabajo de los agentes sea mucho más exitoso.

También propusieron plantillas de entornos: conjuntos estandarizados de guías y sensores para tipos de servicios comunes. Si el 80% de tus servicios son API básicos de lectura y escritura (CRUD), creas una plantilla de entorno para ellas y la reutilizas, reduciendo notablemente los costos por servicio.

  • Puntos débiles: Es un modelo descriptivo, no prescriptivo. Te dice qué tipos de controles existen, pero no qué herramientas usar ni cómo conectarlas. Es un plano arquitectónico, no el edificio terminado. Para equipos que buscan una solución rápida de instalación, este enfoque requiere desarrollo propio. Su categoría de regulación de comportamiento también es un punto débil: verificar que el código sea mantenible es sencillo con las herramientas actuales, pero compruebe que el agente hizo exactamente lo que se le pidió sigue dependiendo demasiado de pruebas generadas por la propia IA, algo que ThoughtWorks admite que aún es insuficiente.

Lo que Revela el Análisis Profundo

Si quitamos las diferencias de implementación, surge algo sorprendente: tres equipos que nunca coordinaron entre sí, trabajando en problemas diferentes, llegaron a los mismos cinco principios fundamentales. Este tipo de coincidencia independiente suele indicar que se ha descubierto una verdad sólida.

Los 5 principios de convergencia descubiertos por las tres corrientes

1. El contexto supera a las instrucciones
2. Separar planificación de ejecución
3. Bucles de retroalimentación obligatorios
4. Avanzar paso a paso (Incrementalismo)
5. El código base es la documentación
  1. El contexto supera a las instrucciones: OpenAI aprendió a dar "un mapa, no un manual". Anthropic creó listas de funciones en JSON para que los agentes sepan dónde están. El flujo de Red Hat analiza el código base real antes de generar tareas. ThoughtWorks lo llama control "preactivo". El nombre cambia, pero el descubrimiento es el mismo: mostrarle al agente el estado real del proyecto (rutas de archivos reales, patrones de código existentes, progreso actual) funciona mucho mejor que darle instrucciones abstractas. Un agente con buen contexto genera código que encaja; un agente con instrucciones vagas inventa rutas y servicios que no existen.
  2. La planificación y la ejecución deben ir por separado: OpenAI separa el diseño del entorno (humano) de la generación de código (agente). Anthropic asigna un agente Planificador antes de que el Generador toque el código. ThoughtWorks exige un punto de control humano entre la planificación y la implementación. Red Hat divide el trabajo en Fase 1 (mapa de impacto) y Fase 2 (implementación). Todos descubrieron que permitir que un agente plano y ejecutar en el mismo paso produzca resultados inestables. Tienen que ser pasos separados y el plan debe revisarse antes de programar.
  3. Los bucles de retroalimentación no son negociables: OpenAI conecta a los agentes a sistemas de CI/CD y monitoreo. Anthropic usa un agente evaluador que navega por la aplicación. ThoughtWorks los llama "sensores" y advierte que las guías sin validación no permiten saber si las instrucciones sirven. La diferencia no está en si se necesita retroalimentación, sino en quién la da. OpenAI usa pruebas automáticas y CI; Antrópico usa otro modelo de lenguaje; ThoughtWorks sugiere usar ambos de forma combinada (primero la computacional por rápida y barata, luego la inferencial por su análisis semántico). Un entorno sin retroalimentación es solo una instrucción optimizada.
  4. Una sola cosa a la vez: OpenAI divide los objetivos en bloques pequeños y trabaja a fondo. Anthropic obliga a procesar una sola función por sprint, guardando los cambios tras finalizarla. ThoughtWorks describe un ciclo de vida por fases. Los agentes que intentan hacer demasiado a la vez se quedan sin espacio de contexto, pierden el hilo o ignoran los requisitos de forma silenciosa. El avance progresivo y controlado es universal para el éxito de estos entornos.
  5. El código base es la documentación: OpenAI coloca archivos AGENT.mden el repositorio. Anthropic usa el historial de Git y archivos de progreso como memoria del agente. ThoughtWorks mide la legibilidad del código base para la IA. Red Hat recomienda llevar a cabo todas las convenciones al control de versiones. Nadie mantiene una base de conocimientos externos para el agente; el repositorio es la única fuente de verdad. Si una regla o decisión de arquitectura no está en el código, el agente no la conocerá. Los equipos que invierten en organizar su código y documentar su repositorio mejoran el rendimiento de sus agentes de forma automática.

Estos cinco principios no son opiniones; son realidades de la ingeniería que tres equipos descubrieron a base de aciertos y errores. Si vas a diseñar un entorno de control desde cero, empieza por aquí. Violar estos principios tendrá un costo elevado, sin importar las herramientas que elijas.

El Costo de Hacerlo Bien

La ingeniería de entornos requiere inversión. Cada enfoque implica un equilibrio entre la configuración inicial, el costo de ejecución y el mantenimiento continuo.

Lo que sabemos: La prueba A/B de Anthropic

Anthropic publicó una de las comparativas de costos más claras que existen al procesar la misma instrucción para una aplicación de dos formas:

  • Agente solo (sin entorno de control): Costó $9 dólares y tomó 20 minutos . El resultado fue una interfaz de usuario atractiva, pero las funciones principales estaban rotas; los elementos no respondían a las acciones del usuario. Se veía bien en capturas de pantalla, pero no funcionaba.
  • Entorno de control completo (con Opus 4.5): Costó $200 dólares y tomó 6 horas . El resultado fue una serie de juegos completamente funcionales, con interfaces cuidadas, una identidad visual consistente y dinámicas correctas.

Estamos hablando de un costo 22 veces mayor para obtener un producto funcional en lugar de una simple demostración visual. Que esto sea caro o barato dependerá enteramente de lo que le cueste a tu equipo lanzar una función defectuosa a tus usuarios.

El beneficio de la mejora de los modelos.

Aquí es donde el panorama se vuelve interesante. Cuando Anthropic pasó de Opus 4.5 a Opus 4.6, pudo simplificar el entorno de control destacado. Eliminaron la división de sprints y la evaluación de un solo paso sustituyó a la clasificación por etapas.

El resultado fue una aplicación de estación de trabajo de audio digital (DAW) completa por $124,70 dólares en 3 horas y 50 minutos . Esto representa una reducción del 38% en el costo y del 36% en el tiempo de desarrollo gracias a las mejoras del propio modelo. El entorno tuvo que hacer menos trabajo porque el modelo requería menos ayuda.

Esta tendencia continúa acelerándose. Opus 4.7 (lanzado el 16 de abril de 2026) amplió esta línea: los puntajes en CursorBench subieron del 58% al 70%, y en Rakuten-SWE-Bench se resolvieron tres veces más tareas de producción. El modelo logró una mejora del 14% sobre Opus 4.6 consumiendo menos tokens, lo que significa menos costos indirectos del entorno por cada unidad de resultado útil. Tres generaciones de modelos trajeron tres rondas de simplificación del entorno. Es una tendencia clara.

Sin embargo, esto no elimina la necesidad de contar con un entorno de control. El evaluador de Opus 4.6 siguió detectando ausencias importantes en la aplicación musical (controles de línea de tiempo faltantes, paneles de interfaz ausentes y errores de grabación). De no haber estado allí, esas funciones se habrían entregado incompletas o rotas. El entorno de control se reduce con cada generación de modelos, pero aún no desaparece.

El costo oculto: El mantenimiento

El factor del que pocos hablan es el mantenimiento. Un entorno de control no se construye una sola vez y ya; es un compromiso de ingeniería constante.

La empresa Manus rediseñó su entorno de control cinco veces en seis meses. LangChain reestructuró su agente de investigación tres veces en un año. Esto no es reflejo de una mala ingeniería, sino la consecuencia natural de construir sobre modelos que mejoran a un ritmo vertiginoso. Cada vez que el modelo evoluciona, alguna pieza de tu entorno de control se vuelve innecesaria, y descubrir cuál de ellas es requiere pruebas constantes.

El consejo de Philipp Schmid al respecto es: "Construye pensando en eliminar". Diseña cada componente de tu entorno de control de manera que pueda ser retirado. Pruebe los componentes apagándolos periódicamente y midiendo si la calidad del resultado cambia. Si no cambia, elimínalo. Mantener componentes obsoletos consume tokens en cada ejecución y añade una carga de mantenimiento que no aporta ningún beneficio.

Un marco de trabajo para tomar decisiones.

En lugar de definir un presupuesto fijo para cada corriente, te sugerimos esta guía para elegir el enfoque que mejor se adapta a tu situación actual:

  • Si eres un desarrollador independiente o un equipo pequeño en etapas iniciales: Comienza colocando archivos AGENT.mdo CLAUDE.mden tu repositorio junto con una buena canalización de CI/CD. Este es el patrón de OpenAI en su forma más simple: costo bajo y beneficios inmediatos. Es muy probable que ya tengas la mayoría de las piezas instaladas.
  • Si construye un producto donde los fallos de calidad impactan directamente a los usuarios: Agregue bucles de evaluación. No necesitas implementar la arquitectura completa de tres agentes de Anthropic; incluso un paso sencillo de revisión posterior al desarrollo, utilizando un segundo modelo para verificar el trabajo del primero, ayuda a detectar errores que las pruebas tradicionales pasan por alto. El principio de separar al ejecutor del juez funciona muy bien a cualquier escala.
  • Si gestionas múltiples equipos que están adoptando agentes en una empresa grande: Invierte en la taxonomía de ThoughtWorks. Ubica tus controles actuales (analizadores de código, pruebas, CI) en la matriz de controles preactivos/retroactivos y computacionales/inferenciales. Identifica los vacíos y diseña plantillas de entornos para tus servicios más comunes. Esto debe tratarse como infraestructura de la organización, no como una decisión por cada proyecto.
  • Si trabajas en una industria regulada: Considera el entorno de control como tu marco de cumplimiento normativo, ya que eso es lo que los auditores eventualmente van a revisar. El registro de eventos permanente de la arquitectura de Anthropic no solo es buena ingeniería; es una pista de auditoría ideal. Asimismo, las plantillas de tareas estructuradas del enfoque de Red Hat generan documentación que se alinea con los requisitos de cumplimiento. Es mejor empezar a planificar esto ahora que esperar a que los auditores lo soliciten.

La Paradoja: Construir para eliminar

Hay una realidad compleja detrás de los datos de Anthropic de la que ninguna de las tres corrientes habla con demasiada frecuencia.

Cuando actualizaron sus sistemas de Opus 4.5 a Opus 4.6, no solo obtuvieron mejores resultados, sino que lograron simplificar sus procesos. La división de sprints, que había sido indispensable para que Opus 4.5 mantuviera la coherencia en tareas largas, ya no era necesaria. El modelo se había vuelto lo suficientemente inteligente como para recordar su propio plan sin necesidad de que el entorno se lo recordara a cada momento.

Esto nos lleva a la paradoja central de la disciplina en 2026: El objetivo de la ingeniería de entornos es construir sistemas destinados a desaparecer.

Escribe código de control hoy para complementar las limitaciones del modelo actual. Sin embargo, en la siguiente actualización, el nuevo modelo ya habrá integrado esas capacidades de forma nativa. Si tu entorno de control se mantiene igual durante más de seis meses, significa que estás gastando dinero en tokens innecesarios y limitando la velocidad de tus agentes con reglas del pasado.

Los ingenieros de software del futuro no se dedicarán a escribir el código que va a producción. Su labor principal consistirá en diseñar los entornos de control para los agentes de IA, probar la eficiencia de esos entornos frente a los nuevos modelos del mercado y eliminar de forma constante el código de control que los modelos de lenguaje vayan dejando obsoleto. El software se escribirá de forma automática; Nuestra tarea será asegurar el entorno para que lo haga correctamente.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.