Diré algo con lo que muchos no estarán de acuerdo: para un sitio, elegir entre Claude Code, Codex y Cursor significa menos de lo que parece. Los tres saben leer el proyecto, cambiar archivos y lanzar comandos. Los tres a veces se equivocan. Y el resultado depende sobre todo de dos cosas que no tienen que ver con la elección de la herramienta: lo clara que esté la tarea y lo atenta que sea la persona al revisar los cambios.
Eso no significa que no haya diferencia. La hay, y es sobre todo de dónde vive la herramienta y cómo trabaja usted con ella: en la terminal, en el editor o en la nube. De eso depende a quién le resulta más cómoda y cómo revisar lo que hizo. De eso hablaremos. No habrá un ranking listo: no hice una prueba comparada en una misma tarea, así que en lugar de un ganador explicaré por qué conviene comparar en la propia tarea y con qué criterios.
En qué se parecen y por qué se confunden
Claude Code, Codex y Cursor son agentes de IA para trabajar con código. A diferencia de un chat, donde el código se copia de un lado a otro, el agente trabaja directo con los archivos del proyecto: los lee, propone cambios, hace correcciones y lanza comandos en la terminal.
Se confunden por razones comprensibles. Las tareas son parecidas en los tres: escribir un bloque nuevo, corregir un error, rehacer una página. Las posibilidades se cruzan: Claude Code y Codex tienen extensiones para editores, y Cursor tiene un agente que lanza comandos. Y los tres cambian rápido, así que una descripción de hace medio año puede ya no corresponder a la realidad.
Un rasgo común importante: cada herramienta lee un archivo de instrucciones del proyecto. Claude Code, al inicio de cada sesión, lee CLAUDE.md, Codex antes de trabajar lee AGENTS.md, Cursor admite sus reglas de proyecto en la carpeta .cursor/rules y también entiende AGENTS.md. En ese archivo se anota cómo está hecho el proyecto, qué comandos lanzar y qué no se puede tocar. Es una de las cosas más útiles al trabajar con cualquier agente.
Dónde vive cada herramienta
Claude Code
Claude Code, de Anthropic, es en origen una herramienta para la terminal. Ahora, según la documentación, funciona en la terminal, en editores (VS Code y JetBrains), en una aplicación aparte para el ordenador y en la web. Sabe trabajar con git: hacer commits, crear ramas, preparar solicitudes de fusión.
Para la mayoría de las formas de trabajo hace falta una suscripción de Claude o una cuenta de Anthropic Console.
A quién le conviene: a quien está acostumbrado a la terminal o dispuesto a acostumbrarse, y a quien quiere que el agente lleve el trabajo con git y la persona revise el resultado.
Codex
Codex, de OpenAI, existe en varias formas. Codex CLI funciona en la terminal: el comando /init crea el archivo AGENTS.md del proyecto, y /permissions configura qué puede hacer el agente sin confirmación. La extensión para editores permite ver las correcciones en el código y deshacerlas. Codex Cloud ejecuta tareas en la nube con repositorios en GitHub o GitLab: usted pone la tarea y recibe el resultado mientras se ocupa de otra cosa.
El grado de autonomía del agente es una decisión aparte. Cuanto más hace sin confirmación, más rápido va el trabajo, pero con más atención hay que mirar el resultado. Por eso la libertad del agente se amplía poco a poco, a medida que se entiende cómo trabaja con un proyecto concreto.
Codex está disponible en los planes de ChatGPT (Plus, Pro, Business y otros).
A quién le conviene: a quien ya usa ChatGPT y a quien necesita poder dejar una tarea en la nube y volver al resultado más tarde.
Cursor
Cursor es un editor de código con IA integrada. El agente del panel lateral puede corregir código y lanzar comandos en la terminal. Antes de cambios importantes Cursor hace puntos de control: copias de los archivos a las que se puede volver. Las reglas del proyecto se guardan en la carpeta .cursor/rules, y también se admite AGENTS.md.
A quién le conviene: a quien quiere ver el código y las correcciones del agente en la ventana habitual del editor y tener a mano una vuelta atrás simple.
| Rasgo | Claude Code | Codex | Cursor |
|---|---|---|---|
| Lugar principal de trabajo | Terminal | Terminal, editor, nube | Editor de código |
| Otras variantes | Editores, aplicación, web | Extensión para editores | Agente en el editor con terminal |
| Archivo de instrucciones | CLAUDE.md | AGENTS.md | .cursor/rules, AGENTS.md |
| Trabajo con git | Commits, ramas, solicitudes de fusión | Tareas en la nube con repositorios | Por el editor y la terminal |
| Volver atrás las correcciones | Por git | Deshacer en el editor, git | Puntos de control, git |
| Acceso | Suscripción de Claude o Console | Planes de ChatGPT | Cuenta de Cursor |
Por qué un ranking no sustituye la prueba en la propia tarea
Los resúmenes y los rankings sirven para conocer las posibilidades. Pero para elegir funciona mejor una comparación en una tarea típica del proyecto concreto: ni la más simple ni la más difícil, clara y comprobable. Las condiciones deben ser las mismas: la misma copia del proyecto, la misma formulación de la tarea, el mismo archivo de instrucciones. Si no, no se comparan las herramientas, sino a quién se le explicó con más detalle.
El resultado también hay que valorarlo con los mismos criterios: si la tarea quedó resuelta del todo, si todos los cambios vienen al caso, si se rompió lo que funcionaba, cuántas aclaraciones hicieron falta, lo fácil que es revisar las correcciones. Aquí pasa el límite: para comparar las herramientas con honestidad hay que saber leer los cambios en el código y entender por qué una solución es más fiable que otra. Sin esa habilidad la comparación se convierte en una elección por sensación. La comodidad también importa: una herramienta que escribe el código un poco mejor, pero trabaja en un entorno donde es incómodo revisar las correcciones, en la práctica puede dar un resultado peor.
Cómo cambia los archivos la herramienta y cómo comprobarlo
Cualquier agente tarde o temprano hará algo que no es lo que hace falta: corregirá un archivo de más, borrará una línea necesaria, resolverá la tarea de otra forma. Por eso importa menos lo a menudo que se equivoca y más lo rápido que usted lo note y lo revierta.
Un diff es la lista de cambios: qué líneas se borraron y cuáles se añadieron. Las tres herramientas muestran los cambios, pero de forma distinta: Cursor y las extensiones de editor, en la propia ventana del editor; las versiones de terminal, en la terminal o por git. El diff hay que mirarlo siempre, aunque la tarea parezca simple.
Commits. Si el proyecto está en git, cada tarea terminada debe ser un commit aparte. Así cualquiera se puede deshacer sin tocar las demás. Claude Code sabe hacer commits solo, pero el contenido igual lo revisa una persona.
Volver atrás. En Cursor hay puntos de control, en la extensión de Codex se deshacen las correcciones en el editor, y en los tres está git. Por eso, antes de cada tarea, el estado actual del proyecto debe estar guardado.
Si el agente se fue por otro lado, una serie de aclaraciones encima de correcciones fallidas suele enredarlo más. Es más fiable volver al estado guardado y reformular la tarea teniendo en cuenta lo que salió mal. Cada corrección nueva encima de un error agranda el diff que después habrá que revisar.
La prueba en el navegador. Para un sitio, el diff es la mitad de la revisión. La otra mitad es abrir la página, mirarla en el ordenador y en el teléfono, y probar los formularios y los elementos interactivos. El agente puede escribir un código que se ve correcto en el diff y rompe la maquetación en una pantalla estrecha.
Qué le conviene a quien empieza y qué a quien lleva el proyecto
A quien empieza y antes no trabajó con código suele resultarle más simple empezar por el editor: se ven los archivos, se ven las correcciones, hay botones para deshacer. La terminal al principio asusta, aunque no tiene nada complicado. Pero con honestidad: si usted no entiende nada de código, ninguna de las tres herramientas le quita la necesidad de entender qué pasa en el proyecto. El agente escribe el código, pero decidir si es correcto le tocará a usted.
Conocer cualquiera de las herramientas conviene en tareas pequeñas, donde el resultado se comprueba fácil. Pero incluso en ellas hay que entender qué cambió el agente y por qué, si no el error aparecerá más tarde y en otro sitio.
A quien lleva el proyecto y entiende cómo está hecho le importa otra cosa: lo bien que la herramienta trabaja con un proyecto grande, cómo sigue las reglas del archivo de instrucciones, si se le puede dejar una tarea y volver más tarde. Aquí conviene mirar las variantes de terminal y de nube, que permiten trabajar en paralelo en varias tareas.
Si el proyecto lo llevan varias personas, importa un solo lugar para las reglas. El archivo AGENTS.md lo admiten Codex y Cursor, así que las reglas comunes conviene tenerlas ahí, y para Claude Code duplicarlas o remitir a ellas desde CLAUDE.md.
Qué revisa la persona
Sea cual sea la herramienta, la persona responde de:
- plantear la tarea: qué hay que hacer exactamente y qué no se puede tocar;
- revisar los cambios: el diff, la página en el navegador, la versión móvil;
- la seguridad: el agente no debe recibir acceso a contraseñas, claves y datos de clientes sin necesidad;
- las decisiones de arquitectura: cómo está hecho el proyecto y qué cambia en él;
- la publicación: qué sale al sitio en funcionamiento y cuándo.
El agente puede proponer una solución en cada punto, pero la responsabilidad del resultado se queda en la persona.
Aparte conviene vigilar las dependencias nuevas. El agente propone fácil conectar una biblioteca más para resolver la tarea antes. Cada biblioteca así es código que hay que actualizar y que puede dejar de mantenerse. En un sitio pequeño a menudo es más simple resolver la tarea sin ella, y eso conviene escribirlo directo en las instrucciones del proyecto.
Qué dejo en el proyecto antes de trabajar con cualquiera de los tres
La preparación ahorra más tiempo que la elección de la herramienta. Antes de la primera tarea aparece en el proyecto un archivo de instrucciones: cómo está hecho, qué comandos lanzan el armado y la revisión, qué no se puede tocar. Las tareas se cortan en partes pequeñas, cada una con una forma clara de comprobarla y un commit aparte. Los límites se escriben de forma explícita, y el plan de cambios se habla antes de las correcciones: un error en el plan es más simple de corregir que uno en el código.
Aparte, la seguridad. Las contraseñas y las claves se guardan en los ajustes del entorno y nunca entran en el texto de la tarea. Y el resultado de cada tarea se comprueba en el navegador enseguida, no al final del día: cuanto antes se encuentra el error, más simple es ver qué corrección lo causó. Todo esto no va de una herramienta concreta, sino de cómo llevar un proyecto en el que parte del código lo escribe la IA.
Si el proyecto es más complejo de lo que se puede llevar con calma con un agente por cuenta propia, se puede pasar al desarrollo a medida. Y si la tarea es una aplicación dentro de Telegram, mire el desarrollo de una Telegram Mini App. El proyecto se puede hablar por el cuestionario de mara-craft.com: miraré la tarea y diré por dónde empezar.