El diagrama de Gergely Orosz sobre la fábrica de software interna de OpenAI ha estado circulando esta semana: un desarrollador presenta un resultado, Codex escribe el código, una flota de agentes de revisión especialistas discuten sobre el riesgo, y un agente supervisa el despliegue mientras monitorea los paneles que él mismo construyó. También es, para las partes que más importan a los propios ingenieros de OpenAI, una descripción de herramientas internas que no se pueden instalar.
Perf Factory, Sevbot y el despliegue agéntico con paneles autoconstruidos se ejecutan en la propia pila de observabilidad de OpenAI y no forman parte del producto Codex que se puede comprar. Lo que sí puedes construir esta semana es un bucle más pequeño que aún realiza trabajo real: un desarrollador define el resultado como una incidencia, Codex trabaja en la rama, CI comprueba que el cambio realmente se comporta, uno o dos agentes revisores lo analizan, y un humano da el visto bueno a cualquier cosa arriesgada antes de que se envíe detrás de una bandera. Todo esto se basa en un detalle que el diagrama original pasa por alto: "CI pasa" solo significa algo si CI comprueba las cosas correctas. Para una API, eso significa probar la API, no solo el código que la llama.
Lo que el diagrama acierta (y lo que no puedes copiar)
La parte pública del artículo de Pragmatic Engineer describe un bucle central donde Codex "realiza una serie de cambios de código hasta que alcanza su objetivo y luego verifica que el software funciona como debería". Las áreas de bajo riesgo pueden autoaprobarse; los cambios de mayor riesgo reciben más revisión de IA o un pase humano obligatorio. Esa estructura, proponer, verificar, revisar por nivel de riesgo, es portátil. Los equipos la han aproximado con bots de pull request y puertas de CI durante años; los agentes simplemente hacen que el bucle sea más rápido y menos supervisado.
Lo que no es portátil es la maquinaria interna que lo rodea. Perf Factory filtra alertas y paneles para encontrar regresiones de latencia y proponer soluciones. Sevbot investiga incidentes y responde preguntas en Slack, aunque no ejecuta mitigaciones por sí mismo. El despliegue agéntico observa un cambio en producción y construye su propio monitoreo utilizando la pila de telemetría interna de OpenAI. Ninguno de esos tres se envía en el producto externo Codex. Lo que sí se envió es la aplicación de escritorio, el comando /goal para tareas de larga duración, y los complementos y habilidades de rol que configuras tú mismo. La página del producto Codex de OpenAI cubre lo que realmente está disponible.
El bucle de cinco pasos que puedes ejecutar esta semana
Una versión a escala reducida se ve así:
- Un desarrollador registra el resultado como una incidencia. No es una lista de tareas, sino una descripción del estado final: "los pedidos pueden llevar un código de descuento opcional que reduce el total". Entregar esa misma incidencia de GitHub a un Agente en Sharkly es la integración enviada: la incidencia se convierte en una Tarea, y la ejecución regresa como una PR en lugar de un ticket separado para conciliar. Actualmente es gratis para organizaciones de hasta 10 personas.
- Codex trabaja en la rama con
/goal. Como se explica en cómo el comando/goalimpulsa las ejecuciones autónomas de Codex y Claude Code, le das al agente un objetivo y lo dejas iterar por sí mismo hasta que se cumpla el objetivo. - CI ejecuta compilación, pruebas unitarias y escenarios de prueba de API. Este es el paso que la mayoría de los equipos omiten o construyen a medias.
- Uno o dos agentes revisores comprueban el diff, y un humano revisa cualquier cosa por encima del bajo riesgo. Las herramientas de revisión de código de IA pueden detectar muchos errores antes de que un humano abra la PR. En Sharkly, aquí es donde Ready for Release hace el trabajo: un humano tiene que mover la tarea de ese estado antes de que algo llegue a Hecho, y un Agente revisor separado puede sentarse en el mismo Equipo que el que escribió el código.
- Despliega detrás de una bandera de características, para que una fusión incorrecta sea un interruptor, no un incidente.
El paso 3 es donde el bucle funciona o te engaña.
Por qué CI tiene que probar la API, no solo el código
La propia función de revisión de Codex, cubierta en cómo funciona la revisión de código de Codex, lee el diff y marca problemas obvios. No ejecuta tu servicio y comprueba lo que devuelve. Las pruebas unitarias, si el agente las escribió o las mantuvo, verifican principalmente que el código hace lo que el código pretende, lo cual no es lo mismo que verificar que la API hace lo que el contrato promete. Un agente que edita un controlador puede pasar todas las pruebas unitarias mientras rompe silenciosamente la respuesta de la que dependen todos los clientes.
Supongamos que ejecutas una API de pedidos. POST /api/orders crea un pedido y devuelve su registro; GET /api/orders/{id} lo recupera por ID. Mantienes una especificación OpenAPI para ambos, y construiste escenarios de prueba de Apidog contra ella: crea un pedido, recupéralo y comprueba cuatro cosas que una prueba unitaria normalmente no haría:
- Códigos de estado.
POST /api/ordersdevuelve201, no200o un silencioso500en un caso límite de validación. - Esquema de respuesta contra la especificación OpenAPI. El campo
total_amountpermanece como un número,statuspermanece como uno de los valores enumerados que definiste, y ningún campo del que dependan los clientes desaparece o se renombra silenciosamente. - Fallos de autenticación. Una solicitud sin un token válido devuelve
401, no un 200 con un cuerpo vacío, lo cual es una regresión sorprendentemente común. - Umbral de latencia. El escenario afirma que la respuesta regresa por debajo de un límite establecido, por lo que un cambio que añade una llamada a la base de datos sin lotes dentro del controlador se detecta antes de que un cliente lo note.
Esas son exactamente las comprobaciones que una refactorización a nivel de controlador puede romper silenciosamente mientras todas las pruebas unitarias siguen pasando, porque las pruebas unitarias suelen simular el límite que el escenario de la API realmente ejercita.
Conectándolo a la pipeline
Ya ejecutas la versión CLI de estos escenarios localmente si seguiste cómo usar la CLI de Apidog en Codex. El mismo comando se ejecuta en CI. Un trabajo de GitHub Actions que compila, ejecuta pruebas unitarias y luego ejecuta el escenario de Apidog se ve así:
name: CI
on:
pull_request:
push:
branches: [main]
jobs:
build-test-verify:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Build and run unit tests
run: npm run build && npm test
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run orders API test scenario
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 88214 \
-e 3301 \
-r cli,junit
- name: Upload Apidog reports
if: always()
uses: actions/upload-artifact@v4
with:
name: apidog-reports
path: apidog-reports/
Los valores -t y -e son tus IDs reales de escenario y entorno de Apidog, no marcadores de posición que inventes. La referencia del comando apidog run cubre cada bandera, y los informes de prueba de la CLI de Apidog explican la salida JUnit que el trabajo sube. apidog run sale con un código distinto de cero en cualquier aserción fallida, por lo que GitHub Actions marca el trabajo como fallido de la misma manera que lo haría para una prueba unitaria fallida.
Cómo se ve el prompt del agente
El objetivo de /goal es que describes el resultado y la condición de salida, y Codex itera sin que apruebes cada paso. Para el ejemplo del código de descuento, un prompt razonable sería:
/goal Add an optional `discount_code` field to POST /api/orders. Validate it
against the promotions service and apply the discount to `total_amount` in
the response. Do not rename or remove any existing response field. Run
`npm test` and `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` before you finish. Both must exit 0. If the Apidog run fails, read the
failing assertion and fix the handler, not the test.
Esa última línea importa. Un agente bajo presión para poner una verificación en verde a veces editará la aserción en lugar del error. Indicarle explícitamente qué lado del bucle debe arreglar mantiene el escenario de prueba como la fuente de la verdad, no como un obstáculo que debe evitarse.
Cuando el agente rompe el contrato
Codex añade el campo de descuento, y en el proceso renombra total_amount a totalAmount porque esa es la convención en un archivo que leyó cerca. Las pruebas unitarias aún pasan; comprueban las matemáticas del descuento, no el nombre del campo. La compilación tiene éxito. Luego, el escenario de Apidog se ejecuta en CI, valida la respuesta contra la especificación OpenAPI y falla: la especificación dice total_amount, la respuesta ahora tiene totalAmount, y la aserción del esquema lo detecta inmediatamente.
CI reporta una salida distinta de cero y señala la aserción de esquema fallida en la salida JUnit. Codex lee el fallo, ve que el renombramiento es la causa y lo revierte mientras mantiene la lógica de descuento. El escenario pasa, la compilación se pone en verde y la pull request avanza a revisión con una garantía real detrás de la palabra "pasando". Sin la comprobación a nivel de API, ese renombramiento se envía, y cada cliente que parsea total_amount se rompe en la próxima versión.
Clasificación de riesgos que puedes basar en la especificación
En lugar de una vaga noción de lo que se considera de bajo riesgo, vincula tu clasificación de riesgo al diff de OpenAPI. Un cambio que añade un campo opcional con un valor predeterminado es candidato para auto-merge una vez que las pruebas pasan. Un cambio que elimina un campo, renombra uno o cambia un código de estado nunca es de bajo riesgo, independientemente de cómo se vea el resto del diff. Esa única regla detecta la mayoría de lo que un agente de revisión especializado señalaría de todos modos. Dirige cualquier cosa que la regla señale a un revisor humano o a una segunda pasada de una herramienta de revisión de código de IA antes de fusionar.
Despliega detrás de una bandera, no al vacío
Una vez que un cambio supera el CI y la revisión, despliégalo detrás de una bandera de características en lugar de directamente a todos los usuarios. Este es el sustituto barato del paso de despliegue agéntico de OpenAI: ningún agente supervisa el lanzamiento o construye sus propios paneles de control. Una bandera que comienza con un 5% de tráfico y una persona que verifica las tasas de error antes de cambiarla al 100% te brinda la mayor parte de la seguridad sin ninguna de las herramientas internas. Si algo sale mal, desactivas la bandera en lugar de revertir una fusión bajo presión.
Un andamio que ya existe
No tienes que construir los cinco pasos desde cero. orchflows es un proyecto de código abierto que apareció en las respuestas al hilo de Orosz: un comando /software-factory con licencia MIT para Claude Code y Codex, construido alrededor de un pequeño número de habilidades reutilizables. Es un andamio inicial, no un reemplazo para los pasos de CI y revisión anteriores; aún lo apuntas a tus propios escenarios de prueba y reglas de riesgo.
Qué evitar construir
No intentes reproducir Perf Factory, Sevbot o el despliegue agéntico con paneles de control auto-construidos. Son sistemas internos de OpenAI conectados a telemetría que la mayoría de los equipos no utilizan. Los humanos en OpenAI todavía definen resultados, aprueban cambios de alto riesgo, autorizan mitigaciones de incidentes y están de guardia; como dijo OpenAI, "la guardia no es cosa del pasado". Copia las partes del bucle que son simplemente una buena disciplina de ingeniería: verifica antes de fusionar, clasifica el riesgo por lo que realmente cambió y mantén a un humano en cualquier cosa que no sea obviamente segura.
Pon el bucle en marcha
Comienza con el paso de CI; hace que todos los demás pasos sean dignos de confianza. Construye tu escenario de prueba de API de pedidos en Apidog, cubriendo códigos de estado, esquema, autenticación y un presupuesto de latencia. Conéctalo a tu pipeline con la CLI, apunta /goal a una incidencia real y deja que Codex itere contra una verificación que realmente asegura el comportamiento de la API en lugar de confiar en la palabra del agente. Descarga Apidog para construir el primer escenario, luego añade los pasos de revisión y bandera una vez que el bucle demuestre su valía.