AI Engineering Orchestrator: usar mejor el modelo de IA caro al desarrollar videojuegos

En la programación asistida por IA, el recurso más caro suele ser la cuota de uso del modelo más potente: cuando se agota, el trabajo se para. AI Engineering Orchestrator, un proyecto de código abierto, reserva ese modelo caro para pensar, decidir y revisar, y delega la escritura del código en un modelo al que se accede de forma más barata, con el objetivo de sacar más trabajo de la misma cuota.

En resumen

• Claude Code o Codex hace de «líder del equipo»; el cambio de código en sí lo hace Gemini (a través de Antigravity) o, como respaldo, Cursor.
• El líder delega cada tarea con un contrato de implementación por escrito, verifica él mismo el código devuelto con git diff y los tests, y decide APROBADO o CAMBIOS NECESARIOS.
• En la medición del propio proyecto, el tiempo de API del modelo caro en una sola tarea bajó de 8 min 54 s a 3 min 39 s; el desarrollador deja claro que fue un único intento y que no garantiza ningún ahorro.
• Tiene licencia MIT, se instala desde npm con un solo comando y solo toca la configuración del proyecto donde se instala.

¿Para qué sirve AI Engineering Orchestrator?

Hoy muchos desarrolladores tienen dos tipos de acceso a la IA. Uno es un modelo caro pero con un razonamiento potente: marca la diferencia en las decisiones de arquitectura, la depuración y la revisión de código, pero el límite de la suscripción o la factura de tokens se llena rápido. El otro es un modelo al que se accede de forma más barata, o que incluso está sin usar dentro de un plan que ya se paga. El problema es que la mayoría encarga todo el trabajo al modelo caro, incluida la escritura de código rutinaria.

AI Engineering Orchestrator (AEO, para abreviar) intenta corregir ese desequilibrio con un reparto de tareas. En palabras del propio proyecto, la tesis es sencilla: el modelo caro decide y el barato escribe. Técnicamente tiene dos piezas. Un puente MCP da al modelo líder la capacidad de llamar a otro modelo, y un archivo de políticas que se añade a CLAUDE.md o AGENTS.md establece cuándo se usa esa capacidad. Es decir, la idea central de la herramienta es esta distinción: una herramienta no se usa porque exista, sino porque la regla lo indica.

¿Cómo se aprovecha más el modelo caro con una cuenta barata?

Aquí «barato» es relativo. La documentación de AEO lo subraya: un modelo puede salirte barato por un plan de suscripción, un precio para estudiantes o empresas, precios regionales, una promoción o capacidad sin usar de un plan que ya pagas. El mismo modelo puede ser un mal negocio para otra persona. Por eso la herramienta no declara a ninguna empresa «la más barata»; solo te permite usar la vía de implementación más conveniente y suficientemente capaz que tengas a mano.

El flujo funciona así. El modelo caro entiende la petición, examina el repositorio lo justo y decide si el trabajo es trivial o una tarea de implementación real. Si es real, redacta un contrato acotado con el objetivo, las restricciones, los criterios de aceptación y los tests que hay que ejecutar, y lo envía al modelo implementador. Escribir el código, añadir los tests y hacer las rondas de corrección ocurre en el modelo barato. Lo que gasta el modelo caro es leer y decidir, no escribir código. Para quien trabaja con un límite de suscripción, eso significa terminar más tareas con el mismo límite.

Si en Antigravity se agota la cuota, el puente prueba primero los otros modelos de Gemini configurados; si tampoco funciona, la política dirige el mismo contrato a Cursor. El objetivo es evitar que, cuando el canal del implementador se atasca, el trabajo vuelva en silencio al modelo caro.

¿En qué ayuda a quien desarrolla videojuegos?

Los proyectos de videojuegos encajan de forma natural en el reparto que propone AEO. El código de un juego tiene a la vez pocas decisiones pero caras (arquitectura de red, autoridad del servidor, sistema de guardado, reglas de la economía) y muchas tareas repetitivas (una nueva pantalla de menú, una variante de reglas de un modo de juego, claves de localización, tests que faltan, refactorizaciones). Con la lógica de AEO, el primer grupo se queda en el modelo líder y el segundo va al implementador.

• Equipos pequeños y estudios de una sola persona: un desarrollador indie es a la vez diseñador, programador y responsable de pruebas. Guardar la cuota del modelo caro para la arquitectura y la depuración y delegar el trabajo rutinario de funcionalidades reduce el riesgo de quedarse sin límite a final de mes.
• Multijugador y código de servidor: en temas como la concurrencia, las sesiones o los permisos, la política recomienda recurrir a un agente de revisión independiente (reviewer). En estas áreas, donde un error sale caro, un segundo par de ojos es más seguro que un único modelo aprobando su propio trabajo.
• Lógica de juego con tests: los motores de reglas, el cálculo de puntuaciones, el emparejamiento y la validación en el servidor se pueden probar con tests sin interfaz (headless). Ahí es donde mejor funciona la puerta de calidad de AEO, porque el modelo líder no se fía de la frase «los tests han pasado», sino del test que ejecuta él mismo.
• Trabajo en paralelo: dos tareas que no se tocan, por ejemplo un modo de juego y una pantalla de estadísticas, se pueden dar a la vez a dos implementadores en worktrees de git separados. Los cambios solo se aplican uno a uno al árbol de trabajo principal cuando el líder los aprueba.

Una advertencia honesta: la sensación visual, el timing de las animaciones o la pregunta de si el juego es divertido no se detectan con un test. La puerta de calidad de AEO verifica el código frente al contrato; la calidad del gameplay la tienes que seguir midiendo tú jugando. La propia documentación de la herramienta admite un límite parecido: si el contrato contiene un error de diseño, el código que lo implementa al pie de la letra pasa la puerta.

¿Por qué importa la puerta de calidad?

El riesgo conocido de dar trabajo a un modelo barato es que el informe de «terminado» no refleje la realidad. Por eso AEO trata el informe del implementador como una prueba, no como una aprobación. Antes de empezar, el modelo líder registra un estado de partida con git status; cuando vuelve el trabajo, revisa él mismo las diferencias, los archivos modificados y los tests. Un test que el implementador no pudo ejecutar por un bloqueo de permisos no cuenta como «pasado». La decisión tiene dos opciones: APROBADO o CAMBIOS NECESARIOS. En el segundo caso, los hallazgos se devuelven al mismo implementador junto con sus pruebas.

Esta disciplina tiene otra ventaja: gracias al registro inicial, los cambios propios del usuario que aún no están confirmados quedan protegidos; el líder no toca ningún cambio cuya autoría no pueda demostrar. Además, los ejemplos de permisos por defecto rechazan comandos de git difíciles de deshacer, como push, reset, rebase, merge y commit.

¿Qué muestra una medición real?

En el README del proyecto se midió dos veces la corrección de un error de token de actualización (refresh token) en una API de Laravel: una vez con delegación y otra con una ejecución de control a la que se le quitaron las herramientas de delegación. Se usaron el mismo commit y el mismo prompt.

Métrica	Con delegación	Sin delegación
Tiempo de API del modelo caro	3 min 39 s	8 min 54 s
Coste calculado	3,60 dólares	4,32 dólares
Coste del modelo implementador	En una suscripción aparte, no sumado a la factura	Ninguno
Tiempo total de espera	Aproximadamente un 30 % más largo	Más corto
Fuente	README del proyecto, octubre de 2026	Una sola ejecución por rama (n=1)

El desarrollador no exagera el resultado: la diferencia en dólares es del 17 % y solo existe porque el implementador se pagó con una suscripción aparte. La ganancia real está en el tiempo de uso del modelo caro: aproximadamente un 59 % menos. En una suscripción con límite de uso, esa es precisamente la restricción que importa. A cambio, la tarea tardó aproximadamente un 30 % más por las idas y venidas con el implementador, y las dos ejecuciones produjeron una corrección de calidad similar. De una sola medición no se puede sacar una tasa de ahorro general; el proyecto también ofrece un script y un método para que midas tu propio caso.

¿Cómo se instala?

Los requisitos son Node.js 20 o superior, la herramienta de línea de comandos de Antigravity (agy) con la sesión iniciada y Claude Code o Codex como líder del equipo. La instalación empieza con una ejecución de prueba (dry run) que muestra qué va a cambiar sin escribir ningún archivo. Después, el comando npx ai-engineering-orchestrator@latest install --target . --claude (o --codex) añade al proyecto la política, las definiciones de agentes y el servidor MCP; el comando doctor comprueba la instalación. Las copias de seguridad de los archivos compartidos que se modifican se guardan en la carpeta del usuario, y la configuración global solo se toca si se indica expresamente --global.

Nota de transparencia: AI Engineering Orchestrator es un proyecto de código abierto de Akif Şen, el desarrollador de GAMEAREA, y también se utiliza en el propio proceso de desarrollo de GAMEAREA. Las cifras de medición de este artículo proceden de la documentación del propio proyecto; no son una prueba independiente. Explicamos cómo usamos la IA en el blog en nuestra página de principios de uso de IA.

Preguntas frecuentes

¿AI Engineering Orchestrator es de pago?

No. El proyecto tiene licencia MIT y se instala gratis desde npm. Los servicios de IA que uses (Claude, Codex, Gemini, Cursor) mantienen sus propias tarifas de suscripción o de uso.

¿Garantiza un ahorro de dinero?

No. El proyecto indica claramente que no mide ni garantiza ninguna tasa de ahorro. La ganancia depende de lo barato que te salga en tu cuenta el acceso al modelo implementador.

¿Con qué motores de juego funciona?

La herramienta no es un plugin de un motor de juego; funciona a nivel de repositorio. En principio, el mismo flujo se puede aplicar a cualquier base de código que entiendan los modelos que uses (da igual que sea Unity, Godot o un juego web); la solidez de la verificación depende de los tests del proyecto.

¿Qué pasa si el modelo implementador me rompe el código?

El trabajo no se da por terminado hasta que el cambio se aprueba. El modelo líder revisa las diferencias y los tests y puede decidir CAMBIOS NECESARIOS; en las tareas en paralelo, los cambios se quedan en un worktree aparte y solo se aplican al árbol de trabajo principal tras la aprobación. Operaciones como commit y push están prohibidas por defecto.

Fuentes

1. akifsen / GitHub — AI Engineering Orchestrator (README) Fuente oficial
2. akifsen / GitHub — Cost-aware routing Fuente oficial
3. akifsen / GitHub — Quality gate Fuente oficial
4. npm — ai-engineering-orchestrator Fuente oficial