··
Tres asistentes de código con IA, tres modelos mentales distintos. Agente que vive en el terminal, editor con autocompletado que parece magia y agente remoto al que delegas. Cuándo tiro de cada uno y por qué usarlos en paralelo me ha cambiado el flujo.

Llevo meses pasando el mismo día entre tres asistentes de código distintos. Claude Code corriendo en una pestaña del terminal, Cursor abierto en otra ventana editando lo que ese terminal escribe, y Codex lanzado en la nube para tareas que no quiero mirar en tiempo real. Los tres son asistentes de código con IA y los tres los categorizan igual en las comparativas de internet, pero en la práctica hacen cosas distintas. Este post va de eso, de cuándo tiro de cada uno, por qué y qué me ha dejado usarlos en paralelo en lugar de elegir uno.
No voy a poner una tabla de features. Esas caducan en dos semanas. Voy a contar el modelo mental con el que encaja cada herramienta y en qué tipo de trabajo brilla o estorba.
La trampa de las comparativas es tratar a los tres como si fueran la misma categoría. No lo son. Cada uno parte de una idea distinta de dónde debería vivir el asistente.
Claude Code vive en la terminal. Es un proceso que abres con un comando, se engancha a tu directorio de trabajo y desde ahí puede leer ficheros, ejecutar comandos, escribir código, lanzar tests y pedir permiso cuando algo es peligroso. No tiene IDE. Si tocas un fichero en tu editor favorito, Claude Code lo ve. Si él toca uno, tu editor se entera. La herramienta no compite con tu editor, se superpone.
Cursor es un fork de VS Code con el asistente cosido al editor. La frontera entre "escribir código" y "pedirle código al modelo" se disuelve. Tab sugiere siguiente línea. Cmd+K reescribe la selección. El Composer (o el modo agente) trabaja sobre varios ficheros con una vista diff en la que aceptas o descartas cambios. Todo pasa por la ventana del editor y el modelo vive dentro de ese bucle.
Codex en su versión 2026 es un agente remoto. Le mandas una tarea, corre en una VM en la nube de OpenAI con tu repo clonado, hace lo que puede hacer sin ti y te devuelve un PR, un diff o un informe. No está en tu terminal ni en tu editor, está en una pestaña del navegador. Puedes lanzar varias tareas en paralelo y volver a mirar cuando hayan terminado.
Son tres posturas distintas sobre el mismo problema. Asistente encima del sistema operativo, asistente dentro del editor, asistente fuera de tu máquina. Usarlos bien empieza por entender qué trabajo encaja en cada postura.
Claude Code es el que más uso para trabajo pesado. Lo que me ata a él son cuatro cosas que las otras dos no cubren del todo.
La primera es la sesión larga con contexto persistente. Puedo empezar una tarea por la mañana, ir acumulando decisiones y acabar por la tarde con el modelo aún entendiendo qué estamos haciendo y por qué. Claude Code guarda memoria por proyecto en ficheros que tú controlas, con entradas tipadas (perfil del usuario, feedback, contexto de proyecto, referencias a sistemas externos). Cuando vuelvo al día siguiente, el asistente ya sabe que prefiero commits pequeños, que este repo usa pnpm y no npm o que hay un incidente en producción que condiciona las decisiones. Eso en Cursor lo reconstruyes cada sesión, y en Codex no existe como concepto persistente.
La segunda son los subagentes en paralelo. Si necesito explorar una rama del repo mientras escribo código en otra, puedo delegar la exploración a un subagente con un contexto distinto y que me devuelva un informe cuando termine. La ventana principal no se contamina con los 500 resultados de la búsqueda. Para proyectos grandes esto se nota mucho. Cursor tiene modos agénticos pero el contexto compartido es el mismo.
La tercera son los hooks y los skills. Puedo enganchar comandos al ciclo del agente (antes de editar, después de un commit, al terminar una sesión) y puedo empaquetar habilidades reutilizables, desde "revisa este PR" hasta "haz un análisis de seguridad del diff actual". Esto convierte Claude Code en algo parecido a una plataforma, no en un chat con modelo.
La cuarta es el contexto largo. Cuando toca leer un árbol de ficheros grande, migrar un módulo completo o razonar sobre un sistema con diez servicios, la ventana amplia pesa. No para meter todo el código a ciegas, que nunca es buena idea, pero sí para mantener la traza de la conversación y los ficheros relevantes sin que el agente se olvide al tercer tool call.
Donde pincha Claude Code es en la edición fina. Si lo que quiero es tocar dos líneas de una función y seguir, abrir el terminal, escribir el prompt, esperar el diff y aprobar es más ceremonia de la necesaria. Para eso Cursor gana sin discusión.
Cursor lo uso cuando estoy en el flow, en una función concreta, iterando sobre código que ya entiendo. Hay tres piezas de Cursor que en 2026 siguen sin tener rival cercano.
La primera es Cursor Tab, el autocompletado. No es el autocompletado tradicional de "te adivino la siguiente palabra". Cursor Tab mira varios ficheros relacionados, predice un bloque completo, sugiere el siguiente salto de cursor y cuando pulsas Tab te lleva a la siguiente posición relevante en otro sitio. En la práctica es como tener un copiloto que entiende qué estás haciendo a tres líneas vista. Para trabajo de edición sostenido es la función que más tiempo me ha ahorrado, con diferencia.
La segunda es Cmd+K, la reescritura inline. Seleccionas, escribes una instrucción corta (extrae esto a una función, hazlo async, cambia el formato de error) y te devuelve el diff en sitio. Sin salir del fichero, sin diálogo largo. Es la herramienta perfecta para la carpintería del día a día.
La tercera es el modo agente dentro del editor, que para refactors multi-fichero pequeños es muy cómodo. Ves cada cambio en diff, apruebas o rechazas por fichero, todo sin salir del editor. Para tareas de hasta un puñado de ficheros es muy eficiente.
Donde Cursor sufre es cuando la tarea excede el editor. Si la operación requiere ejecutar comandos, parsear su salida, reaccionar a logs, orquestar commits en varias tandas, el bucle "editor + chat + aprobar diff" se queda corto. Ahí Claude Code es claramente mejor. Y si la tarea es larga y puedo delegarla y volver después, Codex gana.
Un punto que hay que contar es el coste. Cursor tiene plan mensual plano con cupos de requests sobre modelos premium. Para quien usa la herramienta todos los días compensa porque el precio es predecible, pero si encadenas tareas muy pesadas con modelos tope, el cupo se agota antes de fin de mes. En mi caso acabé pagando el plan medio y reservando los modelos caros para las tareas que de verdad los pedían.
Codex, en su encarnación de agente cloud, es el que peor encajaba en mi flujo hasta que cambié de mentalidad. No es un asistente conversacional al que le dejas tiempo para pensar, es un compañero al que le encargas una tarea concreta y te desconectas.
Funciona bien cuando la tarea es claramente delimitada y verificable desde fuera. Añadir una nueva ruta a una API siguiendo un patrón existente. Migrar todos los imports de una librería deprecada. Escribir tests unitarios para un módulo que ya tiene tipos. Reescribir un README con una estructura nueva. Son tareas en las que puedes describir el qué sin meterte en el cómo, y en las que el resultado es un PR que revisas como revisarías el de un compañero.
Lo que me sedujo de Codex no fue la calidad del modelo, que en tareas largas todavía comete errores que un humano con menos tiempo detectaría. Fue el cambio de modo. Poder lanzar cinco tareas antes de comer y volver con cinco PRs candidatos abre una forma de trabajar distinta. En vez de yo programo, el modelo me asiste, es el modelo prepara el terreno, yo reviso y decido.
Ahora, las pegas son reales. Lo primero, que el agente corre en una VM con acceso a tu repo y a tus secretos, así que los permisos que le das importan más que en las otras dos. Lo segundo, que cuando la tarea sale mal suele fallar por razones que el modelo no podía adivinar (un test que depende de una fixture viva, un flag de entorno que no estaba documentado, un detalle operativo del repo), y sin feedback loop interactivo pierde más tiempo del que ahorra. Lo tercero, que la facturación depende del ecosistema (plan ChatGPT, Team, Pro) y cambiar de plan por una subida de uso puntual no siempre compensa.
Mi regla de pulgar es que Codex gana cuando la tarea es aburrida, repetitiva y verificable. Si requiere juicio, diálogo o reaccionar a lo que aparece, no.
La conclusión que más me sorprendió al probar los tres no fue "este es mejor". Fue que cada uno cubre una fase distinta de una misma sesión de trabajo.
Una mañana típica empieza con Claude Code en el terminal. Planteo la tarea grande en un plan, discutimos el alcance, el modelo propone pasos, yo afino, y arrancamos. Esta fase es la que más se beneficia de una conversación larga, memoria persistente y capacidad de orquestar comandos. Cuando aterrizo en un fichero concreto y empiezo a iterar fino (renombrar, extraer, ajustar tipos, añadir un handler), paso a Cursor. Claude Code queda en la terminal observando los cambios, pero el trabajo mano a mano es más rápido dentro del editor. Y cuando detecto una tarea aburrida y delegable (añade tests unitarios para estos cuatro módulos siguiendo el patrón del módulo X), la mando a Codex y vuelvo al terminal con Claude Code para otra cosa.
No es que use tres herramientas por capricho, es que cada una cuesta menos cognitivamente para el tipo de trabajo que me toca en ese momento. Forzar una sola empeora las otras dos fases.
La pregunta realista no es "¿cuál es mejor?" sino "si tuvieras que quedarte con uno, ¿cuál?". Depende del perfil.
Si tu trabajo es sobre todo edición de código en proyectos medianos y no tocas mucho operaciones, Cursor. Cursor Tab y Cmd+K ahorran horas a la semana y la curva de aprendizaje es prácticamente cero si vienes de VS Code.
Si tu trabajo es construir y operar sistemas, QA, DevOps, arquitectura o research sobre código que no conoces de entrada, Claude Code. El poder vivir en el terminal, orquestar comandos, mantener memoria por proyecto y delegar a subagentes cubre mucho más trabajo real que lo que entra dentro de un editor.
Si tu trabajo es coordinar tareas delegables sobre un repo estable, tipo lead que revisa mucho código y menos que lo escribe, o si quieres exprimir horas dormidas, Codex gana terreno. Pero rara vez compensa como herramienta única, casi siempre complementa a una de las otras dos.
En mi caso, si me obligaran a quedarme con una, elegiría Claude Code. No por el modelo (Cursor puede usar los mismos modelos top), sino porque el trabajo que hago pasa por comandos, tests, logs, deploys y memoria entre sesiones. Ese bucle fuera del editor es donde más gano, y es justo donde Cursor y Codex no llegan.
Si tienes que elegir uno hoy, mira cuatro cosas y en este orden.
Dónde vive tu trabajo. Si pasas el 80% del tiempo dentro de un editor concreto, Cursor. Si pasas ese 80% entre terminal, scripts y comandos, Claude Code. Si trabajas a base de PRs revisados y quieres delegar, Codex.
Cuánto contexto cruzado necesitas. Para proyectos grandes y sesiones largas, Claude Code está pensado para eso. Para tareas de edición local, Cursor va sobrado. Para tareas encapsuladas, Codex no necesita contexto cruzado.
Cómo te cobran. Cursor es plan mensual predecible con cupos. Claude Code va por uso de API, más caro si haces sesiones intensas pero sin topes incómodos. Codex depende del plan ChatGPT que tengas y encaja en la cuenta que ya usas para chat.
Cuánta autonomía quieres dar al modelo. Codex es el más autónomo, corre solo en una VM remota. Claude Code requiere aprobación de acciones potencialmente peligrosas por defecto. Cursor te deja aceptar o rechazar cada diff. Si te incomoda que un agente ejecute comandos sin mirar, Cursor es la más conservadora.
Tres cosas me llevo de meses con los tres abiertos a la vez.
La primera es que la categoría asistente de código ya no es una sola categoría. Son al menos tres posturas distintas y elegir la adecuada pesa más que elegir el modelo. Un Cursor con Sonnet rinde más que un Claude Code con el mismo modelo si la tarea es edición fina. Y un Codex con GPT genérico rinde más que cualquier asistente local si la tarea es paralelizable.
La segunda es que la memoria persistente está infravalorada. Volver cada mañana a un agente que sabe quién soy, cómo escribo, qué decisiones tomé ayer y qué errores no quiero repetir es la diferencia entre ahorrar minutos y ahorrar horas. Ninguna de las otras dos herramientas en su forma actual ofrece esto con la misma naturalidad que Claude Code.
La tercera es que delegar requiere disciplina. Codex es potente, pero encargar algo mal especificado y volver dos horas después a un PR enrevesado es peor que hacerlo tú mismo. El superpoder de delegar solo aparece cuando defines la tarea con claridad, y eso es una habilidad que no viene con la herramienta.
No hay una sola respuesta. La pregunta que más me ha servido en este año no es cuál uso, sino para qué tipo de trabajo uso cuál. Esa es la comparativa real, y las features cambian, los planes suben, pero el encaje entre herramienta y tarea se mantiene.

Jose, autor del blog
QA Engineer. Escribo en voz alta sobre automatización, IA y arquitectura de software. Si algo te ha servido, escríbeme y cuéntamelo.
¿Qué te ha parecido? ¿Qué añadirías? Cada comentario afina la siguiente entrada.
Si esto te ha gustado

Quinielas, cámaras de seguridad, monitorización del NAS, control de precios y gestión de facturas: casos de uso personales reales con OpenClaw como asistente autónomo en el día a día.

OpenClaw no solo sirve para verificar integridad: regresión visual, monitorización de endpoints, análisis de logs, smoke tests post-deploy y auditoría de seguridad continua. Casos de uso reales para testing y QA.

Los tests E2E se rompen con cada cambio de interfaz. En JMO Labs construimos un pipeline de 5 fases con IA que planifica, ejecuta, repara selectores, diagnostica fallos y verifica resultados de forma autónoma. La caché de selectores hace que cada ejecución sea más rápida que la anterior.