Hazte dueño del bucle externo

• Aunque un agente se encargue del bucle interno de ejecución, repitiendo investigación, implementación y verificación, el ingeniero debe hacerse dueño del bucle externo, decidir si se despliega y responsabilizarse por el resultado
• Los sistemas de agentes operan sobre la base de la calidad (Quality), que significa verificaciones previas; el veredicto (Verdict), que decide si algo entra en producción; y la responsabilidad de explicación (Answerability), que permite explicar las razones de una decisión
• En la encuesta 2026 de Sonar, el 42% del código commiteado fue generado por IA o recibió una ayuda sustancial de IA; a medida que la velocidad de generación supera la velocidad de control, la revisión, verificación, comprensión y mantenibilidad se vuelven recursos escasos
• El uso de IA trae consigo rendición cognitiva, es decir, aceptar respuestas incorrectas tal como vienen; deuda cognitiva, que debilita la comprensión del código; y costos de orquestación, porque hay que gestionar varios agentes con una atención humana limitada
• Una fábrica de software escalable es posible cuando a los agentes no se les da autonomía máxima, sino autonomía interrumpible, regulable y verificable, y cuando los humanos se hacen responsables de las restricciones, la revisión por muestreo, la auditoría, la propiedad y el resultado final

---

El bucle externo de la ingeniería agéntica

• La discusión sobre ingeniería agéntica se está moviendo hacia arneses de agentes, bucles, flotas y fábricas de software
• A medida que aparecen modelos potentes como Fable y GPT-5.6, los ingenieros deben hacerse dueños directos del bucle externo, es decir, de la responsabilidad sobre el sistema
• El alto apalancamiento de los agentes crea obligaciones equivalentes
  • Debes poder explicar con precisión qué cambió
  • Debes explicar por qué ese cambio fue seguro
  • Debes saber qué ocurrirá si tu juicio fue incorrecto
• Si no se cumplen estas condiciones, no se pueden justificar las acciones del agente, y a la organización también le resultará difícil usar ese sistema

Calidad, veredicto y responsabilidad de explicación

• Calidad (Quality) se refiere a todas las verificaciones que se instalan antes de soltar el sistema, y la evidencia obtenida allí se convierte en la base del veredicto
• Veredicto (Verdict) es la decisión final de producción que toma una persona antes de que el trabajo entre en sistemas dependientes
  • Aunque el modelo escriba el código, la persona que despliega el trabajo con su nombre asume la responsabilidad del veredicto
  • Decide entre desplegar, bloquear, cambiar la ruta, reducir el alcance de respuesta, agregar guardrails o rechazarlo por completo
• Responsabilidad de explicación (Answerability) es la garantía de que se puede explicar ese juicio cuando alguien pregunte por qué
• Un modelo puede escribir una línea de código, pero no reemplaza la responsabilidad de decidir si debe pasarse a sistemas dependientes

Modelo, arnés, bucle y fábrica

• Un agente no es solo un modelo, sino que incluye un arnés que combina archivos, herramientas, memoria, habilidades, sandbox, permisos, observabilidad y capacidad de recuperación
• Si el modelo es el motor, el arnés es el auto construido alrededor de ese motor para que haga trabajo real de forma segura
  • Las herramientas y la memoria proporcionan capacidad de trabajo
  • Los permisos y el sandbox limitan el alcance de ejecución
  • Las pruebas y la observabilidad permiten confirmar los resultados del trabajo
• El bucle de ejecución de un agente está compuesto por investigar → implementar → verificar → repetir
  • Un ciclo repetible convierte un éxito puntual en un proceso nuevamente confiable
  • La finalización del trabajo debe decidirse mediante verificaciones independientes, no por el propio juicio del modelo
• Operar varios bucles al mismo tiempo se convierte en una fábrica de software
  • En el interior, los agentes producen trabajo
  • En el límite, los humanos son dueños de las decisiones de producción

El límite que separa dentro y fuera del sistema

• En el centro de una fábrica de software hay un límite que separa el interior y el exterior del sistema
• El sistema interno recopila como insumos la intención del equipo de producto, conocimiento sobre despliegues pasados, incidentes recientes y feedback concreto de usuarios
• Los bucles de agentes investigan el trabajo, implementan el plan y luego verifican el resultado
• Cuando la evidencia generada por la verificación cruza el límite del sistema, el humano dueño de los sistemas dependientes decide si se avanza
• Antes, los agentes realizaban solo una parte del proceso de ejecución; ahora se hacen cargo de todo el bucle interno de ejecución, y los ingenieros se encargan del bucle externo
• Lo que entregan los agentes dentro del límite es capacidad (capability)
  • Investigar el trabajo
  • Implementar el plan
  • Probar el resultado
  • Reportar el resultado
• Lo que ejercen los humanos fuera del límite es agencia (agency)
  • Decidir
  • Verificar
  • Aprobar
  • Ser dueño

La brecha de confianza y verificación creada por el código de IA

• La proporción de código de IA ya no se mantiene en un nivel marginal
• Según el reporte State of Code 2026 de Sonar, el 42% del código commiteado fue generado por IA o recibió ayuda sustancial de IA, y los encuestados esperan que esa proporción no se estanque y siga creciendo
• A medida que baja el costo de generar código, la revisión, verificación, comprensión y mantenimiento se vuelven recursos más escasos
• Como la velocidad de generación crece más rápido que la velocidad de control, aparece una brecha de confianza y verificación
  • Muchas personas expresan desconfianza hacia el código de IA
  • Menos personas convierten esa desconfianza en procedimientos de verificación consistentes
• Se necesitan formas más baratas y claras de confirmar la confiabilidad del código de IA

Límites de la gobernanza posterior

• Según la investigación de GitLab de junio de 2026 sobre responsabilidad en IA, el cuello de botella actual del uso de IA es la revisión y verificación
• La gobernanza suele aplicarse después de que el código ya fue creado
  • Para ese momento, la organización ya aceptó el riesgo
  • El control sobre la propiedad del trabajo también ya se debilitó
• La gobernanza de IA debe ir más allá del simple control del sistema y definir lo siguiente
  • Qué restricciones se impondrán al sistema
  • Con qué evidencia se inspeccionará el trabajo
  • Cómo se responsabilizará a los equipos
  • Quién será dueño de cada parte del ciclo de vida de la IA

La contrapresión que crea calidad

• La calidad puede entenderse como contrapresión (back pressure) ejercida sobre el sistema
• El objetivo no es darle al agente la mayor autonomía posible
• Hay que darle solo la autonomía suficiente para poder interrumpirlo, regularlo, inspeccionar su trabajo y preservar el rol humano
• En la ingeniería existente ya hay señales que muestran si el trabajo avanza en la dirección correcta
  • Verificación de tipos
  • Pruebas
  • Hooks
  • Límites de sandbox
  • Logs de auditoría
  • Monitores
• Si los agentes también emiten esas mismas señales, el sistema de ingeniería existente puede proporcionar una contrapresión adecuada

Los cuatro bucles en los que deben estar los humanos

• Confiar en un sistema no significa sacar a los humanos del bucle
• Los humanos deben estar en los siguientes cuatro bucles externos de control, más que en el bucle interno de ejecución
  • Bucle de restricciones: decide qué entradas, arquitecturas, instrucciones e invariantes se establecerán
  • Bucle de revisión por muestreo: define qué proporción de las salidas se extraerá y revisará
  • Bucle de auditoría: decide qué evidencia se conservará y cómo se garantizará la validez de los logs de auditoría
  • Bucle de propiedad: aclara quién será dueño de qué parte del límite de producción
• Los agentes pueden producir más trabajo del que los humanos pueden revisar
• Por eso, el recurso escaso es el juicio humano esencial ejercido sobre la base de señales de calidad como logs y pruebas
• En el entorno experimental tratado por la investigación de OpenAI sobre agentes y el futuro del trabajo, la delegación agéntica en rangos de horas ya llegó a una etapa posible
• Hay que establecer límites de propiedad antes de que el sistema produzca más trabajo del que puede revisarse

Agentes de larga ejecución y responsabilidad de explicación

• Todas las elecciones que hace un agente de larga ejecución que opera durante horas son decisiones
• No todas las decisiones quedan registradas, ni cada una puede rastrearse hasta los tokens de entrada
• Si solo se cree que el resultado es la elección correcta para el problema, reconstruir la cadena de decisiones que llevó a ese resultado puede requerir cientos o miles de horas de trabajo humano
• Como esa cadena de decisiones en la práctica es difícil de reconstruir, la responsabilidad de explicación debe ponerse en el centro del diseño del sistema

Tres costos ocultos de delegar en IA

• Rendición cognitiva

  • La rendición cognitiva (cognitive surrender) es el fenómeno de aceptar ciegamente el resultado que entrega la IA
  • Aunque se le encargue una tarea a un agente, el resultado queda conectado con el trabajo, la reputación y la responsabilidad del usuario
  • Los defectos quedan en el software del usuario
  • Lo que debe modificarse para ajustarse a la salida también es el software del usuario
  • La respuesta del agente termina siendo la respuesta del usuario, y la responsabilidad viene con ella
  • En un estudio de Wharton, incluso cuando la IA estaba equivocada, casi tres cuartas partes de los participantes aceptaron su respuesta y mostraron mayor confianza que cuando juzgaron sin IA

• Deuda cognitiva

  • La deuda cognitiva (cognitive debt) es el debilitamiento de la comprensión y la memoria sobre cómo resolver un problema
  • Cuando se delega una tarea a un agente, el proceso de pensamiento también se externaliza
  • El tiempo y la energía necesarios para comprender por cuenta propia una base de código grande pueden ser difíciles de asegurar durante el proceso de aprendizaje
  • Como resultado, el artefacto creado por el agente a veces alcanza un nivel difícil de lograr con la capacidad actual del usuario
  • Mientras más se prolonga el tiempo de planificación del agente, mayor se vuelve la brecha entre el código generado y la comprensión humana
  • Esta brecha se acumula, y el costo de volver a subir la curva de aprendizaje crece casi de forma geométrica
  • En un ensayo controlado aleatorizado de Anthropic, los ingenieros que escribieron código con IA obtuvieron 50% en una prueba de comprensión, 17 puntos porcentuales menos que el 67% del grupo que lo escribió directamente

• Costo de orquestación

  • El costo de orquestación (orchestration tax) surge porque, aunque se puedan ejecutar muchos agentes al mismo tiempo, el ancho de banda cognitivo humano no se paraleliza de la misma forma
  • Los humanos deben realizar directamente las siguientes tareas
    • Ajustar a los agentes para que eviten los peores comportamientos
    • Seleccionar, entre los entregables, los trabajos que requieren atención
    • Indicar que se atiendan primero las tareas importantes
    • Verificar restricciones clave y supuestos riesgosos antes de la ejecución
  • Este trabajo no puede automatizarse y no puede reemplazar el juicio humano

Cómo proteger la atención en brownfield

• Los sistemas brownfield son especialmente riesgosos porque el comportamiento que hay que auditar no existe solo en el código, sino también en cicatrices e historia acumuladas
• En las decisiones de arquitectura, la atención humana debe ponerse como prioridad
• Usar worktree, alcance y evidencia puede reducir el acoplamiento entre el plan inicial y el trabajo que aparece durante la ejecución
• Los intentos de resolver pasos que no pueden ejecutarse deben tener límite de tiempo
• Los permisos de cambio de software deben otorgarse mediante un esquema estricto de opt-in

Alpha, decay y taste

• Los tres patrones clave que moldean las carreras y el desempeño en distintos campos son alpha, decay y taste
• Alpha es la zona líder ocupada por quienes logran el mayor desempeño en la competencia, y el estado de hacer la jugada de mayor valor
• Decay es un patrón asentado que todos aprendieron mediante repetición y observación, y puede verse como una especie de meseta
• Taste es el juicio que detecta el liderazgo de alpha o el cambio de decay antes de que aparezca evidencia
• La discusión de Paul Graham plantea que, cuando cualquiera puede construir cualquier cosa, elegir qué construir se vuelve más importante
• En la definición de Mitchell Hashimoto, taste es un juicio cualitativo de alta calidad que se toma cuando todavía no hay criterios de medición objetivos
• El movimiento de alpha ocurre por cambios en taste, y decay desaparece cuando la gente empieza a preferir otra cosa

Convertir taste en una capacidad operable

• Para mover taste desde la intuición hacia una capacidad consciente, primero hay que ponerle nombre
• Hay que practicar ese juicio mediante crítica y ejemplos concretos
• También hay que expresar explícitamente los fundamentos del juicio
• Para aumentar una ventaja competitiva sostenible, hay que seguir moviendo hacia arriba los límites del rol
  • Hacer el trabajo directamente
  • Enseñar el trabajo a otras personas o sistemas
  • Sistematizar el trabajo
  • Decidir cuándo debe hacerse
  • Ser dueño del resultado

La diferencia entre desarrollador e ingeniero

• Cualquiera puede ser desarrollador, pero no todos son ingenieros
• Un desarrollador se convierte en ingeniero cuando acepta una disciplina de trabajo más estricta
  • Razonamiento riguroso y lógicamente válido
  • Consideración de restricciones y trade-offs
  • Conciencia de riesgos y superficie de exposición
  • Responsabilidad real
• Cuando la ingeniería se vuelve más exigente, las personas se alejan de tareas gestionables y separan roles que estaban atados a la artesanía, aclarando la función de cada uno
  • Quien prototipa
  • Quien construye
  • Quien ordena
  • Quien hace crecer
  • Quien mantiene

El límite del sistema que solo los humanos pueden proteger

• Los humanos también cumplen el rol de elevar alpha en el límite opuesto del sistema
  • Eligen qué vale la pena hacer
  • Definen bajo qué restricciones hacerlo
  • Juzgan si la evidencia es suficiente para avanzar
  • Cuidan el resultado
• Ya sea un equipo o 100 equipos, este límite solo puede ser propiedad de humanos
• Atención, taste y responsabilidad son los elementos clave que hacen funcionar a una fábrica de software
• Sin responsabilidad, tampoco se sostienen las reglas, las respuestas a preguntas, los trade-offs, los riesgos ni las redes de seguridad
• Si no hay alguien que se haga dueño de las consecuencias de una decisión, una agencia alta deriva en caos

Una firma que dura más que la tecnología

• La vida media de una ventaja técnica puede ser una sola release, pero la vida media de la firma (signature) que dejas en tu trabajo se extiende por toda una carrera
• La firma significa que puedes poner tu nombre y respaldar el resultado que desplegaste
• La tecnología crea apalancamiento, y la responsabilidad convierte ese apalancamiento en confianza
• Solo las personas eligen y heredan los resultados
• Los agentes pueden elegir, rutear, mergear y escalar dentro de una política, pero no pueden heredar las consecuencias

El contrato de responsabilidad de la base de código

• Cada base de código puede necesitar un contrato de responsabilidad que explicite las condiciones para aceptar cambios
  • Una checklist que confirme lo comprendido al aprobar
  • La evidencia usada para el juicio
  • La persona responsable del cambio
  • El estado del sistema después de bloquear un cambio
• El contrato debe tratar explícitamente relaciones como atención y taste; evidencia, veredicto y propiedad; y alpha, decay y taste

La escalera de la agencia alta

• En un workflow agéntico, la agencia alta es la capacidad de saber cuándo delegar, inspeccionar, interrumpir y hacerse dueño del resultado
• La escalera de la agencia va de niveles bajos a altos
  1. Señalar un problema potencial
  2. Investigar el problema
  3. Ejecutar trabajo de respuesta
  4. Diagnosticar la causa
  5. Proponer una solución
  6. Recomendar una corrección
  7. Resolver el problema
• Los niveles más altos también incluyen el discernimiento de detectar un problema pero decidir que no vale la pena corregirlo y seguir adelante

Por qué brownfield es la primera línea de las fábricas de software

• Brownfield es la primera línea que enfrentará una fábrica de software que quiere escalar
• En sistemas greenfield se puede controlar todo, por lo que es relativamente fácil planear e implementar suficientes mecanismos de contrapresión
• Al agregar agentes inteligentes a sistemas legacy, también hay que lidiar con complejidad fuera del código
  • Todo el comportamiento en producción
  • Expectativas futuras de los clientes
  • Historial de migraciones
  • Ciclos de release y presupuesto
  • Supuestos implícitos
  • Casos excepcionales
  • Particularidades de los datos
  • Procedimientos de runbook
  • Cicatrices acumuladas sin gestión
• Para cuidar un brownfield se necesita ingeniería sostenible
  • Convertir conocimiento tácito en restricciones explícitas
  • Mantener el conocimiento de forma consistente entre equipos y generaciones
  • Formalizar el conocimiento en procedimientos de prueba y especificaciones funcionales
  • Conectar ese conocimiento con evidencia objetiva
  • Acumular los fallos como aprendizaje adicional
• Si se corta el nivel de gestión que recibía, todo el sistema puede colapsar

El nuevo trabajo que aparece al escalar

• Cuando se automatizan componentes existentes, las personas usan el alpha y el taste obtenidos de su experiencia artesanal para diseñar nuevo trabajo
  • Diseñar nuevos bucles para incorporarlos a la fábrica de software
  • Construir sistemas greenfield basados en principios usando el conocimiento obtenido de la fábrica
  • Crear nuevos formatos de evidencia para verificar nuevos sistemas
  • Cuidar sistemas brownfield que se volvieron lo bastante complejos como para requerir gestión dedicada
  • Diseñar y gestionar nuevos mecanismos de contrapresión
  • Diseñar nuevos agentes
  • Construir nuevos sistemas de agencia
• Todas estas actividades también son trabajo real de ingeniería, y a medida que aumenta la escala se vuelven problemas más interesantes

La automatización mueve el cuello de botella

• La automatización da control a escala industrial y, al mismo tiempo, crea nuevos cuellos de botella
• Si el cuello de botella del pasado era “¿podemos construir esto?”, en adelante se desplazará hacia “¿esto debería existir, y podemos explicar y responsabilizarnos por sus consecuencias?”
• El nuevo cuello de botella en producción merece ser propiedad directa de los humanos

Modelo operativo de la ingeniería agéntica

• El bucle interno es donde se realiza el trabajo real, y cada bucle debe diseñarse con la mayor independencia posible
• Toda garantía de calidad y verificación debe incorporarse al bucle interno
• Una vez diseñado y verificado el propio bucle, se otorga autonomía instalando mecanismos de contrapresión que controlen la velocidad de ejecución y el alcance del trabajo
• En lugar de intervenir en todos los pasos internos, los humanos deben ubicarse en los puntos de decisión correctos
• La comprensión no debe tratarse como un simple handoff o gate de release, sino como un punto de decisión donde los humanos están listos para aportar insight
• Cada vez que los entregables vuelvan a alimentar producción y a nuevos equipos o ingenieros, deben dejar mejores entregables y evidencia que antes
• Hay que construir y seguir operando la fábrica de software, pero mantener el trabajo en un estado legible, verificable y con dueño
• Aunque los agentes escriban el código, antes de que llegue a los usuarios una persona debe responder estas preguntas
  • Por qué este código debería existir
  • Por qué es lo suficientemente seguro incluirlo en producción
  • Qué se hará si está mal
• Hacer este juicio y asumir esta responsabilidad es el bucle externo de la ingeniería agéntica