En 2009 me tocó trabajar con una empresa en California, Adaptive Insights. Lo primero que sorprendía no era su stack ni su velocidad de entrega, aunque tenían las dos cosas: testing automatizado con Selenium, TDD, unit testing, una máquina bien afinada. Lo que sorprendía era su wiki.

Ahí vivían las narrativas de valor del producto. Versión por versión, feature por feature. No un repositorio de documentación técnica: el lugar donde el equipo y el negocio escribían juntos qué estaban construyendo y por qué. Cuando alguien preguntaba qué significaba una funcionalidad, la respuesta no estaba en la cabeza de nadie. Estaba escrita, y estaba donde ambos podían leerla.

Por esos mismos años y por esos mismos rumbos apoye también a Electric Cloud, que hacía software de integración continua, y en 2013 vimos en Thoughtworks algo que se quedó grabado: un radiador de información, una pantalla en la pared de la mesa de trabajo de un equipo que le daba servicio a un banco del Wallstreet, que mostraba la salud del build y se ponía roja en el espacio del desarrollador que lo había roto. Nadie tenía que ir a buscar el dato. El dato iba hacia la persona.

Ninguna de esas tres prácticas era considerada innovación en su momento. Eran higiene. Y sin embargo, diecisiete años después, lo que esos equipos tenían resuelto sigue siendo lo que falta en la mayoría de las organizaciones que además, con mucha valentía, se lanzan hacia el llamado AI-First.

Un lenguaje que nunca terminamos de acercar

Hay una frase que en Latinoamérica se escucha en casi todas las salas donde se decide un proyecto de tecnología: eso es técnico, que lo decidan ellos.

Vale la pena ser justos con esa frase, porque al principio era cierta. La tecnología era efectivamente un lenguaje críptico, y durante décadas nadie hizo demasiado esfuerzo por acercarlo. Quien no manejaba los dos idiomas quedaba en una posición incómoda: opinar sobre lo que no entendía, o callarse. La mayoría eligió callarse, y esa elección se institucionalizó.

Esa distancia es vieja, y no se cerró sola. Quienes estudiamos ingeniería y después un MBA lo hicimos, muchas veces, exactamente por eso: porque el riesgo de no manejar ambos idiomas era decidir sobre supuestos inventados. La traducción existía, pero dependía de personas que la hacían de oficio.

Y ahí está el punto. Durante veinte años, delegar lo técnico fue caro pero absorbible, porque en cada cruce entre áreas había alguien que traducía. Alguien preguntaba. Alguien sabía que en Cobranzas “cliente activo” quería decir otra cosa. Alguien conocía el pasillo. El costo de la no participación del negocio se pagaba en retrabajo, en reuniones de aclaración, en indicadores que había que corregir a mano en una planilla todos los meses.

Lo que cambió no es la frase. Es el precio.

Lo que un agente no va a hacer

Un agente de inteligencia artificial ejecuta sobre la definición que encuentra. No pregunta, no infiere, no conoce el pasillo. Y cuando falta criterio, no se detiene como lo haría un empleado nuevo prudente: resuelve la ambigüedad con lo genérico, con lo que estadísticamente aparece más en todo lo que ha visto.

Esa es la diferencia que vuelve urgente un problema viejo. El traductor humano que absorbía el costo de la no participación del negocio ya no está en el cruce. Y las decisiones que antes se demoraban hasta que alguien preguntaba, ahora se toman solas, a velocidad de máquina y sin testigos.

Los números de la industria muestran la brecha con una claridad incómoda. Una investigación de académicos del MIT y Wharton, publicada en mayo de 2026, encontró que los agentes de código aumentaron la producción de código en 180%, mientras el software efectivamente entregado creció apenas 30%.

La capacidad de ejecutar se multiplicó. El resultado apenas se movió.

Esa distancia entre los dos números es la distancia entre ejecutar y juzgar. Y el juicio, en una organización, no es un problema técnico.

Quién corre el loop

Kief Morris, de Thoughtworks, propuso este año una distinción que ordena bastante la conversación. Separa dos ciclos en el desarrollo de software.

El primero es el ciclo del por qué: de la idea al software funcionando, iterando a medida que se aprende si eso resuelve algo. El segundo es el ciclo del cómo: el proceso de construir, iterando sobre artefactos intermedios como el código, las pruebas y las especificaciones.

Morris sostiene que el lugar del humano frente a los agentes no es ni afuera del segundo ciclo, aceptando lo que salga, ni adentro revisando cada línea, sino sobre él: construyendo y administrando lo que produce los artefactos. Y agrega algo que su artículo, escrito para desarrolladores, no termina de perseguir: el humano corre el ciclo del por qué porque es quien quiere lo que ese ciclo produce.

En una empresa, quien quiere lo que produce ese ciclo no es el desarrollador. Es el negocio.

De ahí el nombre que proponemos para lo que venimos trabajando: business-on-the-loop. No el negocio afuera, aprobando presupuestos y recibiendo demos. Tampoco el negocio adentro, revisando decisiones técnicas que no le corresponden. El negocio sobre el ciclo, sosteniendo las decisiones que solo él puede tomar.

El criterio tiene que estar escrito en alguna parte

Acá es donde la propuesta se separa de la buena intención.

La industria ya instaló una respuesta parcial bajo el nombre de ingeniería de contexto. Los repositorios serios incluyen hoy archivos versionados que le dicen al agente cómo trabajar en ese proyecto: comandos, convenciones, estructura, formas de verificar. Es, en la práctica, el onboarding permanente de la fuerza de trabajo digital.

Pero esos archivos codifican el cómo trabajar. No dicen una palabra sobre qué es bueno.

El archivo que casi ninguna organización ha escrito es el segundo: quién es el usuario y qué le duele, qué significa “bueno” en este producto, qué no construir aunque parezca obvio, cómo desempatar cuando la especificación calla. Ese archivo es el artefacto de business-on-the-loop, y no lo puede escribir el equipo técnico por delegación.

Tampoco lo puede escribir la máquina. Investigadores de ETH Zurich midieron que los archivos de contexto generados automáticamente por los propios modelos empeoran el desempeño de los agentes y encarecen su operación, mientras que solo los escritos por humanos que conocen de verdad el proyecto agregan valor.

Y hay una condición previa, la más vieja de todas. Eric Evans publicó Domain-Driven Design en 2003, y su tesis central es que el mayor valor de un modelo de negocio bien hecho es proveer un lenguaje ubicuo que une a los expertos del dominio con los técnicos. El instrumento de Domain-Driven Design nunca fue una arquitectura ni una tecnología. Fue el lenguaje. Durante veintitrés años eso fue un argumento de calidad, y por lo tanto postergable. Hoy ese lenguaje es, literalmente, lo que el agente lee para decidir.

El esqueleto del proceso

Lo que sigue no es un manual. Es la forma que ha ido tomando el trabajo, y ningún paso es invención nuestra: cada uno se apoya en algo que ya existe y que alguien más probó antes.

1. Acordar el lenguaje. Antes de escribir cualquier especificación, cuando el trabajo cruza fronteras de área. No hay que unificar definiciones para toda la empresa: hay que delimitar dónde vale cada una y hacer explícita la traducción en el cruce.
2. Escribir el criterio. Una página, no un manual. Reunir a las dos o tres personas que hoy cargan el criterio del producto en la cabeza y responder cuatro preguntas: para quién es esto, qué es bueno acá, qué no construimos, cómo se desempata cuando nadie está mirando.
3. Separar el contexto. Distinguir tres cosas que suelen ir mezcladas en un mismo pedido: las convenciones permanentes del proyecto, las instrucciones sobre cómo hacer cierta clase de tarea, y la especificación de lo que se construye ahora.
4. Construir.
5. Verificar por fuera. Un veredicto que el propio sistema emite sobre sí mismo no es evidencia suficiente.
6. Registrar. Qué se hizo, qué se apartó de lo acordado, qué quedó pendiente.
7. Ajustar los controles. Cuando un problema ocurre varias veces, no se corrige el resultado: se corrige lo que lo produjo.

Paso	En qué se apoya
Acordar el lenguaje	Lenguaje ubicuo y contextos delimitados, de Domain-Driven Design (Eric Evans, 2003). La técnica de taller es EventStorming (Alberto Brandolini, 2013), con negocio y técnicos juntos reconstruyendo el proceso hasta que aparecen las inconsistencias.
Escribir el criterio	El ejercicio “Es / No Es, Hace / No Hace” de Lean Inception (Paulo Caroli) recorre este tipo de definición.
Separar el contexto	La distinción entre convenciones, instrucciones y especificación, de Birgitta Böckeler (Thoughtworks). Su recomendación: construir el contexto gradualmente y no cargarlo en exceso por adelantado.
Verificar por fuera	Regla propia, aprendida a golpes: en nuestro trabajo un experimento reportó un fallo que no existía, y de haberlo creído habríamos rediseñado una aplicación entera sobre una premisa falsa.
Registrar	Distinción que importa: registrar qué pasó lo puede hacer un agente. Escribir el criterio, no.
Ajustar los controles	El ciclo de dirección de Böckeler, y el mecanismo concreto de lo que Kief Morris llama estar sobre el ciclo. Es el paso menos automatizado de todos: una persona mirando qué se repite.

Sobre el resto de las prácticas técnicas, que existen y son necesarias, vale una advertencia. Pruebas automatizadas, arquitecturas evolutivas, feature toggling, patrones de arquitectura: forman parte de la propuesta, pero como caja de herramientas de la que se toma una a la vez, cuando la complejidad lo pide. La complejidad no es enemiga. La prematura sí.

Dónde vive todo esto

La respuesta corta es: donde el negocio pueda abrirlo.

En Itera venimos usando Notion, que cumple hoy el papel que cumplía aquella wiki de 2009. No es la herramienta lo que importa, es la condición: un lugar donde la conversación, las definiciones y el criterio queden escritos, versionados, y accesibles para alguien que no va a entrar nunca a un repositorio de código.

Y conviene decir lo que todavía no está resuelto. Todo lo que este arreglo tiene hoy hacia el negocio es de consulta: el documento está ahí si alguien entra. El radiador rojo de 2013 empujaba el estado hacia la persona sin que nadie fuera a buscarlo. Esa parte todavía no la tenemos.

La otra mitad del problema

Sería cómodo cerrar diciendo que basta con dar acceso. No basta.

Quitar la barrera del lenguaje críptico elimina la excusa, pero no crea el deseo de participar. Eso se construye con acompañamiento decidido en la adopción, y la adopción es justamente lo que menos se financia: aparece como una de las seis capacidades del marco de Rewired, de McKinsey, y en nuestra experiencia es una de las dos que rara vez tienen presupuesto propio. Suelen estar sostenidas por alguien sin mandato formal que las adoptó porque le importa.

Hay además una barrera estructural que no es cultural. Kate Smaje, coautora de ese mismo libro, observa que las compañías que logran esto operan a un ritmo metabólico distinto: donde otras reasignan recursos una vez al año, ellas lo hacen todos los meses. Si el equipo se armó pero el presupuesto se sigue asignando anualmente por gerencia, el dueño de dominio no decide. Pide. Y el que pide no está sobre el ciclo.

En Itera venimos acompañando a organizaciones que están incorporando agentes a sus procesos de desarrollo y de negocio. El patrón se repite con una regularidad que ya no sorprende: la tecnología casi nunca es el cuello de botella. El criterio no escrito, casi siempre.

Si mañana un agente tuviera que resolver de punta a punta un proceso de su organización, y llegara a una decisión que nadie especificó, ¿sobre qué criterio estaría decidiendo, y quién lo escribió?

Esa es la conversación que nos interesa tener.