Agentes en la nube de Cursor: Programan, incluso cuando el portátil está apagado

5 min de lectura

Cursor ahora permite que sus agentes de código sigan trabajando en la nube, incluso cuando el portátil lleva tiempo cerrado. Quien cambie al modo de planificación a «Build in Cloud» cede la ejecución a un agente en la nube que continúa funcionando en un entorno Ubuntu aislado, mientras el desarrollador sigue trabajando localmente o cierra el equipo. El agente prepara el pull request para su finalización, proporciona demos y capturas de pantalla para su control y puede enviarse y recibirse con un solo clic entre la nube y el entorno local. Suena a comodidad, pero en realidad desplaza la pregunta sobre dónde se crea el software y, por tanto, también dónde debe asegurarse.

Lo más importante en resumen

• Los agentes de código migran al servidor: Cursor ejecuta agentes en segundo plano en máquinas virtuales en la nube aisladas, que funcionan de manera independiente al editor local y continúan trabajando incluso con el portátil cerrado.
• La utilidad es real: Las tareas paralelas, un pull request ya preparado y una transferencia entre la nube y el entorno local alivian la carga de los desarrolladores y aceleran el flujo de trabajo.
• La factura llega más tarde: Los agentes del lado del servidor consumen recursos de cómputo en la nube y, según la configuración, trabajan con repositorios y secretos. Los costes y la seguridad de las compilaciones deben abordarse antes del despliegue, no después.

Relacionado:Coolify en prueba: Self-hosting en lugar de Vercel y Heroku  /  Cuando la factura de la IA desborda el presupuesto de la nube

Lo que Cursor ha cambiado concretamente

La esencia radica en un cambio en la ejecución. El agente estándar de Cursor trabaja en línea dentro del editor sobre los archivos locales, una tarea tras otra. Por el contrario, los agentes en la nube se ejecutan de forma asíncrona en sus propios entornos Ubuntu aislados. Desde una ampliación a principios de 2026, cada uno de estos agentes cuenta con un entorno de desarrollo completo con escritorio y navegador, por lo que también puede manejar interfaces y demostrar los resultados de forma visual.

En la práctica, esto significa que, en el modo de planificación, el desarrollador inicia una tarea con «Build in Cloud» y puede cerrar el equipo a continuación. El agente continúa iterando en el servidor, prepara el pull request para la fusión y, con ello, no bloquea ninguna sesión local. Quien desee asumir el resultado lo recupera con un clic en el entorno local y, si es necesario, lo envía de nuevo a la nube. Según la documentación de Cursor, los agentes en la nube generan demos y capturas de pantalla en este proceso, lo que permite verificar su trabajo sin necesidad de una lectura exhaustiva.

Por qué esto importa para los equipos de DevOps

El beneficio evidente es la paralelización. Varios agentes pueden trabajar simultáneamente en tareas diferentes, sin que el desarrollador tenga que bloquear su ordenador para ello. Esto desplaza el rol del humano de la labor de tecleo a la supervisión: definir tareas, revisar resultados, aprobar solicitudes de extracción (pull requests).

Para los equipos de DevOps en DACH, el punto más interesante es la cercanía a la pipeline. Un agente que actúa hasta completar una solicitud de extracción interviene profundamente en el flujo de desarrollo. Esto exige líneas claras de actuación: ¿qué repositorios puede ver, qué acciones puede desencadenar y quién da la aprobación final? Sin estas reglas, una herramienta de productividad se convierte rápidamente en una automatización incontrolada. La pregunta sobre el control sobre agentes autónomos afecta ya no solo a Cursor, sino que preocupa a cada dirección de TI.

También se desplaza el cuello de botella. Si los agentes entregan el código en minutos, la revisión se convierte en el punto crítico. Un equipo que antes revisaba una docena de pull requests al día ahora se enfrenta a un múltiplo de estos, todos aparentemente plausibles. Aquí se decide el verdadero gancho de productividad: quien no escala su capacidad de revisión solo acumula riesgos más rápido. Son útiles criterios claros sobre qué cambios puede preparar un agente por cuenta propia y cuáles siempre requieren una revisión humana, por ejemplo, todo lo relacionado con dependencias, migraciones o lógica de seguridad.

La cuestión de costes sigue abierta

Los agentes en el servidor tienen un costo. Dependiendo del plan y del contingente, cada máquina virtual en la nube que itere en segundo plano se contabiliza como tiempo de cálculo consumido, y eso suma cuando un equipo deja corriendo varios agentes de forma continua. Quien no controle los costos de inferencia y cómputo experimentará la misma sorpresa que muchos proyectos de inteligencia artificial, cuando la factura de IA superó el presupuesto de nube.

La cuenta real compara las horas de desarrollo ahorradas frente a los costos recurrentes en la nube. En muchos casos sí compensa, porque un agente paralelo sustituye un tiempo de espera costoso. Pero esta evaluación debe hacerse antes de implementar ampliamente la herramienta, de lo contrario la facturación de la nube aparecerá cuando ya se haya superado el presupuesto.

El entorno de construcción se convierte en una superficie de ataque

El segundo punto ciego es la seguridad. Un agente en la nube que prepare una solicitud de extracción trabaja en el repositorio y, según la configuración, puede acceder a secretos de construcción o incluso a derechos de despliegue. Estos accesos se encuentran en un entorno que el desarrollador ya no tiene directamente ante sí. Una VM aislada ayuda, pero no sustituye una gestión clara de permisos.

Es útil tratar al agente como otro runner de construcción: permisos mínimos, tokens de corta vida, separación clara entre permisos de lectura y de despliegue, y un registro de lo que ha tocado. Quien introduzca agentes en el servidor sin este fundamento aumenta su superficie de ataque precisamente donde se construye y entrega el software.

Además está la perspectiva de la cadena de suministro. Un agente que añade o actualiza paquetes toma decisiones sobre dependencias que luego terminarán en el sistema productivo. Sin una revisión de estas propuestas, la responsabilidad sobre la cadena de suministro de software se traslada silenciosamente a un modelo. Los equipos que ya usan dependencias firmadas y construcciones reproducibles deberían aplicar explícitamente estas mismas controles a lo que aporta un agente en la nube.

Preguntas frecuentes

¿Qué son los agentes en la nube de Cursor?

Agentes asincrónicos que corren en entornos aislados de Ubuntu en la nube, independientemente del editor local. Trabajan en tareas incluso cuando el equipo está cerrado y preparan solicitudes de extracción.

¿Puedo cerrar realmente el portátil?

Sí. En modo plan, «Build in Cloud» transfiere la ejecución a un agente en la nube que continúa en el servidor. Los resultados se pueden recuperar posteriormente haciendo clic en la entorno local.

¿Cuál es el beneficio para los equipos DevOps?

Paralelismo y un pull request preparado. Varios agentes trabajan simultáneamente sin bloquear la sesión local, y la tarea del humano se desplaza hacia definir y liberar.

¿Cuánto cuesta el funcionamiento?

Depende del plan y del cupo, cada máquina virtual en la nube en ejecución consume tiempo de procesamiento. Los costes deben contabilizarse contra las horas de desarrollo ahorradas antes de la implementación amplia del herramienta.

¿Qué preguntas de seguridad surgen?

Dependiendo de la configuración, el agente trabaja en el repositorio y puede acceder a secretos de compilación o derechos de despliegue. Debe tratarse como un runner de compilación: permisos mínimos, tokens efímeros y un registro de sus acciones.

Consejos de lectura

• OpenTelemetry: una vez instrumentado, el backend se elige libremente
• OpenTofu vs. Terraform: ¿cuál herramienta IaC realmente encaja?
• Apple divide la inferencia de IA: dispositivo contra nube

Más del MBF Media Network

Fuente de imagen: generada por IA (junio 2026)