En el último año, la conversación sobre la ingeniería agéntica ha pasado a los arneses y bucles, las flotas y las fábricas de software. Mi opinión es que los ingenieros deben ser dueños del bucle externo — la responsabilidad sobre estos sistemas. Esto se vuelve aún más cierto a medida que modelos potentes como Fable y GPT-5.6 estén disponibles.
Los agentes tienen apalancamiento, y el apalancamiento crea obligaciones. Alguien debe poder explicar exactamente qué cambió, por qué era seguro y qué pasará si se equivoca. De lo contrario, sus acciones no pueden justificarse. Lo que hace poco probable que su organización los solicite en primer lugar.
Y por eso quiero hablar de tres términos. El primero, Calidad, se refiere a todas las comprobaciones que instalamos antes de dejar que el sistema actúe. Esas comprobaciones producen evidencia, y de esa evidencia derivamos un Veredicto.
El segundo, Veredicto, se refiere a la decisión final que tomamos antes de que el trabajo entre en nuestro sistema dependiente: soy el productor de línea de este contenido. Dirijo el equipo cuyo trabajo se envía bajo mi nombre. El modelo puede escribir la línea, pero el Veredicto es mío. El trabajo de mi equipo no entrará en nuestros sistemas dependientes sin mi decisión. Un Veredicto es la decisión de producción: ¿deberíamos enviar, bloquear, redirigir, acotar la respuesta, añadir una protección o rechazar directamente?
El tercero, Capacidad de Respuesta, se refiere a la garantía de que si alguien pregunta, puedo explicar por qué.
Dicho de otra manera: nuestro agente (que defino como un modelo más un arnés de archivos, herramientas, memoria, habilidades, entornos aislados, permisos, observabilidad y recuperación) es lo que ejecuta nuestro bucle (que defino como investigación, implementación, verificación y repetición). Y es lo que crea nuestra fábrica de software.
El modelo es solo el motor. El arnés (herramientas, memoria, permisos, entornos aislados, pruebas) es el coche que construyes a su alrededor para que pueda hacer trabajo real de forma segura.
Envuelve ese arnés en un ciclo repetible: investiga, implementa, verifica, repite. El bucle es cómo una buena ejecución se convierte en un proceso en el que puedes confiar para que se repita. Envuelve ese arnés en un ciclo repetible (investiga, implementa, verifica, repite) donde una comprobación independiente, no la palabra del propio modelo, decide cuándo el trabajo está terminado.
Ahora ejecuta muchos bucles a la vez. Una fábrica son bucles a escala: los agentes envían el trabajo internamente, mientras que los humanos toman las decisiones en el límite.
Y en el corazón de esa fábrica hay un límite cuidadoso entre lo que está dentro del sistema y lo que está fuera de él. Dentro del sistema: recopilamos entradas (de la intención del equipo de producto, o del conocimiento de trabajos enviados anteriormente, o de incidentes recientes, o de comentarios específicos de los usuarios). El bucle del agente investiga la tarea, implementa un plan y verifica el resultado. Luego, la evidencia cruza ese límite. Un humano, que es dueño del sistema dependiente, ve la evidencia y decide si proceder.
Y eso, amigos, es el cambio que estamos tratando de hacer. Antes, nuestros agentes hacían el bucle interno del bucle de ejecución. Ahora ejecutan el bucle de ejecución interno. Los ingenieros son dueños del bucle externo.
Dentro del sistema, realmente solo hay un tipo de cosa que hacen nuestros agentes: capacidad. La capacidad de investigar tareas, implementar planes, probar sus resultados e informar. Esa es la capacidad de un modelo. Y como hemos dicho, ese futuro ya está aquí.
Fuera del sistema, hay un solo tipo de cosa: agencia. La agencia para decidir, verificar, aprobar y ser dueño.
Todavía estamos hablando de código, ¿ves? Solo necesita vivir en un lugar y ser realizado por personas que saben lo que hacen.
El potencial del código de IA ya no es marginal. En una encuesta de Sonar 2026, preguntamos a los equipos sobre la proporción de sus commits que fueron asistidos por IA. Era pequeña pero no trivial. Y varios de los encuestados dijeron que esperan que la proporción de commits asistidos por IA crezca sustancialmente. El Informe del Estado del Código 2026 de Sonar encontró que el 42% del código comprometido fue generado por IA o significativamente asistido por IA, con expectativas de que esa proporción siga creciendo en lugar de estabilizarse.
La creación, en otras palabras, se está volviendo más barata. Los recursos más escasos son la revisión, la validación, la comprensión y el mantenimiento.
Movimos la velocidad de generación más rápido de lo que movimos la velocidad de control. Y por lo tanto, tenemos una brecha de confianza-verificación. Muchas personas con las que hablamos todavía expresan cierto grado de desconfianza en el código de IA. Sin embargo, menos de ellos parecen construir consistentemente esa desconfianza en sus procesos de verificación.
Y ese es un lugar peligroso para estar. Vamos a necesitar formas más baratas y claras de verificar la confiabilidad del código de IA.
Si observas el informe de GitLab de junio de 2026, verás que las preguntas de gobernanza han cambiado. La investigación de responsabilidad de IA de GitLab de junio de 2026 muestra que la revisión y la validación son los cuellos de botella actuales al usar IA y, más preocupante aún, que la gobernanza generalmente ocurre después de la creación del código, después de que hemos aceptado el riesgo y perdido el control sobre la propiedad. Hoy, no se trata solo de control. Se trata de qué restricciones establecemos en el sistema. Se trata de cómo verificaremos el trabajo con evidencia y cómo haremos responsables a los equipos. Se trata de quién será dueño de qué parte del ciclo de vida de la IA.
Así que la distinción final en esta serie es entre proceso y calidad. La calidad es el concepto de contrapresión. Lo decimos literalmente. No queremos otorgar a nuestros agentes tanta autonomía como puedan ejercer. Queremos otorgarles la autonomía justa para que tengamos suficiente contrapresión para detenerlos, regularlos, verificar su trabajo y asegurar nuestra humanidad.
La ingeniería ordinaria sostiene muchas señales que indican que el trabajo que se está haciendo está haciendo lo correcto. Comprobaciones de tipos, pruebas, hooks, límites de entornos aislados, registros de auditoría, monitores. Nuestros sistemas de ingeniería están llenos de este tipo de señales, y están diseñados para proporcionar suficiente contrapresión para mantener el sistema honesto.
Y así, mientras nuestros agentes emitan estas mismas señales, podemos confiar en que nuestra ingeniería ordinaria proporcione la contrapresión adecuada.
Confiar en nuestros sistemas no significa que no queramos un humano en el bucle. Solo significa que el humano no necesita estar en el bucle interno. Lo queremos en el bucle de restricciones (¿qué entradas, arquitecturas, instrucciones o invariantes deberíamos establecer?), el bucle de muestreo (¿cuánta salida deberíamos muestrear y revisar?), el bucle de auditoría (¿qué evidencia deberíamos conservar y cómo aseguramos que nuestro registro de auditoría sea efectivo?) y el bucle de propiedad (¿qué parte del límite de producción deberíamos poseer?).
Pero el humano no necesita estar en el bucle interno.
El agente puede enviar más de lo que puedes revisar.
Y el recurso escaso es tu propio juicio humano central, informado por señales de calidad como registros o pruebas.
El informe de IA de junio de 2026 muestra que, en el entorno experimental, la delegación agéntica en horizontes de tiempo de escala horaria está esencialmente aquí. El trabajo de OpenAI este año sobre agentes y el futuro del trabajo fue una gran fuente para estas ideas. Por lo tanto, debemos comenzar a pensar en cómo establecer este límite de propiedad, a medida que nuestros sistemas comienzan a enviar más de lo que podemos revisar.
Y ahí es donde entra la capacidad de respuesta.
Porque con agentes de horizonte largo, las decisiones tomadas en horizontes de tiempo de escala horaria son solo eso: decisiones. Y no todas las decisiones serán registradas. No puedes rastrearlas todas hasta los tokens de entrada. Si todo lo que haces es confiar en que la salida que obtienes es la elección correcta para el problema en cuestión, los cientos o incluso miles de horas de trabajo humano que necesitarás para reconstruir la cadena de decisiones que llevaron a ella se vuelven imposibles. Y así, nuevamente, la capacidad de respuesta se convierte en algo que debe estar en el centro del diseño de nuestro sistema.
Tres costos ocultos
Y hay tres costos ocultos:
Rendición cognitiva ~ aceptar ciegamente lo que la IA te da. Cuando delegas trabajo a un agente, el trabajo en sí mismo puede parecer el trabajo del agente. Pero en realidad es tu trabajo. Es tu reputación. Es tu responsabilidad. Y es tu software el que sufrió los defectos en la salida. Y es tu software el que necesita ser cambiado para reflejar esa salida. Así que la salida del agente se convierte en tu respuesta. Y con ella viene toda la responsabilidad. El estudio de Wharton que armó esto es tranquilizador cuando la IA tiene razón. Pero cuando se equivoca, las noticias no son buenas. Cuando la IA se equivocaba, casi tres cuartas partes de las personas lo aceptaban de todos modos y se sentían más seguros de lo que se habrían sentido sin la IA.
Deuda cognitiva ~ erosión de tu comprensión y memoria de cómo resolver problemas. Cuando delegas trabajo a un agente, estás externalizando todo el trabajo de pensamiento al agente. Y aunque pensar todo por ti mismo requiere tiempo y energía, pensar en una base de código masiva requiere recursos que no están disponibles cuando intentas subir la curva de aprendizaje. Por lo tanto, la salida que obtienes a menudo es inalcanzable para ti. Y cuanto más largo es el horizonte temporal de la planificación agéntica, mayor se vuelve la brecha entre el código que produce el agente y tu comprensión del mismo. La brecha se acumula. La deuda se acumula. Y el costo de subir la curva de aprendizaje crece casi exponencialmente. Hay un ensayo controlado aleatorio de Anthropic que analiza si los ingenieros que dependen de la IA para escribir código lo entienden tan bien como los ingenieros que lo escriben ellos mismos. La conclusión fue sombría: en un cuestionario de comprensión, los ingenieros que trabajaron con IA obtuvieron diecisiete puntos porcentuales menos que los que no lo hicieron, 50 por ciento frente a 67 por ciento.
Y luego está el impuesto de orquestación ~ es fácil poner en marcha muchos agentes ahora, pero tu ancho de banda cognitivo no se paraleliza de la misma manera. Dirigir a tu agente lejos de los peores comportamientos, clasificar el trabajo que produce el agente para identificar los que necesitan tu atención, dirigirlo para que se centre primero en el trabajo que te importa, verificar tus restricciones más importantes y tus suposiciones más peligrosas antes de dejarlo funcionar…
Todo eso requiere trabajo y no se puede automatizar.
No hay sustituto para el juicio humano.
Los sistemas brownfield son especialmente peligrosos aquí, porque el comportamiento del sistema que tienes que auditar no vive en el código. Vive en las cicatrices.
¿Soluciones? Haz de la atención la prioridad en tus decisiones arquitectónicas. Usa árboles de trabajo, ámbitos y evidencia para reducir el acoplamiento entre tu plan inicial y el trabajo que surge de él. Limita el tiempo para resolver pasos no accionables. Y haz que el cambio en tu software sea estrictamente un permiso de aceptación explícita.
Alfa, decadencia y gusto: estos son los tres patrones centrales que dan forma a las carreras y actuaciones en todos los dominios.
Alfa es la parte principal que asume el que más logra en la competencia, cuando estás jugando tu movimiento de mayor valor. Las decadencias son patrones establecidos que todos aprenden a través de la repetición y la observación de otros (mesetas, si lo prefieres). El gusto es lo más temprano que podemos sentir la delantera en un alfa o el cambio en una decadencia. Es nuestro juicio de lo que viene antes de tener evidencia de que algo está sucediendo. El punto de Paul Graham es que cuando cualquiera puede hacer cualquier cosa, elegir qué hacer importa más, y la definición de Mitchell Hashimoto es la operativa: hacer juicios cualitativos de alta calidad donde aún no existe una métrica objetiva. De ahora en adelante, el gusto lo impulsa todo: los cambios alfa son cambios de gusto. Y las decadencias se desvanecen porque empezamos a saborear algo diferente.
¿Siguiente paso? Operacionaliza tu gusto. ¿Cómo? Dale un nombre que refleje lo que estás tratando de mover de límbico a consciente. Practícalo en la crítica y los ejemplos. Haz explícita su razón de ser.
Y sigue haciendo el movimiento que brinda la ventaja competitiva más duradera en tu industria. ¿Cuál es ese? Sigue moviendo el límite hacia arriba, desde solo hacer la tarea hasta enseñarla, sistematizarla, decidir cuándo debe hacerse y ser dueño del resultado.
Todos son desarrolladores, pero no todos son ingenieros. La ingeniería es en lo que se convierte un desarrollador cuando adopta una disciplina de trabajo más estricta: razonamiento minucioso y lógicamente sólido, consideración de restricciones y compensaciones, reconocimiento de riesgos y exposiciones, y responsabilidad práctica.
En el futuro, las personas dejarán el trabajo administrativo de la ingeniería y adoptarán nuevos roles que surgen a medida que la ingeniería se vuelve más exigente. Roles que se desvinculan del espíritu del oficio pero dejan claro lo que cada persona hace. Habrá quienes prototipen. Quienes construyan. Quienes barran. Quienes hagan crecer. Quienes mantengan.
Los humanos también mantienen el límite del sistema en la otra dirección. Aumentando el alfa en la otra dirección: elegir lo que vale la pena hacer, definir las restricciones dentro de las cuales debe hacerse, decidir si la evidencia es suficiente para proceder y cuidar el resultado. Ya sea un solo equipo o cien equipos, este es el límite que solo los humanos pueden mantener.
La responsabilidad escalará la fábrica. Como la atención y el gusto, la responsabilidad es también una de las tres dualidades que hacen que todo funcione. Sin responsabilidad, no hay reglas. Sin forcejeo con los cuestionadores. Sin compensaciones. Sin riesgos. Sin redes de seguridad. Si nadie es dueño de la consecuencia de una decisión, entonces la alta agencia solo puede traer caos.
La vida media de un límite es un lanzamiento, pero la vida media de una firma es una carrera. Una firma es tu nombre en el trabajo, de modo que sientes que puedes defender lo que se envió. Las habilidades te dan apalancamiento; la responsabilidad convierte el apalancamiento en confianza.
Solo las personas pueden elegir. Solo las personas heredan las consecuencias. Se puede pedir a los agentes que elijan, enruten, fusionen y escalen de manera segura dentro de una política, pero no pueden heredar las consecuencias.
Quizás cada base de código debería venir con algún tipo de contrato de responsabilidad que establezca explícitamente la lista de verificación que se entendió cuando se aceptó el cambio, la evidencia que respaldó la decisión, quién fue responsable del cambio y el estado del sistema después de que se bloqueó el cambio. Como por ejemplo:
- Tu atención y gusto
- Tu evidencia, veredicto y propiedad
- Tu alfa, decadencia y gusto
Alta agencia
En un flujo de trabajo agéntico típico, la alta agencia es el arte de saber cuándo delegar, cuándo inspeccionar, cuándo detenerse y cuándo ser dueño del resultado de un proceso. La escalera de la agencia va de baja a alta: señalar un problema potencial, investigarlo, ejecutarlo, diagnosticarlo, proponer soluciones, recomendar correcciones y resolver el problema. Un peldaño alto en la escalera de la agencia es el discernimiento: lo encontré, no vale la pena arreglarlo, sigo adelante.
Los doce pilares que sostienen la fábrica de software
Brownfield es la frontera para las fábricas que esperan escalar. Todas esas pequeñas innovaciones inteligentes pueden no parecer mucho todavía, pero el entorno de producción es mucho. Al construir un sistema completamente nuevo, es mucho más fácil planificar e implementar mecanismos de contrapresión suficientes porque tienes control total. Sin embargo, cuando agregas agentes inteligentes a un sistema heredado, es otro asunto completamente diferente.
Los sistemas heredados incluyen la totalidad del comportamiento de producción, las expectativas futuras de los clientes, los historiales de migración, las duraciones de los ciclos de lanzamiento y presupuesto, las suposiciones tácitas, los casos extremos, las rarezas de los datos, los procedimientos de los runbooks y todas las cicatrices que se acumularon sin la voluntad de cuidar el sistema.
Ser un administrador de brownfield requiere una forma de ingeniería duradera. Se debe trabajar para convertir el conocimiento implícito en restricciones explícitas, mantenerlo coherente entre equipos y a través de generaciones, formalizar ese conocimiento en procedimientos de prueba y especificaciones funcionales, y vincular ese conocimiento a la evidencia objetiva. Todo mientras se convierte el fracaso en más aprendizaje. Porque si el sistema no recibe el cuidado que siempre ha recibido, todo se vendrá abajo.
El Nuevo Trabajo es Trabajo Real
El trabajo se volverá más interesante a medida que escales. Porque cuando todo lo demás esté construido, la gente querrá construir cosas nuevas. Querrán emplear el alfa y el gusto que han desarrollado a través de su oficio para diseñar nuevos bucles que puedan injertarse en la fábrica de software. O querrán construir sistemas greenfield que empleen todo el conocimiento de la fábrica de software en un esfuerzo elegante, bien intencionado y basado en principios. Querrán diseñar e implementar nuevas formas de evidencia que se eleven al nivel de verificación para los nuevos sistemas. Querrán cuidar los sistemas brownfield que ahora son tan complejos que necesitan atención dedicada. Querrán diseñar y gestionar nuevos mecanismos de contrapresión. Querrán diseñar nuevos agentes. Y querrán construir agencia.
Y, a medida que lo hagan, llegarán a ver que todo esto es trabajo real. Eso es algo bueno.
La automatización crea cuellos de botella. Cuellos de botella en la producción que vale la pena poseer. Porque la automatización nos da control a escala industrial. Pero también surgen nuevos cuellos de botella de la escala industrial. El cuello de botella pasa de "¿podemos construir esto?" a "¿debería existir esto, podemos responder por ello?"
Lo que sugiero es un modelo operativo práctico para escalar la ingeniería agéntica. Hay bucles internos y externos. El bucle interno es donde se realiza el trabajo. Los bucles están diseñados para ser lo más independientes posible. Pon todas las garantías de calidad y verificación dentro del bucle. Una vez que hayas diseñado y validado el bucle en sí, lo único que te queda por hacer es otorgar autonomía implementando un mecanismo de contrapresión que actúe para controlar la velocidad a la que se ejecuta el bucle y su alcance de operación. Y pon a los humanos en su lugar legítimo, en las decisiones correctas. No trates la comprensión como una transferencia o una puerta de lanzamiento, sino como un punto de decisión donde los humanos están preparados para proporcionar su visión. Y luego, por cada artefacto que exista y se retroalimente a la producción y a nuevos equipos e ingenieros, deja mejores artefactos.
Construye la fábrica; mantén las luces encendidas; haz que el trabajo sea legible, verificable y de propiedad conocida.
Un agente puede escribirlo. Pero antes de que llegue a los usuarios, alguien debe explicar por qué debería existir, por qué es lo suficientemente seguro como para ser parte de la producción y qué harán cuando esté mal.
Eso es ingeniería agéntica en el bucle externo — ese es el trabajo ahora.
Pangram ha calificado este artículo como 100% escrito por humanos: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
