Cursor vs Claude Code: subagents, skills y cuál usar en 2026

TL;DR: Cursor ya trae subagents y skills, las dos primitivas que hicieron grande a Claude Code. Pero copiarlas no iguala el resultado: cada herramienta gana en un terreno distinto.

Cursor brilla en desarrollo dentro de un repo con contexto visual y agentes en paralelo (hasta 8 en background sobre git worktrees).
Claude Code manda en terminal, multi-repo, CI/CD y automatización headless.
Las skills usan el mismo formato SKILL.md, pero la portabilidad real entre Cursor y Claude Code aún no es perfecta.

El problema: dos agentes que ahora se parecen demasiado

Hasta hace poco la decisión Cursor vs Claude Code era sencilla: Cursor era el editor con IA, Claude Code el agente de terminal. Esa frontera se ha borrado. Cursor incorporó subagents y skills, justo las piezas que diferenciaban a Claude Code, y la pregunta cambia: si ambos tienen las mismas primitivas, ¿cuál elijo y para qué?

Esto importa porque construir skills y flujos sobre un agente es una inversión de tiempo. Si eliges mal, parte de ese trabajo no se mueve contigo. La respuesta no es fanboyismo, es entender dónde gana cada uno y qué se queda atrapado al cambiar.

¿Qué es un subagente?

Un subagente es una instancia de agente separada que se ejecuta en su propia ventana de contexto, hace una tarea acotada y devuelve solo un resumen al hilo principal. Esto mantiene limpia la conversación principal y permite paralelizar trabajo.

En Cursor, los subagents corren en contextos aislados y soporta hasta 8 agentes en background simultáneos, cada uno en su propio worktree de Git. Claude Code añade dos cosas encima de la base: un fork experimental que hereda toda la conversación y reutiliza la caché del prompt padre (arranca más barato que un subagente nuevo), y un agente Explore de solo lectura fijado al modelo rápido Haiku.

¿Qué es una skill?

Una skill es una carpeta con un archivo SKILL.md que el agente carga bajo demanda cuando su descripción de una línea encaja con la tarea, sin que tengas que repetir instrucciones. Dejas de reprommptear y empiezas a componer.

La diferencia con meter todo en un CLAUDE.md gigante es clave: la skill solo entra en contexto cuando hace falta. Es el mismo principio de separación de responsabilidades aplicado al contexto del agente: cada pieza con su trabajo, cargada cuando toca.

# SKILL.md: el agente la descubre por la descripcion y la carga sola
---
name: changelog-writer
description: Genera el changelog a partir de los commits desde el ultimo tag
---
Lee los commits con git log, agrupa por tipo (feat, fix, chore)
y redacta entradas en formato Keep a Changelog.

Cursor vs Claude Code: tabla comparativa

Criterio	Cursor	Claude Code
Interfaz	IDE visual (árbol de archivos, pestañas, terminal a la vista)	CLI / terminal, un solo panel
Subagents	Hasta 8 en paralelo, aislados en git worktrees	Subagents + fork experimental, agente Explore en Haiku
Skills	Formato SKILL.md, scope por proyecto	Formato SKILL.md, scope global y por proyecto
Mejor para	Features en un repo, mucho tooling de UI, iteración visual	Multi-repo, CI/CD, scripting, ejecución headless
Coste	Suscripción con requests incluidas (rango ~20€/mes)	Pago por uso o plan de tarifa plana, más caro por tarea equivalente
Portabilidad de skills	Limitada: scope de proyecto, hay que copiarlas en cada repo	Amplia: estándar SKILL.md compatible con varios agentes

Portabilidad: el detalle que decide tu inversión

La buena noticia: el formato SKILL.md está convergiendo. Una skill básica (revisión de código, tests, automatización de Git, documentación) funciona igual en Claude Code, Codex, OpenClaw, Gemini y Cursor copiando la carpeta al directorio correcto de cada agente.

La letra pequeña: las features avanzadas no viajan. El context: fork de Claude Code (ejecutar una skill como subagente con contexto aislado) lo ignoran otros agentes. Cursor usa scope solo-proyecto, así que las skills personales hay que copiarlas en cada repositorio. A junio de 2026, la portabilidad mejora pero no es transparente: escribe tus skills para el agente que más uses y asume conversión manual si migras.

# La misma skill instalada en varios agentes: el formato viaja, las features avanzadas no
cp -r changelog-writer ~/.claude/skills/    # Claude Code (scope global)
cp -r changelog-writer .cursor/skills/      # Cursor (scope por proyecto)
cp -r changelog-writer ~/.codex/skills/     # Codex CLI

¿Cuándo usar cada uno en producción?

La regla práctica que sigo: elige por dónde vive la tarea, no por marketing. Trabajo de feature dentro de un único codebase con mucho contexto visual encaja en Cursor. Tareas que cruzan repos, se integran con pipelines o corren sin GUI van a Claude Code.

En equipos de producto es común usar ambos en tándem: Cursor para el desarrollo activo del día (construir features, iterar con subagents viendo los diffs) y Claude Code para las operaciones de fondo (scripts de despliegue, cambios multi-repo, lotes nocturnos, integración con herramientas de gestión). No es un o esto o lo otro. Si vienes de elegir entre modelos, la lógica es la misma que en comparar Opus y Sonnet según la tarea: la herramienta sigue al trabajo.

En Producción

Coste real por tarea, no por mes. En una prueba publicada con tres cambios de código equivalentes, Claude Code costó alrededor de cuatro veces más que Cursor para el mismo trabajo (unos 7-8€ frente a 2€ aproximadamente). El número exacto da igual; la lección sí importa: con muchas iteraciones diarias, la diferencia se acumula. Vigila tu factura y compacta el historial a menudo, igual que harías para evitar los cache miss que disparan el coste de tokens.

Paralelismo con cabeza. 8 subagents en paralelo suena a velocidad, pero cada uno consume contexto y dinero. Para refactors quirúrgicos o debugging fino, un solo agente con control humano sale mejor que un enjambre que falla en cascada y luego hay que auditar.

Lock-in operativo. Las skills con scope de proyecto de Cursor no son tu librería global. Si construyes 20 skills ahí y migras, las recreas. En Claude Code, una skill global se reutiliza entre proyectos desde el primer día. Más que el modelo, lo que pesa es cómo montas el flujo: la configuración manda sobre la herramienta elegida.

Integraciones. Si tu agente depende de servidores MCP o herramientas externas, define contratos claros antes de paralelizar; un subagente que llama a una integración frágil multiplica el fallo. Aplica lo mismo que en contratos para MCP que no revientan.

Errores comunes y depuración

Error: copias una skill de Claude Code a Cursor y no se activa. Causa: usaba context: fork o rutas globales que Cursor ignora. Solución: elimina las directivas específicas y colócala en .cursor/skills/ del proyecto.
Error: factura disparada tras activar subagents. Causa: varios agentes explorando en paralelo, cada uno quemando contexto. Solución: reserva el paralelismo para tareas realmente independientes (tests, research) y usa un solo agente para debugging.
Error: el subagente devuelve un resumen pobre y pierdes detalle. Causa: tarea mal acotada, el subagente destila demasiado. Solución: dale un objetivo concreto y pídele que devuelva artefactos (diffs, rutas), no prosa.

Preguntas frecuentes

¿Las skills de Claude Code funcionan en Cursor?

Las skills básicas en formato SKILL.md sí, copiando la carpeta a .cursor/skills/. Las que usan features propias de Claude Code, como context: fork, no se traducen y hay que adaptarlas a mano.

¿Cursor reemplaza a Claude Code?

No. Cursor gana en desarrollo dentro de un IDE con contexto visual; Claude Code gana en terminal, multi-repo y automatización headless. Muchos equipos usan los dos a la vez según el tipo de tarea.

¿Cuántos subagents puede correr Cursor en paralelo?

Hasta 8 agentes en background simultáneos, cada uno aislado en su propio git worktree, trabajando de forma autónoma mientras sigues programando.

Conclusión

Hemos visto que Cursor ha cerrado el hueco de features con subagents y skills, pero la decisión sigue siendo de contexto, no de checklist. Cursor encaja en el desarrollo visual dentro de un repo; Claude Code, en terminal, automatización y trabajo multi-repo. La clave está en la portabilidad: el formato SKILL.md viaja, las features avanzadas y el scope no, así que escribe tus skills pensando en el agente que más usas y asume algo de conversión si cambias. Y recuerda que el coste por tarea, no la cuota mensual, es lo que de verdad pesa con uso intensivo.

¿Has montado un flujo con los dos a la vez o has migrado skills entre ellos? Cuéntame qué se rompió en los comentarios o en Twitter @sergiomarquezp_. En el próximo artículo desmonto el hype de los meta-harnesses multi-agente que orquestan enjambres de agentes encima de Claude Code: cuándo aportan y cuándo solo suman coste.