[🤖] Cuando la IA entregó un resultado intermedio equivocado, detuve el siguiente trabajo

✨ Resumen de GPT-5.6 Sol

Los informes de que todo había pasado ocultaron una mala estructura de información que se extendió a otras pantallas y al backend. Hice que la revisión fuera obligatoria antes del trabajo posterior.

Los informes decían que todo había pasado. Confié en ellos y abrí una pantalla que era pura basura. Pero el problema que persigue este artículo estaba antes de esa pantalla final.

Nadie detuvo la estructura de información cuando empezó a desviarse, así que las siguientes páginas y el backend siguieron construyéndose encima. Hice que un resultado intermedio equivocado cerrara el trabajo posterior.

Los informes PASS hicieron crecer la pantalla equivocada durante 16 horas

Yo no miraba personalmente cada resultado intermedio. La sesión de implementación declaraba su propio trabajo completo y otras sesiones seguían construyendo páginas y backend encima. Una mala estructura de información se extendió antes de ser verificada. Cuando abrí la UI, dieciséis horas de trabajo ya descansaban sobre la dirección equivocada.

No necesitaba una forma de ejecutar la IA durante más tiempo.

Necesitaba una estructura que impidiera iniciar el siguiente trabajo cuando el resultado intermedio era incorrecto.

Al discutir el problema encontré el término Graph Engineering: diseñar resultados revisables y condiciones de avance como un graph explícito, en lugar de entregar todo el loop largo a un solo Agent.¹ No necesitaba un gran graph runtime. Necesitaba que un resultado sin verificar no abriera la siguiente edge.

«¿No se está volviendo innecesariamente complicado?»

En cuanto propuse Graph Engineering, la IA sacó Coordinators, Workers, Auditors, versiones de contratos, durable ledgers, dashboards y reauditorías completas. Todo sonaba razonable. Pero si la solución a un sumidero de 16 horas empezaba agrandando aún más el sistema de gestión, podía repetir el mismo fracaso.

Mi primer graph solo tenía una sesión de trabajo y otra de auditoría. La primera termina un resultado revisable y se detiene. La segunda ve el resultado congelado y el requisito original, no el ambiente de la conversación ni la autoevaluación del worker. Si hace falta corregir, se modifica una vez el mismo resultado. Si la dirección es errónea, se vuelve al plan sin apilar patches. El trabajo posterior directo permanece cerrado hasta terminar la auditoría.

Las objeciones taparon los huecos del diseño. El worker no puede fijar un criterio de auditoría favorable; si cambia el Runtime o el candidato, se descarta el veredicto anterior. El Gate tampoco se usa para una errata o un bug con un test decisivo, sino donde un resultado equivocado pueda contaminar varias tareas posteriores.

Convertí eso en la Skill custom-graph-engineering-gate, sin DB ni dashboard aparte. Congela un resultado y limita la siguiente acción según PASS, CHANGES_REQUESTED, REPLAN_REQUIRED o NOT_VERIFIABLE. Bastaron las Skills y los subagents de Codex.²³

El primer Gate detuvo de verdad el siguiente trabajo

Crear la Skill no demostraba que funcionara. Congelé un contrato de transición de autorizaciones del que dependerían varias funciones y lo envié a una sesión de auditoría sin la conversación anterior.

El primer veredicto fue CHANGES_REQUESTED, no PASS. El contrato no aclaraba cuándo se evaluaba la autoridad, de dónde nacía la autoridad delegada y cómo se revocaba, ni si usuario, autoridad y empresa objetivo pertenecían al mismo scope. Si se hubiera propagado, habría tenido que rehacer todo el modelo de permisos.

La sesión de trabajo corrigió ese único resultado una vez. Solo después de que la misma auditoría lo revisara apareció PASS. Mientras tanto no se abrió ninguna implementación ni despliegue posterior. Ese era el efecto que buscaba: la siguiente edge se cerró realmente en el punto donde el worker había dicho «suficiente».

Un contrato no demuestra que esto evite otro fracaso de UI de 16 horas. La dirección visual es más difícil de someter a un Gate, y un auditor que usa el mismo modelo y Working Tree puede compartir las mismas premisas falsas. Una Skill tampoco es un motor de ejecución forzosa.

Pero esta vez no instalé un framework gigante por oír un término nuevo. Conservé solo el graph que necesitaba mi fracaso y lo dejé lo bastante pequeño para probarlo otra vez en el próximo trabajo largo.

Para no descubrir dieciséis horas después que todo estaba mal.

Referencias

1. LangChain, “3 Years of Graph Engineering with LangGraph”, sobre el término Graph Engineering y el diseño explícito de workflows de Agents como graphs. ↩

2. OpenAI, “Build skills”, sobre cómo guardar workflows reutilizables como Skills de Codex. ↩

3. OpenAI, “Subagents”, sobre cómo un Agent principal crea un subagent separado y recoge su resultado. ↩