Elegir entre Code y empieza antes de escribir el primer prompt. ¿Necesitas corregir un fallo que ya sabes reproducir, desarrollar una función o revisar una interfaz? El nombre del producto importa menos que poder comprobar que el encargo ha quedado bien. Una respuesta convincente no demuestra que el código funcione.
Esta guía compara flujos documentados y propone una prueba que puedes repetir. No publicamos una clasificación de velocidad ni de calidad: no hemos ejecutado aquí el mismo proyecto con ambas herramientas. El uso de en nuestro proceso editorial tampoco permite deducir cómo habría rendido Code.
Qué comparten y dónde mirar las diferencias
Claude Code y Codex CLI pueden trabajar con archivos de un proyecto y ejecutar herramientas de desarrollo. Por eso, reducir la comparación a un chat que contesta mejor deja fuera buena parte del trabajo.
Conviene comparar el entorno que usarías de verdad. ¿Quieres revisar cambios en el editor, trabajar desde la terminal o encargar una tarea remota? Comprueba los permisos, las herramientas disponibles y cómo recuperas el resultado. Una capacidad anunciada para una interfaz no implica que esté disponible en todas las demás ni en tu cuenta.
También separa producto y modelo. Si cambias la herramienta, el modelo y los permisos a la vez, estarás comparando dos configuraciones completas. Es una prueba válida para decidir qué usar, pero no permite atribuir cada diferencia a una sola causa.
Primer encargo: corregir un error reproducible
Prepara una copia del proyecto sin credenciales y elige un fallo pequeño. Por ejemplo, un filtro que no respeta el intervalo de fechas. Escribe los pasos para reproducirlo y conserva un caso que falle antes de pedir la corrección.
Da a cada herramienta el mismo punto de partida. Pide que explique la causa, aplique el cambio y ejecute la comprobación. Después revisa tú el diff: ¿ha corregido la lógica o ha debilitado el test? ¿Ha tocado archivos ajenos? Guarda los comandos y sus resultados, incluidos los fallidos.
El criterio de aceptación debe existir antes de ver las respuestas. Así evitas premiar una explicación elegante que no resuelve el problema original.
Segundo encargo: añadir una función acotada
Una exportación CSV permite comprobar más cosas que la aparición de un botón. Define qué columnas contiene, cómo trata las comas y los saltos de línea, y qué ocurre si no hay filas. Incluye ejemplos de entrada y salida esperada.
Cuenta las intervenciones que necesitas hacer después del primer intento. Una herramienta puede producir más código y dejarte más trabajo de revisión. Otra puede preguntar algo relevante antes de empezar. Registrar esas diferencias es más útil que contar líneas generadas.
Mantén separado el tiempo de ejecución del tiempo que tú dedicas a explicar, corregir y comprobar. No conviertas una prueba pequeña en un juicio universal sobre todos los proyectos.
Tercer encargo: revisar una interfaz
Pide una mejora observable: que un formulario pueda usarse en una pantalla estrecha y con teclado. Conserva una captura inicial y describe la secuencia que debe funcionar, incluido el mensaje de error y la confirmación de envío.
Después abre la aplicación. Un compilador no detecta que el botón queda fuera de la pantalla o que un mensaje tapa el campo. Tampoco una captura demuestra que el formulario guarda datos. La revisión visual y la prueba funcional responden a preguntas distintas.
Qué anotar para tomar la decisión
Guarda por tarea la versión de la herramienta, el modelo, los permisos, la fecha, el resultado de aceptación, las correcciones humanas y el coste que puedas observar. Si una suscripción no muestra importe por tarea, anota «desconocido». Dividir la cuota entre un número inventado de tareas no crea una medición.
Prueba primero la opción que encaje en tu entorno habitual y en el acceso que ya tengas. Si termina los encargos con una revisión asumible, ya tienes una base para decidir. Cambiar de herramienta tiene sentido cuando puedes nombrar la fricción que quieres resolver.
Para mejorar la consistencia entre encargos, consulta nuestra introducción a las skills. Si necesitas convertir una tarea de tu proyecto en una prueba verificable, puedes contarnos el caso.
