AI / ML 16 Czerwiec 2026

Cursor — el modo Multitask y las novedades de Junio 2026

También en:

Cursor no para de acelerar. En los últimos dos meses el editor ha recibido una serie de actualizaciones que cambian la forma de trabajar con agentes de IA. La novedad central es el modo /multitask, pero junto a él han llegado mejoras en los Canvases, nuevas capacidades del SDK y una aceleración significativa de Bugbot. Este artículo describe cada uno de esos cambios y explica cuándo conviene utilizarlos.


El modo Multitask — subagentes en paralelo desde una única sesión

¿Qué es /multitask?

Introducido el 24 de abril de 2026 en Cursor 3.2, /multitask es un comando disponible en la ventana Agents Window. En lugar de encolar las peticiones para que un único agente las procese una por una, al escribirlo Cursor lanza subagentes asíncronos que trabajan en paralelo. Una tarea grande puede dividirse automáticamente en fragmentos más pequeños, cada uno asignado a su propio subagente.

Si ya hay mensajes esperando en la cola, basta con pedir a Cursor que los cambie al modo multitask: los subagentes arrancan de inmediato, sin esperar a que termine la ejecución en curso.

Cómo funciona por dentro

Cada subagente tiene su propio contexto. Al agente padre solo le llega el resumen final, de modo que la sesión principal conserva toda su capacidad de planificación y permanece receptiva a preguntas de seguimiento. Por defecto los subagentes usan el mismo modelo que el agente padre (con excepciones para BYOK y facturación por petición).

/multitask tiene dos modos de funcionamiento:

  1. Paralelización de la cola — en lugar de ejecutarse uno tras otro, los mensajes en cola se lanzan como subagentes en segundo plano de forma simultánea.
  2. Descomposición automática — una única petición grande se divide en fragmentos lógicos, cada uno enviado a un subagente distinto.

Qué aporta /multitask sobre el mecanismo de subagentes existente

Una aclaración importante: antes de /multitask, Cursor ya podía lanzar subagentes en paralelo mediante la herramienta Task — un agente padre podía delegar de forma autónoma subtareas independientes a varios subagentes y esperar sus resultados. /multitask no introduce un mecanismo radicalmente nuevo; lo que hace es modificar el existente en varios aspectos concretos:

Conversión de la cola en paralelismo. Antes de /multitask, los mensajes en cola se procesaban secuencialmente, uno tras otro. /multitask permite al usuario convertir explícitamente esas peticiones encoladas en ejecuciones paralelas. Antes, conseguir esto requería redactar un prompt que convenciera al agente de usar la herramienta Task de la manera adecuada.

Los subagentes corren en segundo plano — el padre no se bloquea. Con el enfoque clásico de la herramienta Task, el agente padre quedaba bloqueado hasta recibir los resultados de los subagentes. Con /multitask, los subagentes funcionan de forma asíncrona en segundo plano y el padre recupera la interactividad de inmediato: puedes hacerle preguntas y escribir nuevos prompts mientras los subagentes siguen trabajando.

Descomposición automática sin prompts complejos. En lugar de construir un prompt que lleve al agente a dividir la tarea y llamar manualmente a la herramienta Task, basta con escribir /multitask y Cursor determina por sí solo cómo repartir el trabajo en piezas independientes.

Botón "Build in Parallel" en el modo de planificación. Cuando el agente genera un plan de acción, puedes pulsar "Build in Parallel" en lugar de "Build Locally" — Cursor identifica automáticamente las partes independientes del plan y las ejecuta como subagentes en paralelo.

Aspecto Herramienta Task (antes) /multitask
Quién lo inicia El agente de forma autónoma El usuario explícitamente o con "Build in Parallel"
El padre mientras trabajan los subagentes Bloqueado Interactivo
Cola de peticiones Secuencial Puede convertirse en paralela
Descomposición de la tarea El agente debe inferirla del prompt Automática al invocar /multitask

Cuándo usarlo — y cuándo no

/multitask funciona mejor cuando una tarea tiene workstreams genuinamente independientes — por ejemplo, escribir pruebas para varios módulos a la vez, generar documentación para distintas clases o refactorizar archivos no relacionados entre sí. También resulta útil cuando quieres que el trabajo avance en segundo plano mientras sigues haciendo preguntas.

Evítalo cuando las tareas estén estrechamente acopladas y modifiquen los mismos archivos — en ese caso, combina /multitask con worktrees (ver más abajo) o trabaja simplemente de forma secuencial.


Worktrees en Agents Window (Cursor 3.2, 24 de abril de 2026)

Junto con /multitask, Cursor 3.2 introdujo un sistema mejorado de worktrees directamente en la ventana Agents Window. Un worktree es un checkout de git independiente en su propia rama — cada subagente puede editar sus propios archivos sin riesgo de conflictos con otros agentes que trabajen al mismo tiempo.

Cuando un subagente termina, un solo clic lleva esa rama al primer plano para probar los cambios en local. Esto funciona especialmente bien combinado con /multitask — los subagentes trabajan en ramas aisladas, lo que hace que los merges sean sencillos y predecibles.


Multi-root workspaces (Cursor 3.2, 24 de abril de 2026)

Una sola sesión de agente puede ahora apuntar a un workspace compuesto por varias carpetas a la vez. En la práctica esto significa que un agente puede hacer cambios transversales que abarquen frontend, backend y librerías compartidas simultáneamente, sin necesidad de redirigirse cada vez que cambia de repositorio. El workspace puede guardarse como un perfil reutilizable.


Canvas Design Mode y el informe de uso de contexto (Cursor 3.7, 4 de junio de 2026)

Design Mode en los Canvases

Cursor ha incorporado un modo de diseño directamente en los Canvases. En lugar de describir un cambio con palabras — "mueve la leyenda del gráfico a la derecha" — puedes hacer clic en el elemento de UI dentro del Canvas, añadir una anotación y enviársela al agente como instrucción directa. El modo funciona de manera análoga a las herramientas de inspección del navegador.

Esto acorta el ciclo de iteración al editar dashboards, informes y herramientas internas generados por el agente.

Informe de uso de contexto

Cursor puede ahora mostrar un informe interactivo del consumo de tokens directamente como un Canvas. El informe desglosa el consumo en categorías: system prompt, definiciones de herramientas, reglas, skills, historial de chat y más. Como el resultado es un Canvas, puedes hacer preguntas de seguimiento — por ejemplo, "¿qué regla consume más contexto en archivos TypeScript?" — y el agente ajusta la visualización en consecuencia.

El botón Debug with Agent abre una nueva conversación en la que Cursor propone formas concretas de reducir el uso de contexto.

Otras mejoras de los Canvases incluidas en la misma actualización:

  • Los Canvases compartidos pueden abrirse ahora en pantalla completa en el navegador, lo que facilita las presentaciones.
  • Los agentes pueden incrustar en los Canvases botones que ejecutan un prompt concreto al pulsarlos.
  • Mejora en la corrección de errores de tipos dentro de los Canvases.
  • Opciones de estilado de componentes ampliadas y mayor personalización de los gráficos.

Bugbot — 3× más rápido, un 22% más barato, más bugs detectados (10 de junio de 2026)

Bugbot ha recibido una actualización importante:

  • El tiempo medio de revisión se ha reducido de unos 5 minutos a ~90 segundos.
  • El coste por ejecución ha bajado un 22%.
  • La detección de bugs ha mejorado un 10% — de una media de 0,56 a 0,62 bugs por revisión.

Las mejoras son posibles gracias a la migración de Bugbot al modelo Composer 2.5.

Nuevas capacidades de Bugbot

/review antes de hacer push — ahora puedes ejecutar Bugbot y Security Review con el comando /review antes de subir el código. Cursor pregunta qué agentes lanzar, o puedes llamarlos directamente con /review-bugbot y /review-security. /review también se sincroniza con Bugbot en GitHub y GitLab: si abres una PR con el mismo diff, Bugbot lo reconoce, omite la revisión y deja un comentario indicando que ya ha revisado ese diff.

Revisar solo los cambios nuevos — Bugbot puede configurarse ahora para revisar únicamente lo que ha cambiado desde la última revisión, manteniendo el feedback centrado en tus últimas modificaciones en lugar de repasar toda la PR de nuevo.


Actualizaciones del Cursor SDK (SDK 3.7, 4 de junio de 2026)

Para los desarrolladores que construyen automatizaciones y pipelines CI/CD sobre Cursor:

Herramientas propias (customTools) — ahora puedes registrar tus propias funciones como herramientas disponibles para el agente, sin necesidad de alojar un servidor MCP independiente. Las herramientas son heredadas automáticamente por todos los subagentes de la sesión.

Auto-review para el modo headless — la opción local.autoReview dirige las llamadas a herramientas a través de un clasificador que decide cuáles requieren confirmación y cuáles pueden ejecutarse automáticamente. Resulta útil en scripts sin intervención humana.

Store JSONL y stores personalizados — hasta ahora los metadatos de agentes y ejecuciones se guardaban en SQLite. Ahora puedes optar por un store JSONL (JsonlLocalAgentStore), que escribe los datos en un archivo de texto plano fácil de comparar con diff y de versionar en el repositorio.

Subagentes anidados — los subagentes pueden ahora crear sus propios subagentes hasta cualquier profundidad de anidamiento.


Resumen

Cursor 3.2 y 3.7 empujan al editor hacia un modelo de trabajo en flota — en lugar de un único agente trabajando secuencialmente, el patrón habitual se está convirtiendo en un coordinador que delega subtareas en subagentes paralelos. El modo /multitask es la entrada más sencilla a ese modelo, mientras que los worktrees y los multi-root workspaces eliminan las fuentes de conflicto más comunes en el trabajo paralelo. El Canvas Design Mode y el informe de contexto acortan los ciclos de iteración a nivel de artefactos, y un Bugbot más rápido reduce el coste del control de calidad automatizado.


Referencias