[🤖] Probé a aplicar Graph Engineering a Codex

✨ Resumen de GPT-5.6 Sol

Después de que una tarea de Codex de 16 horas terminara en un desastre, cuestioné si Graph Engineering era de verdad la solución, lo reduje a un Gate Skill mínimo y lo probé con un contrato real de autorización.

Ayer, después de discutir durante horas, terminé las especificaciones página por página para una reforma completa de UI/UX y configuré un Goal de Codex para que desarrollara a partir de ellas. El Goal estuvo ejecutándose durante 16 horas.

Hoy abrí la pantalla lleno de expectativas y el resultado era, sencillamente, basura.

Dos días antes ya había escrito que debía abandonar la fantasía de la magia de un solo intento con IA. Esta vez no me limité a una instrucción de una línea. Definí el trabajo por roles y por páginas, y concreté bastante el calendario, la vista de tabla, la búsqueda, los filtros y la recuperación ante fallos. Tras varios prototipos fallidos, incluso había creado criterios específicos para auditar la UI.

Sin embargo, varios workers pasaron la noche escribiendo código y afirmando que habían superado tests y auditorías, y lo que yo vi fue una pantalla administrativa antigua cuyo significado apenas podía entender. ¿Dónde estaban el calendario y la vista de tabla de los que tanto había hablado?

Se gastaron una cantidad enorme de tokens, se cambió una cantidad enorme de código y se acumularon montones de informes PASS. Pero el resultado que yo quería no existía.

Volví a ser humilde. Otra vez.

Por eso decidí probar Graph Engineering con Codex. No quería limitarme a estudiar la última palabra de moda ni empezar instalando un framework gigantesco. Quería reducirlo a la forma más pequeña capaz de evitar el fallo que acababa de sufrir.

Apareció una razón para probar Graph Engineering

Pedí a la IA que analizara por qué había ocurrido. Las reglas compartidas eran parte del problema y la auditoría de UI se había concentrado demasiado en aspectos fáciles de medir, como el tamaño de letra o la altura de los botones. Pero el problema principal estaba en otro sitio.

Yo no revisaba cada resultado intermedio de Codex. La sesión que implementaba declaraba terminado su propio trabajo, y otras sesiones heredaban ese resultado y seguían construyendo más páginas y backend. La arquitectura de información equivocada del principio se propagó por varias pantallas antes de que nadie la verificara. Cuando abrí el producto real, ya había 16 horas de trabajo construidas sobre aquella dirección errónea.

No necesitaba una forma de dejar que la IA trabajara más tiempo.

Necesitaba una estructura que impidiera comenzar el trabajo siguiente cuando un resultado intermedio fuese incorrecto.

Mientras seguía discutiendo el problema con la IA, conocí el término Graph Engineering. Era un enfoque que, en vez de dejarlo todo al largo loop de un único Agent, conectaba varios Agents, verificadores y decisiones humanas mediante nodes y edges, y definía explícitamente qué resultados permitían pasar a la fase siguiente. Más que una tecnología completamente nueva, parecía un nombre reciente para ideas ya conocidas de workflow y state machine.¹

Lo importante no era memorizar otra palabra de moda. Ahora una sesión de Codex puede asumir un trabajo bastante grande; por tanto, el resultado producido por esa sesión puede convertirse en un node y las condiciones para pasar a la sesión siguiente pueden diseñarse de forma explícita.

Aplicado a mi experimento, Graph Engineering significaba esto:

• node: un resultado intermedio que el usuario puede revisar de forma independiente
• edge: la condición que devuelve el trabajo a corrección o lo lleva a la tarea siguiente según el veredicto
• state: el registro de qué resultado se auditó, con qué criterio y qué acción está permitida ahora
• cycle: el bucle que corrige únicamente el mismo resultado y lo vuelve a revisar cuando aparece un defecto

Llamar a más Agents no es por sí mismo Graph Engineering. El núcleo de mi prueba era diseñar primero la topología y las transiciones de estado para que un node sin verificar no pudiera abrir sus edges posteriores.

Mi primer graph solo tenía una sesión de trabajo y otra de auditoría

Cuando propuse aplicar Graph Engineering, la IA empezó enseguida a agrandar la estructura. Separó Coordinator, Worker y Auditor, y añadió aprobación humana de la dirección, versiones de contrato, un durable ledger y una auditoría final en frío.

Ninguna de esas ideas era absurda por sí sola. Aun así, me preocupaba.

“¿No estamos complicándolo sin necesidad?”

Si para impedir que 16 horas de trabajo consumieran todos los tokens sin producir nada íbamos a abrir varios Agents y acumular estados e informes, ¿qué cambiaba realmente? Si aplicar Graph Engineering se convertía en otro gran proyecto, podía volver a gastar tokens sin resultados.

Mi idea era mucho más sencilla.

La sesión de trabajo termina un resultado revisable.
→ Lo entrega a la sesión de auditoría y espera.
→ La auditoría devuelve PASS o cambios solicitados.
→ Solo entonces se reanuda la sesión de trabajo.

Pregunté si podía convertir este flujo en un Skill reutilizable. Pero la IA seguía hablando de la estructura de sesiones y de los límites de una imposición mecánica, complicándolo todo. Hasta llevé la respuesta de otra sesión y volví a preguntar.

“¿De verdad es ineficiente convertirlo en un Skill? ¿Hablas en serio o solo estás improvisando?”

También insistí en que no aceptara mi propuesta automáticamente, sino que la criticara. No buscaba oír que mi idea era correcta; quería saber si realmente evitaría otro fracaso de 16 horas o si solo estaba construyendo un juguete nuevo con aspecto sofisticado.

Reduje el experimento a base de objeciones

Después de varias revisiones críticas, admití que mi propuesta simple también tenía huecos.

Si la sesión de trabajo define incluso los criterios de auditoría, puede favorecer su propio resultado. Si la auditoría recibe todo el reasoning y la autoevaluación del worker, quizá solo relea su explicación en lugar de evaluar de forma independiente. Si el siguiente trabajo empieza mientras la auditoría sigue abierta, el PASS gate no sirve. También era posible revisar una pantalla antigua después de que cambiara el Runtime o recordar erróneamente un PASS tras una compaction de la conversación.

Pero tampoco era necesario aceptar todo lo que proponía la IA. Descarté tres sesiones permanentes, un graph runtime separado, una base de datos, un dashboard, auditorías de cada página y una nueva revisión total cada vez que cambiara el contrato. Con todo eso, el sistema de gestión sería mayor que el producto.

Al final conservé solo estos principios:

• La sesión principal coordina y trabaja.
• Solo se abre una sesión separada de auditoría para resultados que realmente necesitan Gate.
• La auditoría no recibe toda la conversación anterior.
• Se congela el resultado auditado y no se toca ni él ni su trabajo directamente posterior hasta terminar la revisión.
• Se distingue entre una implementación incorrecta y una dirección de trabajo incorrecta.
• Si tras una corrección y una segunda auditoría sigue habiendo un problema importante, se deja de parchear y se reabre el plan.
• Si cambia el contrato, solo se vuelven a auditar las partes afectadas.
• Un PASS de auditoría no sustituye mi aprobación de la dirección del producto ni autoriza el despliegue.

Sobre todo, decidí no aplicar esta estructura a todos los trabajos. Una errata, un bug que se resuelve con un test decisivo o una exploración libre sin camino conocido no justifican otra sesión de auditoría. El Gate solo debe colocarse donde un resultado equivocado pueda contaminar múltiples trabajos posteriores.

Tampoco convertí automáticamente cada página en una unidad. Si el trabajo real consiste en buscar en una lista, entrar en un detalle, actuar y volver al mismo filtro, todo ese journey es la unidad revisable. En cambio, no hay razón para auditar por separado cada pantalla que solo repite el mismo pattern.

Así mantuve el graph sencillo que quería, pero dejé claro por qué detenerse y qué revisar.

Convertí el graph mínimo en un Codex Skill

Finalmente pedí a Codex un Skill compartido llamado custom-graph-engineering-gate. OpenAI ya ofrece una forma de guardar workflows repetibles como Skills y de hacer que el Agent principal invoque un subagent separado y recoja su resultado.²³ No necesitaba crear otro servicio para organizar el intercambio entre la sesión de trabajo y la de auditoría.

También exigí que la implementación no creciera. No creé scripts de ejecución, otra base de datos ni un graph dashboard. Solo el cuerpo del Skill y los metadatos mínimos para mostrarlo en Codex.

El Skill hace tres cosas principales.

Primero, decide si el trabajo es lo bastante importante como para necesitar un Gate. Solo se usa cuando un resultado intermedio incorrecto podría estropear varios resultados posteriores.

Segundo, congela en una frase el resultado que se auditará. Registra el resultado que recibirá el usuario, el criterio que separa éxito y fracaso, el candidate exacto, la ruta normal de verificación y el trabajo posterior directo que abrirá un PASS. El número de archivos o tests nunca sustituye ese resultado.

Tercero, restringe las transiciones entre trabajo y auditoría.

PASS              → avanzar solo al trabajo directamente posterior
CHANGES_REQUESTED → corregir una vez el mismo resultado y volver a auditar
REPLAN_REQUIRED   → revisar el contrato o la división del trabajo, no seguir implementando
NOT_VERIFIABLE    → no aprobar sin evidencia

La sesión de auditoría no hereda la conversación anterior. Mi enfado, el esfuerzo de la sesión de trabajo y las partes que el implementador considera buenas no son evidencias. El reviewer observa directamente el requisito original y el resultado actual.

Si cambian el source o el Runtime durante la auditoría, se descarta el veredicto anterior. Si una interrupción o compaction impide reconstruir qué candidate recibió qué veredicto, el Skill no supone que pasó.

Esto no difiere mucho de mi idea inicial. Solo fijé en el Skill las condiciones de transición que se olvidan fácilmente, para que la propuesta de “mantener una sesión de auditoría” pueda ejecutarse con la misma topología en la siguiente sesión.

Probé el graph con un contrato real

Si confiara en el Skill solo porque ya estaba creado, repetiría el mismo error. Por eso entregué el propio Skill nuevo a un reviewer separado que no había heredado la conversación previa.

Primero confirmé que no debía utilizarse para una simple corrección de texto. No usarlo cuando no hace falta fue la primera prueba contra el desperdicio de tokens.

Después escogí como primer node real un contrato de transición de autorización del que dependerían varias funciones. Congelé el candidate y lo envié a la auditoría. El primer veredicto no fue PASS, sino CHANGES_REQUESTED. No estaba suficientemente claro en qué momento se evaluaban los permisos, de dónde procedía una delegación y cómo se propagaba su revocación, ni si usuario, permiso y empresa objetivo estaban realmente vinculados al mismo scope.

Si lo hubiéramos extendido a varias funciones, más tarde habría sido necesario reconstruir toda la frontera de autorización. La sesión de trabajo corrigió solo ese alcance y la misma auditoría lo revisó de nuevo antes de devolver PASS. Durante todo ese tiempo, la implementación posterior y el despliegue permanecieron cerrados.

Era una prueba pequeña, pero produjo el efecto de Graph Engineering que buscaba. El edge posterior quedó cerrado en un node que el worker había considerado “suficiente” y el problema se corrigió antes de propagarse. Solo después de que la misma auditoría revisara el candidate corregido y devolviera PASS se pudo abrir el siguiente paso.

El primer experimento pasó, pero aún no ha resuelto el fracaso de UI

El graph funcionó como esperaba en la primera prueba. Pero todavía no puedo afirmar que este Skill habría evitado el desastre de UI de 16 horas. Revisar un contrato de autorización con un source relativamente explícito no es lo mismo que detener a tiempo una dirección visual equivocada. Aún no he comprobado si reduce el tiempo y los tokens totales en un gran trabajo real de UI. La auditoría usa el mismo modelo y ve el mismo Working Tree, por lo que puede compartir los supuestos erróneos del worker. Un Skill es una instrucción, no un motor de enforcement.

Por eso, el siguiente trabajo largo no debe evaluarse por el número de PASS.

• ¿Detectó la primera dirección equivocada antes de expandirla?
• ¿La reelaboración evitada fue mayor que el coste en tokens de la auditoría?
• ¿Retrasó el momento en que yo vi el primer resultado provisional?
• ¿Compartieron las sesiones de trabajo y auditoría el mismo contrato erróneo?

Si no resulta útil, debo usar menos Gates, no añadir más reglas. Si el mismo fallo se repite, antes de sumar otra etapa de auditoría debo revisar qué agrupé como un único resultado y qué evidencia mostré al reviewer.

Conocer el término Graph Engineering no me convirtió de pronto en alguien experto usando IA. Pero esta vez no instalé un gran framework apenas oí una palabra de moda. Conservé solo el graph necesario para el fallo que había sufrido, seguí cuestionando las propuestas excesivas de la IA y lo convertí en un Skill pequeño que puedo volver a probar en futuras sesiones.

Para no descubrir, solo después de 16 horas, que toda la dirección estaba equivocada.

Referencias

1. LangChain, “3 Years of Graph Engineering with LangGraph”. Explica el término reciente Graph Engineering y la idea de diseñar workflows de Agents como graphs explícitos. ↩

2. OpenAI, “Build skills”. La vía oficial para guardar workflows repetibles como Codex Skills. ↩

3. OpenAI, “Subagents”. Explica cómo un Agent principal puede crear subagents separados y recoger sus resultados. ↩