En el último año, la conversación sobre la ingeniería de agentes se ha movido hacia los arneses y los 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 por estos sistemas. Esto se vuelve aún más cierto a medida que modelos poderosos como Fable y GPT-5.6 estén disponibles.
Los agentes tienen influencia, y la influencia crea obligaciones. Alguien debe poder explicar exactamente qué cambió, por qué era seguro y qué sucederá si se equivoca. De lo contrario, sus acciones no pueden justificarse. Lo que hace que sea 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 verificaciones que instalamos antes de dejar que el sistema actúe. Esas verificaciones 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 ingrese a nuestro sistema dependiente: soy el productor de línea de este contenido. Dirijo el equipo cuyo trabajo se entrega bajo mi nombre. El modelo puede escribir la línea, pero el Veredicto es mío. El trabajo de mi equipo no ingresará a nuestros sistemas dependientes sin mi decisión. Un Veredicto es la decisión de producción: ¿deberíamos enviar, bloquear, redirigir, acotar la respuesta, agregar una protección o rechazar por completo?
El tercero, Capacidad de Respuesta, se refiere a la garantía de que si alguien pregunta, puedo explicar por qué.
Para decirlo 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 auto 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 ejecute de nuevo. Envuelve ese arnés en un ciclo repetible (investiga, implementa, verifica, repite) donde una verificación independiente, no la propia opinión del 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 son dueños de 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 del trabajo enviado 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 estaban haciendo 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 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 eso 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 las restricciones que 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.
Por lo tanto, 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 suficiente 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. Verificaciones 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 estén emitiendo 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. Los 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 nos aseguramos de 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 de agentes en horizontes de tiempo de escala de horas 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 de horas 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ías 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í 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. Por lo tanto, 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 de tiempo de la planificación del agente, mayor se vuelve la brecha entre el código que el agente produce 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 crear 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 el agente produce 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 worktrees, ámbitos y evidencia para reducir el acoplamiento entre tu plan inicial y el trabajo que surge de él. Limita el tiempo del esfuerzo 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 moldean carreras y desempeños en todos los dominios.
Alfa es la parte de liderazgo que asume el que más logra en la competencia, cuando estás jugando tu movimiento de juego 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 el liderazgo en un alfa o el cambio en una decadencia. Es nuestro juicio de lo que viene antes de tener alguna 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.
¿Próximo paso? Operacionaliza tu gusto. ¿Cómo? Dale un nombre que refleje lo que estás tratando de mover de lo límbico a lo 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 borde de solo hacer la tarea a 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 exhaustivo 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 surjan a medida que la ingeniería se vuelva más exigente. Roles que se desvinculan del espíritu de la artesanía pero que dejan claro lo que cada persona hace. Habrá quienes prototipen. Quienes construyan. Quienes limpien. Quienes hagan crecer. Quienes mantengan.
Los humanos también sostienen el borde 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 borde que solo los humanos pueden sostener.
La responsabilidad escalará la fábrica. Como la atención y el gusto, la responsabilidad es también una de las tres dualidades que hace que todo funcione. Sin responsabilidad, no hay reglas. Sin discusiones con los que preguntan. Sin compensaciones. Sin riesgos. Sin redes de seguridad. Si nadie es dueño de la consecuencia de una decisión, entonces una alta agencia solo puede traer caos.
La vida media de un borde 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 respaldar lo que se envió. Las habilidades te dan influencia; la responsabilidad convierte la influencia 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 se utilizó en la decisión, quién fue responsable del cambio y el estado del sistema después de que se bloqueó el cambio. Tal como:
- Tu atención y gusto
- Tu evidencia, veredicto y propiedad
- Tu alfa, decadencia y gusto
Alta agencia
En un flujo de trabajo de agente 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 escalón 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 no dichas, 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 sobre la escala industrial. Pero también hay nuevos cuellos de botella que surgen de la escala industrial. El cuello de botella pasa de "¿podemos construir esto?" a "¿debería existir esto, podemos responder por ello?"
Lo que estoy sugiriendo es un modelo operativo práctico para escalar la ingeniería de agentes. 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 perspectiva. Y luego, para 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.
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 de agentes 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
