- Un ingeniero senior con 14 años de experiencia comparte una comparación en condiciones reales entre Claude Code (Opus 4.6) y Codex (GPT-5.4) en un proyecto de Python/TypeScript de 80 mil líneas de código
- Claude Code es rápido e interactivo, pero necesita gestión activa porque ignora instrucciones, deja tareas incompletas y agrega funciones indiscriminadamente a archivos existentes
- Codex es 3 a 4 veces más lento, pero más cuidadoso y sistemático al escribir código; además, refactoriza por iniciativa propia y cumple rigurosamente el archivo de instrucciones (
AGENTS.md) - La evaluación es que Claude Code encaja mejor en prototipado rápido, mientras que Codex resulta más adecuado para desarrollo de software de nivel enterprise
- En conclusión, ambos comparten un mismo límite: sin capacidad real de ingeniería de software es difícil obtener buenos resultados
Contexto del autor y entorno de desarrollo
- Ingeniero de nivel Principal/Staff Eng Manager con 14 años de experiencia en MAG7 (las 7 grandes tecnológicas de EE. UU.) y otra empresa tecnológica importante
- Su fortaleza principal es el desarrollo a nivel de plataforma, con amplia experiencia en sistemas distribuidos
- El proyecto consiste en una base de código Python/TypeScript de 80 mil líneas en forma de extensión de VSCode, con unos 2,800 tests
- Es una aplicación de análisis de datos que permite subir archivos PDF/CSV/XML, los parsea y los normaliza en un modelo de datos estructurado basado en Postgres
- Se conecta por WebSocket a un proveedor de datos en tiempo real del backend para transmitir datos actuales al modelo
- En el servidor se actualiza el análisis basado en flujos de datos y se envía a la UI web mediante SSE (Server-Sent Events)
- No se trata de vibe coding, sino de desarrollo basado en una arquitectura sistemática
Flujo de trabajo común con agentes
- Primero comienza en modo Plan con prompts de alcance bien definido y ejecuta, mediante la habilidad plan-review, 8 subagentes (arquitectura, estándares de código, diseño UI, rendimiento, etc.)
- Cada subagente tiene prompts concretos junto con documentos de referencia creados en sesiones previas de investigación (por ejemplo,
postgres_performance.md,python_threading.md,software_architecture.md)- El especialista en revisión de arquitectura recibe prompts preparados para revisar con referencias a conceptos como SOLID, DRY, KISS, YAGNI
- Después de escribir código, hace commits separados por cada etapa del plan, revisa cada commit con la habilidad code-review (reutilizando los subagentes del plan) y verifica/ajusta manualmente el feedback
CLAUDE.mdtiene unas 100 líneas e incluye TDD, flujo de trabajo con Git, principales convenciones de DevEx, comandos de Docker y uso de herramientas del proyecto
Experiencia con Claude Code (Opus 4.6)
- Da la impresión de un ingeniero corriendo contra la fecha límite, más enfocado en implementar funciones con hacks, parches y helpers en exceso que en revisar la arquitectura central
- Es interactivo, pero por eso mismo requiere más supervisión constante
- Produce código funcional rápidamente, pero no piensa lo suficiente antes de actuar
- Incluso gestionando activamente el contexto de forma manual (considera que un contexto de 1M es una trampa para principiantes y que debe mantenerse en menos de una cuarta parte), en casi todas las sesiones ocurren casos donde ignora abiertamente
CLAUDE.md - A veces deja tareas a medio terminar
- Ejemplo: al migrar patrones asíncronos en 8 suites de tests, procesa la mayoría pero deja algunas con el patrón antiguo
- Casi no crea archivos nuevos para funciones nuevas y, en cambio, sigue agregando funciones a archivos existentes
- Esto choca con su preferencia por principios OO estrictos y mantener menos de 600 líneas por archivo
- Cuando se rompen tests, tiende a modificarlos por su cuenta sin prompt, así que tuvo que añadir muchas instrucciones del tipo “si un test falla, detente y pregúntame”
- El 95% de los tests que escribe son útiles, pero el 5% fija comportamientos incorrectos, y eso se acumula con el tiempo
Experiencia con Codex (GPT-5.4)
- Se siente como un ingeniero semi senior de 5 a 6 años de experiencia que, incluso sin instrucciones extra, se detiene por su cuenta para rehacer el código y dejarlo más limpio
- Es 3 a 4 veces más lento que Claude (para la misma tarea)
- Trabaja de forma más cuidadosa e intencional, y a diferencia de Claude no se dedica a expandir una
'god class', sino que factoriza el código de forma más compacta automáticamente - Revisa sus propias suposiciones durante el trabajo y rehace cosas a mitad del proceso para ordenarlas mejor
- A veces realiza por iniciativa propia trabajos adicionales valiosos que no se habían pedido
- Nunca lo vio ignorar
AGENTS.md, y ni siquiera acepta que se intente sobreescribir esas instrucciones durante la sesión - Como ya demostró suficiente capacidad, pudo pasar a un flujo de dejarlo trabajar y revisar al final, sin necesidad de monitoreo en tiempo real
Comparación general
- El límite de uso de Codex Pro x5 está en un nivel similar al de Claude x20
- Codex es claramente más lento y menos interactivo, pero más cuidadoso; Claude es rápido e interactivo, pero requiere supervisión
- En una sola sesión, Claude puede sacar más volumen de trabajo, pero la calidad del trabajo de Codex es superior
- Claude permite prototipado y construcción extremadamente rápidos, pero cada pocos días hay que guiar refactorizaciones
- Codex también necesita refactorización cuando la app crece, pero ya no en el sentido de “qué problemas hay que ordenar”, sino más bien de “la app ya creció y llegó el momento de refactorizar”
- Para vibe coding en proyectos de complejidad baja a media, Claude puede terminar antes
- Para construir software enterprise, Codex resulta más adecuado
- Ambos son útiles, pero Claude necesita un conductor más experto y concentrado que Codex
- Si no sabes nada de ingeniería de software, ambos producirán malos resultados
📋 Resumen de los principales puntos en los comentarios de Reddit
Estrategia de uso combinado de ambas herramientas (la más mencionada)
- El patrón más popular es un flujo de validación cruzada: borrador/trabajo rápido con Claude → revisión de código con Codex
- “Haz que Codex revise el código escrito por Claude, y también al revés” — es muy raro que ambos modelos alucinen de la misma manera
- También hay usuarios que usan una estrategia de pase de estafeta hacia Codex cuando se agotan los tokens de Claude
- Guardan el estado en
save-state.mdynext-task.mdpara que Codex continúe, y la calidad del handoff mejora en cada transición
- Guardan el estado en
- También existen casos donde envuelven Codex CLI como servidor MCP para automatizar la colaboración de Codex dentro de Claude Code
- Después del trabajo de Claude, Codex devuelve sugerencias y Claude las implementa, con lo que la calidad del código mejora drásticamente
- También funciona pasar todo el día trabajando con Codex, hacer el pulido final con Claude y luego volver a Codex
Coincidencia con las fortalezas de Codex
- Ya hay usuarios que bajaron Claude Code del plan 20x ($200) al 5x ($100) y lo combinan con el plan de Codex de $100
- No se percibe una brecha de calidad grave entre GPT-5.4 y Opus 4.6, y según el problema el resultado queda 50:50
- “Simplemente lo dejas corriendo, vas por un café y cuando vuelves ya terminó” — en ejecución autónoma (fire-and-forget), Codex supera a Opus
- Codex sigue
AGENTS.mdcon tanta disciplina que hasta rechaza ignorarlo, salvo que se le indique explícitamente sobreescribirlo - También hay reportes de mejores resultados tras pasar a un esquema puramente con Codex de plan + implementación + revisión con otra instancia separada de Codex
Desventajas de Codex
- La mayor queja es su estilo de comunicación robótico
- Por ejemplo, en vez de escribir en una línea los valores de un dict de Python como
[0.1, 0.3, 0.5, 0.7, 0.9], los muestra uno por línea - Algunos especulan que el entrenamiento por RL recompensó una conducta del tipo “mientras más viñetas, mejor”
- Incluso ajustando la configuración de comunicación, oscila entre extremos (demasiado poco vs demasiado) y cuesta encontrar un punto medio
- Por ejemplo, en vez de escribir en una línea los valores de un dict de Python como
- Tiene tendencia a contradecir constantemente al usuario: aunque un desarrollador con más de 10 años de experiencia le dé instrucciones claras, sigue objetando, y al final ni siquiera propone una alternativa mejor
- El diálogo se alarga sin fin, y eso lo vuelve disperso en vez de centrarse en la tarea
- Al implementar funciones grandes, a veces omite muchas partes y no logra entender bien la codebase existente
- Por ejemplo, aunque ya exista un formatter, crea uno nuevo por su cuenta, o inserta cadenas hardcodeadas en un ViewModel
- En funcionalidades va por detrás de Claude Code en hooks, soporte MCP y plugins, así que cambiarse puede sentirse como un retroceso
Coincidencia con los problemas crónicos de Claude Code
- Hay un acuerdo amplio sobre el patrón de Claude de ignorar las instrucciones del usuario y actuar como él quiere
- “Claude intenta ejecutar lo que imagina que tú quieres” — la confiabilidad en seguir instrucciones es baja
- Se han visto casos donde hardcodea 100 objetos de una lista y asegura que eso es un éxito, incluso saltándose hooks diseñados para evitarlo
- En los últimos meses se ha intensificado la tendencia de Claude a no encontrar el problema real en código complejo
- Parchea solo síntomas en vez de la causa raíz y luego afirma con seguridad que “encontró el problema”
- A veces Codex también queda arrastrado por análisis seguros pero incorrectos de Claude
- También hay usuarios que cancelaron su suscripción porque Claude consume créditos demasiado rápido, al punto de no dejar tiempo ni para aprender a usarlo
Opinión contraria: la visión de que Claude sigue por encima
- Hay experiencias donde Opus 4.6 muestra un pensamiento más cuidadoso y profundo, y una mejor calidad de análisis en diseño/arquitectura que GPT-5.4
- En algunas revisiones, Opus detectó problemas adicionales que GPT-5.4 no encontró
- Aunque también podría relacionarse con rumores de que los modelos recientes de Claude fueron modificados para “usar menos esfuerzo”
- Si se le exige Clean Architecture, Claude también crea archivos nuevos activamente y no aparece el problema de la god class
- Si ambas herramientas respetan la arquitectura, la calidad del código es casi equivalente; la diferencia está en la velocidad y la facilidad de uso
- Si se construye un flujo sistemático (plan mode + custom skills + feedback de coderabbit/sonarqube), se puede seguir produciendo buen código incluso en periodos en que otros usuarios se están quejando, sin llegar al límite
Otras opiniones interesantes
- “Impresiona que el equipo de Anthropic pueda lanzar tantas funciones, considerando que Claude escribe el 100% del código” (sarcasmo)
- “Programar con Codex → revisar en Claude → meter también a Gemini en la revisión” — estrategia de revisión cruzada con 3 modelos, donde a veces Sonnet detecta cosas que Opus no ve
- También existe la expectativa de que Mythos (el modelo de próxima generación) reduzca este tipo de manejo complicado
18 comentarios
Cualquiera de los dos necesita HITL. (al menos hasta hoy)
Por favor, ojalá no empiecen con cosas como ese tal Ralph Loop.
Yo solo uso Codex, y coincide exactamente con lo que he sentido.
También va bien con mi forma de trabajar, así que lo estoy usando mucho.
Estaba pensando pasarme a Claude cuando se me acabara ChatGPT en KakaoTalk,
pero siento que, de alguna manera, las desventajas de Claude no van con mi estilo..
¿Habrá diferencias en los lenguajes principales que usan los usuarios de Claude y Codex?
> Tendencia a contradecir constantemente al usuario: incluso cuando un desarrollador con más de 10 años de experiencia da instrucciones claras, sigue poniendo objeciones y al final ni siquiera propone una buena alternativa por su cuenta.
jaja
Parece que también debe haber diferencias en la forma de usarlo. Dependiendo del estilo de cada desarrollador, la manera de manejarlo y las preferencias serán distintas. Al usar mucho una herramienta, uno se acostumbra al flujo de trabajo con cierto modelo, así que otro modelo puede sentirse extraño.
No parece que haya una razón para aferrarse a un modelo en particular~
¿No depende de a qué dominio se aplique?
En trabajos como
rhwp, que estoy llevando ahora, donde hay que detectar y corregir diferencias de renderizado de 1 mm, si usas Codex se arruina. Hasta ahora, para tareas de alta dificultad Claude Code sigue estando por delante, pero yo siento que para el desarrollo de apps web, donde basta con contar con un workflow y un framework que permitan resolver las cosas solo hasta cierto nivel siguiendo un procedimiento, usar Codex es mejor para la salud mental.Lo estoy usando muy bien
¡En Mac también carga más rápido que el visor y está buenísimo!
Muchísimas gracias.
Oh, oh, lo estoy usando muy bien. Gracias por este excelente proyecto.
Usaré bien
rhwp.Estoy de acuerdo en que Codex es minucioso. Recomiendo programar con Claude y usar Codex para la revisión. Toma bastante tiempo, pero si lo dejas corriendo antes de ir al baño o antes de una reunión, la tasa de finalización también resulta alta.
Yo también lo hago así. Un poco más en detalle, lo tengo configurado con Claude de 100 dólares y Codex de 200 dólares, y armé una skill para que Claude Code Opus haga la planificación -> Sonnet la implemente -> Codex la revise -> Opus valide la revisión -> Sonnet vuelva a implementar -> Codex la revise otra vez (y así sucesivamente), y estoy satisfecho con el resultado.
Yo también lo uso así. Solo que, en vez de fijar cada rol a un modelo, primero se lo asigno al modelo que tenga la cuota más holgada pero que siga siendo potente.
Yo usé ambos y pensé exactamente lo contrario, pero parece que no.
Cuando yo los usaba, Codex ignoraba las instrucciones con bastante frecuencia.
También puede ser que haya cambiado porque Anthropic bajó el rendimiento de Opus 4.6 recientemente.
¿No es al revés? El senior se queda más corto de lo esperado
Parece que no has experimentado este
problema crónico de Claude Code. En Reddit también siempre se arma revuelo por eso.En mi caso,
codexfue una mejor experiencia.