La gente sigue preguntando cuál elegir, PaellaDoc o Cursor, y la pregunta parte de una suposición equivocada. No son el mismo tipo de herramienta. Cursor es el editor donde te sientas a escribir código con la IA al lado. PaellaDoc es la capa que va encima del editor: corre agentes sobre tareas, comprueba si su output es correcto de verdad, convierte el trabajo en artefactos de producto y te mantiene todos los repos en un solo sitio. Puedes usar los dos a la vez. De hecho puedes abrir en Cursor el trabajo que produjo un agente y seguir editándolo ahí.
Qué hace Cursor
Cursor es un editor de código nativo de IA, un fork de VS Code, y muy bueno. Escribes y editas código dentro con la IA metida en el bucle todo el rato: ediciones inline donde seleccionas código y le dices qué cambiar, un panel de chat que conoce tu fichero, tab completion que adivina la siguiente edición y un modo agente que hace cambios multi-fichero por ti. El bucle interno, la sensación minuto a minuto de escribir código con un modelo ayudando, es de lo que va Cursor y lo hace excelente. La adopción es enorme y el pulido se nota. Si tu día se pasa dentro de un fichero, con las manos en el código, Cursor es uno de los mejores sitios donde estar.
PaellaDoc no intenta ser eso. No estamos construyendo un editor y no deberías dejar Cursor para usarnos.
Qué hace PaellaDoc
PaellaDoc corre agentes de codificación por ti. Le das una tarea, levanta un agente (Claude Code, Codex, Kimi, cualquier agente CLI) en un worktree de git aislado en tu máquina, agnóstico al modelo, con tu propia suscripción. Mientras Cursor es donde una persona edita código, PaellaDoc es donde los agentes hacen tandas de trabajo y tú decides qué cuenta como terminado.
La pieza que más importa es el gate. Antes de que el agente arranque, escribes los criterios de aceptación. Cuando el agente dice que ha terminado, PaellaDoc no se lo cree. Corre el código contra esos criterios sobre el diff real. Un build que compila en verde no es “hecho”. La feature tiene que hacer de verdad lo que dijiste que tenía que hacer, o el gate se queda en rojo. Ese es el sentido de todo esto.
Alrededor de eso, PaellaDoc te da un sala de control para todos tus repos (en la era de la IA tienes cien en la máquina, dispersos, y nadie los abre), un modo no-coder que construye un producto a partir de una descripción en lenguaje llano para alguien que no sabe leer un diff, reverse intake que lee un repo existente y reconstruye el contexto de producto, y control por Telegram para que puedas lanzar una tanda o aprobar un paso desde el móvil.
La diferencia clave: editor vs la capa que va encima
Cursor responde a “cómo escribo este código más rápido”. PaellaDoc responde a “¿construyó el agente lo correcto, y ya es producto?”. Son trabajos distintos a distinta altura.
En Cursor eres tú quien se mueve por el fichero. Lees cada cambio, lo aceptas o lo rechazas, tú eres la verificación. Funciona porque estás ahí delante. PaellaDoc existe para el momento en que no estás delante: el agente corrió por su cuenta, en su propio worktree, quizá tres agentes en tres tareas, y algo tiene que decidir si el output es correcto sin que un humano lea cada línea. Ese algo es el gate, y corre tus criterios contra el código real, no un vistazo a ojo.
Así que no es lo uno o lo otro. Cursor es tu editor. PaellaDoc es la capa de orquestación más verificación más producto que va encima. Abre el trabajo en Cursor cuando quieras mancharte las manos. Deja que el gate cace lo que mirar un build en verde nunca caza.
Por qué existe el gate
Corrimos un benchmark público, 210 runs. El output de un agente a pelo pasaba el build pero estaba mal de verdad un 40% de las veces. Y el modelo frontier más fuerte, a máximo esfuerzo, fallaba una tarea difícil en 2 de cada 3 runs, en runs distintos cada vez, así que ni siquiera lo podías predecir. Un build en verde no es una feature correcta, y “los tests están en verde” dice menos de lo que la gente supone cuando el agente también escribió los tests. El gate es nuestra respuesta a ese número. Corre tus criterios, sobre el diff, cada vez, en lugar de fiarse de que compilar signifique funcionar.
Código, o producto
Hay una segunda cosa que Cursor no intenta hacer, y es la parte que más nos importa. El código que escribe un agente es un output. El producto es lo de alrededor: el PRD, las épicas, las historias de usuario, los criterios de aceptación, los porqués. En Cursor ese contexto vive en tu cabeza y en chats dispersos. En PaellaDoc se convierte en artefactos .paella versionados y comparables que viven en tu repo y viajan con él.
Eso lo mueve un SDK abierto y cuatro tipos de pack de la comunidad: method packs (la metodología), stack packs (tu stack técnico), design packs (theming y design tokens) y validator packs (los gates en sí). Eliges los packs y el trabajo sale como producto, no como un diff que cayó por ahí. Haces producto, no solo código.
PaellaDoc no reemplaza tu editor
Que quede claro, porque es todo el encuadre: PaellaDoc no reemplaza Cursor ni lo pretende. Va por encima. El montaje natural es Cursor como el sitio donde escribes y editas, y PaellaDoc como la capa que corre agentes, verifica su output y te mantiene el producto y los repos ordenados. Cuando quieras llevarte el trabajo de un agente a un fichero a mano, ábrelo en Cursor. Estamos encantados de ser el suelo bajo tu editor, no un cambio por él.
Qué compartimos
Los dos corren IA sobre código real en tu máquina. Los dos tienen un modo agente que hace cambios multi-fichero. Los dos son flexibles con el modelo hasta cierto punto. Y lo decimos sin rodeos: Cursor es mucho más maduro, está mucho mejor financiado, infinitamente más pulido y lo usa muchísima más gente. La experiencia de edición nos saca años de ventaja a nivel de fichero, porque nosotros ese nivel no lo tocamos. PaellaDoc es temprano y lo hace una sola persona. Donde Cursor va por delante, va por delante de sobra.
| Capacidad | Cursor | PaellaDoc |
|---|---|---|
| Edición inline con IA en un fichero | Sí | No, ábrelo en Cursor |
| Tab completion / bucle interno | Sí | No |
| Modo agente (cambios multi-fichero) | Sí | Sí |
| Corre agentes en worktrees de git aislados | No | Sí |
| Gate de ejecución: output corrido vs criterios que escribiste antes | No | Sí |
| Artefactos de producto versionados (.paella: PRD, historias, criterios) | No | Sí |
| SDK abierto + packs de comunidad (method/stack/design/validator) | No | Sí |
| Reverse intake de un repo existente | Parcial (contexto) | Sí (contexto de producto) |
| Sala de control multi-repo | No | Sí |
| Modo no-coder (producto a partir de una descripción) | No | Sí |
| Control remoto por Telegram | No | Sí |
| Madurez, pulido, financiación, adopción | Por delante | Temprano, solo founder |
Para quién es cada uno
Usa Cursor si tu día es con las manos en el código y quieres la mejor experiencia minuto a minuto escribiendo y editando con IA. Ese es el trabajo para el que está hecho y lo hace mejor que casi nada. Si lo único que necesitas es un editor estupendo con un modelo dentro, no nos necesitas.
Tira de PaellaDoc cuando la pregunta deja de ser “escribe esto más rápido” y pasa a ser “corre agentes sobre tareas, demuestra que el output es correcto antes de que haga ship, y convierte el trabajo en producto que pueda versionar y reutilizar”. Cuando tienes cien repos y ni idea de qué hay dentro, cuando quieres un gate que corra tus criterios en vez de fiarse de un build en verde, cuando alguien que no sabe leer un diff necesita sacar un producto, ese es nuestro trabajo. Y mantienes Cursor abierto todo el tiempo.
PaellaDoc no es un Cursor mejor. Es otra capa haciendo otro trabajo, y el montaje más limpio usa los dos. Cursor es donde escribes el código. PaellaDoc decide si era el código correcto y lo convierte en producto. Mira el resto de comparaciones si quieres el cuadro completo.