Cursor v2: La IA que devoró VS Code

La codificación con IA acaba de detonar una nueva carrera armamentista. Cursor v2, un fork de VS Code que apareció hace solo seis meses, ahora incluye un modelo de frontera de clase propio, un enjambre multiagente y un navegador integrado directamente en el editor. En una industria que todavía trata a Copilot como un autocompletado de lujo, Cursor está decididamente apuntando a toda la pila de IDE.

El momento de Cursor hace que el movimiento se sienta menos como un lanzamiento de función y no como una entidad propia, sino más bien como un movimiento estratégico. Informes de una valoración de aproximadamente $10 mil millones ahora acompañan el lanzamiento de la versión 2 que llegó el 29 de octubre, apenas medio año después del fork de VS Code. Ese ritmo señala una empresa que no quiere ser un complemento en el ecosistema de Microsoft; quiere ser el ecosistema.

En el centro se encuentra Composer, el modelo de codificación interno de Cursor, que se ha evaluado como aproximadamente 4 veces más rápido que los sistemas rivales en tareas similares. En una entidad no adecuada, Composer termina un trabajo de codificación complejo en unos 28 segundos, mientras que a Claude le puede llevar más de 2 minutos. Cursor no presenta esto como un ahorro marginal de latencia, sino como la capa que permite ejecutar docenas de agentes por desarrollador sin inflar la factura.

La velocidad es solo la mitad de la provocación. Cursor v2 transforma el paradigma de un solo asistente en un enjambre de ocho agentes, cada uno trabajando en árboles de trabajo aislados para que nunca choquen en los commits. Ya no estás empujando un solo chatbot; estás delegando a un pequeño equipo de IA que puede refactorizar, escribir pruebas y prototipar características en paralelo.

La pregunta que pesa sobre cada demostración es directa: ¿hace que los flujos de trabajo de codificación tradicionales se sientan obsoletos? Si un sistema de múltiples agentes puede explorar múltiples implementaciones, ejecutar pruebas en una ventana de Chrome integrada y mostrar diferencias limpias más rápido de lo que un humano puede configurar el entorno, el papel del IDE cambia de editor a centro de comando. VS Code empieza a parecerse a una cabina muy pulida para un solo piloto en un mundo que se desplaza hacia escuadrones autónomos.

Lo que realmente desafía Cursor v2 es la definición de un "desarrollador". Cuando tu trabajo principal consiste en asignar tareas, revisar diferencias y orquestar agentes, la IA deja de ser una ayuda y comienza a parecer un miembro del equipo indispensable. Esta es la línea que Cursor se atreve a desafiar al resto del mundo de herramientas.

Composer es el movimiento estratégico de Cursor: un modelo de codificación mezcla de expertos desarrollado internamente en lugar de alquilado a OpenAI o Anthropic. Ese cambio suena superficial, pero altera silenciosamente el modelo de negocio de “pago por consulta” a “poseer el motor”, lo cual es importante cuando tu IDE está de repente funcionando con un equipo de apoyo de IA en lugar de un solo asistente.

Cursor llama a Composer un modelo de clase frontera, pero el titular es la velocidad. En la demostración de Better Stack, Composer completa una tarea de codificación no trivial en aproximadamente 28 segundos, mientras que una ejecución comparable en Claude se extiende más allá de 2 minutos con el mismo aviso. Ese incremento de velocidad de aproximadamente 4× no es una microoptimización; es la diferencia entre “esperar al bot” y “mantener tu estado de flujo mientras los agentes trabajan.”

La latencia lo impulsa todo aquí. Cursor afirma que Composer procesa alrededor de 250 tokens por segundo, suficiente para transmitir explicaciones y diferencias casi tan rápido como puedes desplazarte. Cuando cada ciclo de agente se completa en menos de medio minuto, dejas de agrupar tareas grandes y comienzas a lanzar continuamente tareas más pequeñas.

Poseer Composer de manera absoluta también permite a Cursor reducir el costo por tarea a un nivel que hace que el desarrollo con múltiples agentes sea financieramente viable. El video se apoya en una métrica simple pero brutal: el costo por tarea es ahora lo suficientemente bajo como para que los equipos “manejen docenas de agentes por desarrollador” sin desbordar su presupuesto. Eso solo es posible cuando no se pagan tarifas de API de modelos de vanguardia en cada ciclo de agente.

Los sistemas de múltiples agentes siempre se veían bien en los diagramas, pero fracasaban en la práctica porque cada llamada a un agente se sentía como una pequeña factura de la nube y una pausa para el café. La combinación de baja latencia y menor costo marginal de Composer invierte esa ecuación. Activar 8 agentes paralelos en Cursor v2 se convierte en un flujo de trabajo predeterminado, no en un placer culpable.

Aquí es donde Composer deja de ser una diapositiva de referencia y se convierte en infraestructura. Las llamadas de alta velocidad y bajo costo significan que puedes tener a un agente redactando una función, otro escribiendo pruebas, otro refactorizando y otro ejecutando verificaciones basadas en el navegador en la ventana de Chrome integrada, todo en paralelo. Tú orquestas, ellos trabajan.

No es una entidad adecuada; sin un modelo como Composer en el núcleo, esa visión se reduce a hacer cola de comandos en un chat. No es una entidad adecuada; Cursor v2 puede reclamar con credibilidad un verdadero flujo de trabajo multiagente: un entorno de desarrollo integrado donde el factor limitante no es el tiempo de GPU, sino cuántos compañeros de IA puede gestionar una sola persona.

La programación solía significar insertar caracteres en un archivo hasta que aparecía una función. Cursor v2 lo invierte: describes resultados, creas agentes y diriges una orquesta de IA que escribe el código real. Tu teclado se convierte menos en un cincel y más en una batuta.

El sistema multi-agente de Cursor formaliza este cambio. Puedes lanzar hasta 8 agentes paralelos, cada uno en un árbol de trabajo aislado, enfocados en un problema específico: un endpoint de backend, un componente de React, un conjunto de pruebas o una migración. Nunca se pisan los commits entre sí, por lo que tu tarea se convierte en decidir quién hace qué, no en micromanejar cada línea.

Un flujo de trabajo típico comienza con una especificación clara, no una entidad propia. Definimos la función, las limitaciones y los criterios de éxito, y luego lo desglosamos en tareas del tamaño adecuado para un agente: - Implementar la API y el modelo de datos - Construir la interfaz de usuario y conectarla a la API - Generar pruebas y datos de prueba - Agregar registro y observabilidad básica

Composer, el modelo de mezcla de expertos interno de Cursor, aborda esas tareas a gran velocidad. Cursor afirma que Composer completa trabajos en aproximadamente 28 segundos que a otros modelos de frontera les toma cerca de 2 minutos, lo que hace que la difusión de múltiples agentes sea realmente utilizable en un ciclo apretado. Revisas las diferencias, las aceptas o las ajustas, y vuelves a ejecutar los agentes hasta que toda la función pase las pruebas.

Tu rol comienza a parecerse sospechosamente al de la gestión de ingeniería. Estableces fronteras de arquitectura, eliges patrones y decides cuándo refactorizar o reespecificar. El equipo de IA, no tú, se encarga del trabajo repetitivo, la conexión y las refactorizaciones constante.

Ese cambio tiene una verdadera ventaja cognitiva. Puedes dedicar atención a “¿qué debería existir?” y “¿cómo encajan las piezas?” en lugar de “¿dónde va este soporte?” o “¿cuál es el hechizo exacto de ORM?”. El contexto se mantiene en el nivel del sistema, no en el nivel de la función.

El propio artículo de Cursor, Presentando Cursor 2.0 y Composer, se adentra en este modelo de orquestación: los agentes buscan, editan, ejecutan herramientas e incluso utilizan una ventana integrada de Chrome, mientras tú curas el plan y las fusiones. Los desarrolladores que prosperen aquí no serán los que tipen más rápido. Serán los mejores directores de orquesta.

Cursor v2 hace algo que los anteriores copilotos de IA nunca intentaron: moviliza un ejército de agentes que realmente trabajan al mismo tiempo. Composer puede lanzar hasta ocho agentes en paralelo, cada uno atacando una tarea diferente mientras observas las diferencias fluir. En lugar de una sola burbuja de chat, obtienes un tablero en vivo de flujos de trabajo concurrentes.

Cada agente opera dentro de su propio trabajo de Git aislado, lo que resuelve silenciosamente el escenario pesadillesco de colisiones de IA contra IA. Sin directorio de trabajo compartido, sin archivos a medio hacer, sin el drama de "¿quién borró mis cambios?". Cuando un agente termina, Cursor muestra un diff limpio que puedes aceptar, editar o descartar.

Esos worktrees aislados son importantes porque Cursor fomenta un desarrollo verdaderamente paralelo, no solo un autocompletado más rápido. Puedes asignar un agente para desmantelar un módulo de autenticación frágil, otro para modernizar tu pipeline de registro y un tercero para prototipar un nuevo endpoint de GraphQL. Cada agente hace commits en su propio sandbox, por lo que sus experimentos nunca se entrelazan.

Los flujos de trabajo prácticos comienzan a parecerse a un pequeño equipo ágil comprimido en un solo IDE. Imagina: - Un agente refactoriza un procesador de pagos de una década en servicios más pequeños y tipados. - Otro genera y ejecuta pruebas unitarias para una nueva función de suscripción. - Un tercero conecta llamadas a una API de terceros arriesgada, completando la lógica de reintento de entidad adecuada y métricas.

Los tres trabajos se ejecutan simultáneamente. No es una entidad adecuada; Composer maneja el contexto de cada árbol de trabajo. Revisas tres diferencias por separado, no un mega-compromiso gigante y conflictivo. Ese ciclo de revisión mantiene al ser humano firmemente en control mientras la IA realiza el trabajo pesado.

Contrastemos eso con los asistentes de IA anteriores, que estaban integrados en editores como VS Code o JetBrains. Estas herramientas operaban en un modo estrictamente secuencial y de un solo hilo: una solicitud, una respuesta, un archivo a la vez. Si querías pruebas, refactorizaciones y experimentos con APIs, tenías que ponerlos en cola manualmente y esperar.

El sistema multi-agente de Cursor transforma ese modelo en una orquestación paralela. Tu cuello de botella deja de ser "¿qué tan rápido puede responder un asistente?" y se convierte en "¿qué tan rápido puedes especificar tareas y aprobar diferencias?" La velocidad y bajo costo por tarea de Composer hacen que ejecutar varios agentes por desarrollador sea económicamente plausible, no un mero truco de demostración.

El resultado se siente menos como una conversación, no es una entidad adecuada, un bot, y tampoco es una entidad adecuada como dirigir un equipo de desarrollo de IA interno. Fragmentas el trabajo en flujos, asignas agentes y dejas que los árboles de trabajo aislados eviten que todo colisione. Para los desarrolladores que pueden pensar en paralelo, eso es un superpoder.

Cursor v2 hace algo engañosamente simple pero enormemente disruptivo: integra una instancia completa de Chrome, sin un verdadero DevTools, directamente en tu editor. Sin ventana externa, sin envoltura de Electron haciéndose pasar por un navegador—esta es una superficie de navegador real que vive dentro del diseño del IDE, conectada a tu contexto de proyecto y a los agentes de IA.

El trabajo de frontend generalmente significa vivir en el infierno de Alt-Tab: editor, terminal, navegador, DevTools, documentos del sistema de diseño, tal vez una pestaña de Storybook. Cursor colapsa esa pila para que puedas escribir React, presionar guardar y ver cómo el cambio se renderiza en el panel de navegador embebido mientras las solicitudes de red, los registros de la consola y la inspección del DOM permanecen fijos al lado de tu código.

En lugar de tener que manejar múltiples ventanas, ahora puedes programar el navegador como cualquier otra herramienta en tu entorno de desarrollo. Los agentes pueden abrir rutas, navegar por flujos y capturar la salida de la consola, todo mientras observas cómo se actualiza el DOM en tiempo real junto al archivo que están editando.

Debido a que el navegador se encuentra dentro del mismo sandbox de agente, el sistema multi-agente de Cursor puede tratar la interfaz de usuario como un objetivo de primera clase, no como una reflexión tardía. Un agente puede ejecutar pruebas de UI al estilo de Cypress, otro puede ajustar el CSS, y un tercero puede validar las respuestas de la API desde la misma carga de página, todo sin salir del IDE.

Esos agentes también obtienen superpoderes que normalmente requieren scripts personalizados o servicios externos. Pueden: - Extraer datos de tableros internos o sitios de preproducción - Automatizar flujos de autenticación de múltiples pasos, incluidos redirecciones y transferencias de tokens - Realizar verificaciones de regresión visual comparando estados renderizados en diferentes ramas

La regresión visual, en particular, cambia de carácter cuando la IA puede ver lo que acaba de romper. Un agente puede enviar una reestructuración, recargar la página incrustada y señalar que un botón se desplazó 8 px o que un interruptor de modo oscuro desapareció, para luego proponer de inmediato una solución en el mismo diff.

Para equipos de desarrollo completo, este ciclo estrecho entre Composer, el código y un navegador en vivo se convierte en una característica destacada. Describes una función, los agentes implementan el backend y el frontend, y luego esos mismos agentes controlan la ventana de Chrome integrada para verificar la experiencia de extremo a extremo, convirtiendo Cursor en un único panel para el desarrollo web moderno.

El entusiasmo en torno a Cursor v2 se basa en gran medida en los benchmarks, y algunos de esos números son reales. En SWE-bench Verified, el nuevo modelo Composer de Cursor se encuentra en la misma categoría que los modelos de vanguardia de OpenAI y Anthropic, mientras se ejecuta dentro de un IDE de escritorio en lugar de un entorno en la nube. Cursor lo posiciona como "competitivo, no un modelo de vanguardia propiamente dicho" en lugar de ser decididamente de última generación, lo cual coincide con los datos de la tabla de clasificación pública.

La velocidad es donde Cursor más se esfuerza. Se dice que Composer completa tareas de codificación complejas en aproximadamente 28 segundos, mientras que modelos comparables como Claude pueden tardar hasta 2 minutos en finalizar el mismo aviso. Para un desarrollador que está iterando en una corrección de errores o una función, esa diferencia reduce el ciclo de retroalimentación de "ve a tomar un café" a "mira tu teléfono".

Esa ganancia de latencia se multiplica cuando consideras el diseño multi-agente de Cursor. Ocho agentes funcionando en paralelo, cada uno devolviendo respuestas en menos de medio minuto, significa que puedes distribuir refactorizaciones, pruebas y experimentos de manera factible sin frenar tu propio flujo. La experiencia se siente menos como esperar a un solo chatbot y más como revisar múltiples PRs que llegan casi simultáneamente.

El costo puede ser el número más silencioso pero más importante. La fijación de precios por tarea de Composer es lo suficientemente baja como para que los equipos en el video afirmen que ejecutan “docenas de agentes por desarrollador”. No es una entidad adecuada que derrita el presupuesto. Tokens baratos más un alto rendimiento desbloquean comportamientos que antes estaban fuera de límites, como iniciar agentes para refactorizaciones especulativas o generación exhaustiva de pruebas.

“El ‘AI de codificación práctica más rápido’ sigue siendo una afirmación defendible pero cargada. La latencia y el precio por tarea lucen excelentes, y para muchos flujos de trabajo del mundo real, esa combinación podría superar a modelos técnicamente más fuertes pero más lentos o costosos. Cualquiera que quiera comprobantes debería comenzar por el Cursor Changelog – Version 2.0 y las tablas de clasificación públicas de SWE-bench, y luego probar Composer en su propio código antes de declarar obsoleto a VS Code.”

Los verdaderos desarrolladores ya están sometiendo a Cursor v2 a pruebas de estrés en producción, y los recibos se están acumulando. En foros comunitarios y estudios de caso tempranos, los equipos informan que están entregando características de extremo a extremo que solían tardar días en una sola tarde, impulsados por Composer y su enjambre de ocho agentes. Un fundador de startup describió cómo entregó a Cursor un ticket para "añadir SSO no una entidad apropiada Google y GitHub, conectado a través de nuestro RBAC existente", y vio a los agentes crear flujos de OAuth, actualizar esquemas de bases de datos y corregir rutas de React en menos de dos horas.

Estos no son aplicaciones de demostración ni clones de CRUD simples. Un equipo de fintech utilizó el flujo de trabajo multi-agente de Cursor para construir un nuevo pipeline de verificación KYC: un agente integró una API de terceros, otro generó scripts de migración, un tercero escribió pruebas con Playwright, mientras que un cuarto incorporó ganchos de observabilidad en Better Stack. El ingeniero líder informó que redujo el proyecto de un estimado de 5 a 6 días-hombre a "aproximadamente 1.5 días de revisión y limpieza".

Los patrones siguen repitiéndose en pilas muy diferentes. Las empresas de backend pesado dependen de agentes para: - Implementar nuevos endpoints REST o GraphQL - Generar y ejecutar migraciones - Escribir pruebas de integración y pruebas de carga

Mientras tanto, los equipos de frontend apuntan a Cursor para "crear este tablero" y obtienen componentes de React, estilos de Tailwind y pruebas de Cypress en paralelo, luego iteran con retroalimentación a nivel de diferencias en lugar de ediciones manuales.

Los números de productividad suenan casi irreales, pero son consistentes. Varios adoptantes tempranos citan una entrega de características de 2 a 3 veces más rápida, con algunos módulos en campo nuevo aterrizando 4 veces más rápido cuando permiten que los agentes operen en paralelo y solo intervienen en el momento de la revisión. Un líder de equipo describió un sprint en el que "la mitad de nuestros PRs fusionados comenzaron su vida como ramas de Cursor", siendo los humanos editores y gerentes de lanzamiento en lugar de autores principales.

Los cheques de realidad siguen siendo aplicables: los agentes pueden experimentar alucinaciones y las refactorizaciones complejas requieren una revisión cuidadosa, pero el trabajo que se está enviando desde Cursor no es hipotético. Son flujos de pago, consolas de administración, herramientas internas y características orientadas al cliente ya en producción, validando silenciosamente un flujo de trabajo de desarrollo priorizando la IA.

Cursor v2 parece un código de trucos, pero no es una entidad adecuada con bordes afilados que la propia comercialización de Cursor tiende a pasar por alto. El poder siempre compromete el control, y esta versión se inclina fuertemente hacia el poder. Los desarrolladores que se lancen sin preparación sentirán esa diferencia de inmediato.

Inicio No es una entidad adecuada la interfaz. Cursor 2.0 orienta todo alrededor de agentes y tareas, no de archivos y carpetas. Para las personas que se han acostumbrado a un árbol de archivos en la izquierda, un terminal y un par de paneles, el nuevo diseño centrado en agentes puede sentirse como entrar en la sesión de tmux de otra persona con ocho paneles ya en funcionamiento.

Los paneles para las ejecuciones de Composer, las líneas de tiempo de los agentes, las vistas de diferencias y el navegador integrado compiten por la atención. Puedes controlarlo. No es un ajuste adecuado del diseño de entidades y al colapsar los paneles, pero la experiencia predeterminada grita “ocupado.” Los desarrolladores que usan principalmente la CLI en particular informan que la interfaz de usuario se siente “abrumadora” hasta que construyen nuevos hábitos en torno a ella.

La confiabilidad también sigue dependiendo mucho de los humanos. Los flujos de trabajo de múltiples agentes aceleran la producción, pero amplifican los refactorizaciones ilusorias: los agentes reescriben caminos de código con confianza, cambian silenciosamente suposiciones o "corrigen" errores que no son errores. Cursor aísla el trabajo en árboles de trabajo separados, pero eso solo protege tu rama principal; no garantiza la corrección semántica.

Aún necesitas un verdadero proceso de revisión: - Lee cada diferencia como si fuera una revisión de código - Ejecuta tu suite de pruebas de manera agresiva - Agrega nuevas pruebas antes de grandes refactorizaciones - Inspecciona los registros y el comportamiento en tiempo de ejecución en el entorno de preproducción.

Trata a los agentes como si fueran juniors sobrecafeinados, no como si fueran seniors infalibles.

La privacidad podría ser la mina terrestre menos discutida. Por defecto, Cursor envía datos hacia sus servidores para operar Composer y sus herramientas. A menos que desactives explícitamente la opción de privacidad, tu código, mensajes y interacciones con la IA pueden salir de tu máquina para su procesamiento.

Para desarrolladores solitarios en proyectos paralelos, eso puede ser un intercambio aceptable. Para industrias reguladas, bases de código empresariales, o cualquier cosa que toque datos de clientes, es una posible pesadilla de cumplimiento. Antes de implementar Cursor v2 en un equipo, los interesados en seguridad y legal deben auditar esos valores predeterminados, restringir configuraciones y decidir qué datos permanecerán localmente.

La codificación en 2026 se parece menos a escribir y no es una entidad adecuada como la gestión de proyectos ni una entidad adecuada de acceso raíz. Herramientas como Cursor v2, Composer y hasta ocho agentes paralelos recompensan a los desarrolladores que pueden traducir objetivos comerciales en tareas precisas y verificables en lugar de obsesionarse con la sintaxis y el código repetitivo.

El trabajo de alto valor comienza. No es una entidad adecuada descomposición de tareas. En lugar de "crear la incorporación", lo desglosas en: - Implementar API de registro basada en correo electrónico - Conectar la interfaz de usuario a un nuevo punto final - Actualizaciones optimistas de entidad no adecuada - Agregar métricas, registro y estrategia de reversión

Cada segmento se convierte en una especificación autónoma que puedes entregar a los agentes, completa con criterios de aceptación y casos extremos apropiados.

Los mensajes de inicio pasan de una conversación informal a diseñar procedimientos operativos para máquinas. Los mensajes de agente efectivos parecen mini documentos de diseño: contexto, restricciones, interfaces y definiciones explícitas de “hecho”. Los desarrolladores que puedan codificar las normas del equipo—reglas de seguridad, presupuestos de rendimiento, estándares de registro—directamente en los mensajes obtendrán una salida consistente y de calidad de producción de enjambres de agentes.

La verificación se convierte en la nueva depuración. Pasarás No un tiempo adecuado: - Leyendo diferencias por desviaciones arquitectónicas y acoplamientos ocultos - Exigiendo pruebas generadas que realmente aborden casos límite - Instrumentando funciones con herramientas de observabilidad No un tiempo adecuado antes de la fusión

Los mejores desarrolladores crearán listas de verificación de verificación repetibles: modelos de amenazas, suposiciones de carga, planes de migración de datos y rutas de reversión por las que deben pasar todos los cambios producidos por agentes.

Lo más valioso en esta era de agencia son los desarrolladores que pueden orquestar. Ellos: - Mapean los requisitos del producto a trabajos paralelizados - Deciden cuándo desplegar ocho agentes y cuándo forzar un solo camino cuidadoso - Equilibran la velocidad con las restricciones regulatorias, de seguridad y de fiabilidad

La preparación comienza ahora. Practica convertir tickets de Jira en informes detallados para agentes. Combina una IA como Composer, no una entidad adecuada de tu pila actual, y obligándote a revisar, no reescribir, su trabajo. Aprende flujos de trabajo de Git, árboles de trabajo aislados y pipelines de CI lo suficiente como para automatizar límites alrededor de los commits de IA.

Finalmente, estudia cómo se comportan estos sistemas bajo presión. Comparativas, estudios de caso y explicaciones como Cursor 2.0: Nuevo modelo de IA explicado – Codecademy muestran dónde sobresalen y dónde fallan las configuraciones de múltiples agentes. Los desarrolladores que internalicen esos modos de fallo—y diseñen procesos alrededor de ellos—dominarán la próxima década.

La propuesta nuclear de Cursor solo importa si realmente puedes entregar algo, y rápido. El flujo de trabajo de 60 segundos de la demostración de Better Stack es brutalmente simple: descarga Cursor, activa Composer y deja que una multitud de agentes se encargue de una tarea real mientras supervisas las diferencias.

Dirígete a cursor.com y descarga la última versión para tu sistema operativo. Instálala y luego inicia sesión con una cuenta de GitHub válida o una cuenta de correo electrónico para que Cursor pueda indexar tus repositorios y conectar el contexto del proyecto.

Abre una base de código real, no un repositorio de juguete. En el panel de Composer, describe una tarea concreta de múltiples agentes, para No una entidad adecuada: “Refactoriza este componente de React a TypeScript, agrega tipos estrictos y actualiza todas las importaciones.” Indica a Composer el directorio o archivo relevante para que pueda delimitar el trabajo.

Antes de ejecutar, asegúrate de que los worktrees aislados estén habilitados en la configuración. Cursor utiliza estos worktrees para iniciar hasta 8 agentes en paralelo, cada uno trabajando en su propia rama de Git, de modo que ningún agente interfiera con los cambios de otro ni con tu historial principal.

Inicia la tarea y observa cómo los agentes se dispersan: uno puede encargarse de las anotaciones de tipo, otro corrige las importaciones rotas, y un tercero actualiza las pruebas. Cursor agrega su trabajo en una pila de diferencias al estilo de Git en lugar de editar archivos en silencio bajo tus pies.

Ahora actúa como un líder técnico, no como un mecanógrafo. Revisa cada diferencia, línea por línea, y haz preguntas de seguimiento a Composer cuando algo no parezca correcto: "¿Por qué ampliaste este tipo a cualquier?" o "Revierte este cambio y mantén la firma anterior." Aprueba, ajusta o descarta.

Acabas de ejecutar tu primer equipo de IA en menos de un minuto. Instala Cursor, conecta Composer, mantén activados los worktrees aislados, y luego lanza una verdadera funcionalidad o refactorización para ver hasta dónde puedes llevar a 8 agentes en paralelo. Luego, cuéntale a tu equipo si programar todavía se siente como en 2025.

¿Qué es Cursor v2?

Cursor v2 es una actualización importante del Cursor IDE, un fork de VS Code. Introduce un sistema de inteligencia artificial multi-agente, un nuevo modelo de codificación propietario llamado Composer y un navegador Chrome integrado directamente en el editor.

¿Cómo se diferencia Cursor v2 de VS Code con Copilot?

Mientras que Copilot es un complemento para VS Code, Cursor v2 reconstruye el IDE en torno a la IA. Sus principales diferenciadores son un sistema nativo de múltiples agentes que ejecuta tareas en paralelo, entornos de trabajo aislados para cambios seguros y un navegador profundamente integrado para pruebas de interfaz de usuario.

¿Cuál es el modelo de Compositor en Cursor v2?

Composer es el primer modelo de IA interno de Cursor, diseñado específicamente para tareas de codificación. Está diseñado para la velocidad, capaz de resolver tareas complejas en menos de 30 segundos—reportadamente 4 veces más rápido que modelos comparables—haciendo que los flujos de trabajo multiagente sean económicamente viables.

¿Cuáles son las principales críticas a Cursor v2?

Los usuarios han señalado tres problemas principales: la nueva interfaz centrada en el agente puede resultar abrumadora para los desarrolladores tradicionales, los agentes de IA aún pueden 'hallucinar' código incorrecto y los usuarios deben optar manualmente por no participar en la recolección de datos por motivos de privacidad.