La gente pregunta si PaellaDoc es una alternativa a Codex. No lo es. PaellaDoc ejecuta Codex. La comparación de verdad es Codex solo en tu terminal, frente a Codex corriendo dentro de PaellaDoc, donde su resultado tiene que pasar un gate independiente antes de que algo se dé por “hecho”. Codex es el agente que escribe el código. PaellaDoc es la capa que decide si ese código está realmente bien.
Qué hace Codex
Codex es el agente de programación por línea de comandos de OpenAI. Lo apuntas a un repo, lee el código, escribe y edita ficheros, lanza los tests e itera hasta que todo se ve en verde, usando los modelos de OpenAI. Vive en tu terminal o en CI, y se le da bien el ciclo de convertir una instrucción en un cambio que funciona. Si lo has usado, sabes que va rápido y se come buena parte del trabajo pesado de escribir y arreglar código.
Eso es una virtud real, y PaellaDoc no intenta replicarla. Escribir código es el trabajo de Codex, y lo hace bien.
Qué hace PaellaDoc
PaellaDoc es una capa local que se coloca alrededor del agente. Ejecuta Codex (y Claude Code, Kimi, o cualquier agente CLI) en un worktree de git aislado en tu máquina, agnóstico al modelo, con tu propia suscripción. Encima añade las piezas que deciden si el trabajo valía algo:
- Un gate de ejecución. El “hecho” no es un build en verde. El hecho es el código corriendo contra unos criterios de aceptación que escribiste primero. El gate ejecuta el cambio en un sandbox y lo comprueba contra esos criterios. Si no pasa, no se hace ship.
- Artefactos de producto versionados. Un PRD, épicas, historias de usuario y criterios de aceptación se vuelven ficheros
.paellareales en tu repo, comparables entre ejecuciones, construidos y compartidos a través de un SDK abierto de packs (method, stack, design, validator). - Routing multiagente por tarea. Cada tarea puede ir a un agente distinto. Codex en una, otro modelo en la siguiente, elegido por tarea en vez de quedar atado a una sola herramienta.
- Un modo no-coder que construye un producto entero a partir de una descripción en lenguaje normal, para quien no sabe leer un diff.
- Control por Telegram para arrancar trabajo, revisar un gate o aprobar un paso desde el móvil.
- Una sala de control multirepo que abre, organiza y etiqueta los cien repos que ahora tienes en la máquina.
La diferencia que importa
Codex decide que ha terminado cuando los tests pasan y el build está en verde. PaellaDoc decide que ha terminado cuando el código hace lo que especificaste, comprobado ejecutándolo. No son lo mismo, y en ese hueco entre ambos es donde vive casi todo el dolor. Codex optimiza hacia una ejecución en verde. PaellaDoc trata el verde como un punto de partida y hace una pregunta aparte: ¿esto cumple de verdad los criterios?
Por eso las dos cosas se suman en lugar de competir. Sigues queriendo a Codex escribiendo código lo más rápido que pueda. También quieres algo que no se lo crea sin más.
Por qué un build en verde no basta
Lo medimos en un benchmark público de 210 ejecuciones, exactamente sobre esto. El resultado de un agente en crudo pasaba el build pero estaba genuinamente mal un 40% de las veces. Y el modelo frontier más potente a máximo esfuerzo seguía fallando una tarea difícil dos de cada tres veces, fallando en ejecuciones distintas cada vez. Ese es todo el argumento del gate independiente: que el build se ponga verde te dice que el código compila y que los tests existentes están contentos, no que la feature sea correcta. El análisis está aquí, un build en verde no es una feature correcta.
Código, o producto
Codex produce código. PaellaDoc intenta que tú produzcas producto. La metodología, la especificación, los criterios de aceptación, las decisiones, todo se vuelve artefactos versionados de primera clase en .paella, en lugar de vivir en un historial de chat que desaparece al cerrar la terminal. Escribes los criterios primero, el trabajo se mide contra ellos, y el resultado es algo que puedes comparar, revisar y reutilizar. La comunidad construye packs encima: method packs para cómo trabajas, stack packs para tu tecnología, design packs para tokens y theming, validator packs para los propios gates. Haces producto, no solo código.
PaellaDoc no reemplaza a Codex, lo ejecuta
Que quede muy claro: PaellaDoc no es una alternativa a Codex. Codex es uno de los agentes que PaellaDoc ejecuta. Si te encanta Codex, sigue usando Codex. PaellaDoc le da un worktree donde trabajar, le pasa una tarea con sus criterios de aceptación enganchados, y luego verifica el diff que produce. La pregunta que sale siempre es “¿PaellaDoc reemplaza a Codex?”, y la respuesta es no, lo ejecuta y comprueba su trabajo. Todo lo que Codex hace bien, te lo quedas. Lo que añades es la verificación y la capa de producto que él no tiene.
Lo que compartimos
Las dos ejecutan agentes de programación reales contra un repo real, en local, en tu terminal. Las dos leen código existente y actúan sobre él. Las dos encajan en el ciclo normal de un desarrollador en vez de pedirte que muevas tu código a otro sitio.
Y Codex va por delante en lo que un laboratorio grande hace bien: es más maduro, más pulido, está mejor financiado y lo respaldan directamente los modelos sobre los que corre. PaellaDoc es temprano y lo construye un fundador en solitario. Si hoy quieres la experiencia de agente en crudo más refinada, esa es Codex, y está bien, porque PaellaDoc la ejecuta.
| Codex | PaellaDoc | |
|---|---|---|
| Ejecuta un agente de código sobre tu repo | Sí | Sí (ejecuta Codex y otros) |
| Lee código existente y actúa sobre él | Sí | Sí |
| Local, en tu terminal | Sí | Sí |
| Elección de modelo / agente | Modelos de OpenAI | Agnóstico al modelo, routing por tarea |
| “Hecho” decidido por un gate de ejecución | No (build en verde) | Sí (ejecuta tus criterios de aceptación) |
| Artefactos de producto versionados (.paella) | No | Sí (PRD, épicas, historias, criterios) |
| SDK abierto de packs (method/stack/design/validator) | No | Sí |
| Modo no-coder | No | Sí |
| Control remoto por Telegram | No | Sí |
| Sala de control multirepo | No | Sí |
| Madurez, pulido, financiación, escala | Por delante | Temprano, fundador en solitario |
Para quién es cada uno
Si eres un desarrollador que quiere el agente más rápido y pulido para escribir y arreglar código en tu terminal, y confías en tu propio criterio para juzgar si el resultado está bien, Codex por su cuenta es una opción fuerte. Hace bien el trabajo central y lo respalda un laboratorio.
Si quieres el código escrito por un agente pero no quieres dar por bueno el build en verde a ciegas, si quieres que el trabajo se convierta en artefactos de producto versionados que puedas comparar y reutilizar, si quieres repartir tareas entre modelos o construir para alguien que no sabe leer un diff, PaellaDoc es la capa que poner alrededor. Y el agente dentro de esa capa puede ser Codex.
PaellaDoc no es mejor que Codex. Hace un trabajo distinto. Codex escribe el código. PaellaDoc decide si ese código está bien y convierte el trabajo en producto. Puedes ver cómo encaja ese enfoque frente a otras herramientas en el hub de comparativas.