Limitar la primera tarea del agente en la nube de Cursor a una corrección verificable

Encargar a Cursor un fallo pequeño y reproducible y esperar a que devuelva una PR para revisión humana es una buena primera forma de probar un agente en segundo plano. Una tarea adecuada para delegar debe cumplir tres condiciones a la vez: el comportamiento esperado está claro, se puede verificar en el entorno remoto y una persona responsable puede comprender el alcance de los cambios. Si falta alguna, resulta más útil resolverla primero que seguir ampliando el prompt.

Cursor llama actualmente a este producto Cloud Agents; antes se llamaba Background Agents. Trabaja en una máquina virtual aislada en la nube, en lugar de tomar el control del directorio de trabajo local actual. En las tareas de repositorio, modifica y entrega el código en una rama independiente. El siguiente análisis sobre cómo elegir tareas se basa en la documentación oficial; el ejemplo no se ha ejecutado.

Supongamos que un proyecto tiene un endpoint que devuelve una lista: una consulta vacía válida debería devolver un array vacío, pero provoca una excepción. El equipo ha confirmado el comportamiento correcto y dispone de pruebas pertinentes. Es más adecuado para delegar que «mejora la búsqueda», porque el agente puede investigar la causa, modificar la implementación y añadir una prueba de regresión en torno a un resultado observable. Quien revisa también puede determinar si la corrección es acertada.

El mismo criterio se aplica a añadir pruebas para casos límite conocidos, corregir ejemplos de documentación que no coinciden con una interfaz existente y eliminar código duplicado dentro de un alcance bien definido. Pero la refactorización también necesita pruebas existentes que protejan el comportamiento observable desde el exterior. Si faltan, hay que pedir primero que se identifiquen los componentes que llaman al código y se añadan pruebas, sin solicitar al mismo tiempo grandes cambios estructurales.

La corrección anterior se podría delegar con estas instrucciones:

• Reproducir la excepción que provoca el endpoint de listas al procesar una consulta vacía válida. Añadir primero una prueba de regresión que falle con la implementación anterior.
• Corregir el resultado para esa entrada de modo que devuelva una respuesta satisfactoria y un array vacío. Mantener el tratamiento actual de las entradas incorrectas, sin cambiar los parámetros de la interfaz ni la estructura de la respuesta.
• Modificar únicamente la implementación y las pruebas relacionadas. No actualizar dependencias ni cambiar la autorización, el esquema de la base de datos o la configuración de despliegue. Si es necesario exceder este alcance, explicar primero el motivo y detenerse.
• Ejecutar las pruebas pertinentes y las comprobaciones existentes del proyecto. Registrar los comandos, los resultados y las comprobaciones que no se hayan podido ejecutar. Entregar una PR en borrador que explique la causa raíz, los archivos modificados, las evidencias de verificación y los riesgos pendientes. No fusionarla.

Este es un ejemplo de tarea para el análisis, no un script directamente ejecutable que afirme que esos archivos o comandos existen. Para una delegación real también hay que indicar el repositorio, el commit de referencia, la entrada concreta que reproduce el problema y los comandos de prueba del proyecto. Al aceptar el trabajo, hay que confirmar que la nueva prueba cubra realmente el fallo original, en lugar de fijarse solo en «pruebas superadas». Si el agente ha eliminado las aserciones o ha cambiado la prueba para convertir el comportamiento incorrecto en el resultado esperado, un indicador verde sigue sin significar nada.

La documentación de entornos de Cursor explica que los agentes alojados en la nube se ejecutan en Ubuntu y pueden configurarse con la ayuda del agente o mediante un Dockerfile. No se puede dar por hecho que las herramientas ya instaladas localmente, los archivos sin confirmar o las conexiones a servicios privados estén también disponibles en remoto. Antes de poner la corrección en cola, hay que verificar que las dependencias se puedan instalar, las pruebas puedan iniciarse y los servicios necesarios sean accesibles.

El repositorio, los repositorios de los que depende y los submódulos necesitan los permisos de lectura y escritura correspondientes. Si la tarea depende de componentes disponibles solo en el equipo de un desarrollador, o si las pruebas deben acceder a un servicio de la red interna cuyo acceso aún no se ha autorizado, hay que resolver primero el entorno y los permisos. No se deben presentar fallos de instalación o tiempos de espera de red agotados como código ya verificado. Se puede reducir la tarea a entregar un análisis de la causa y propuestas de cambio, o pasar a un flujo de trabajo local e interactivo que tenga acceso al entorno necesario.

Para la primera tarea conviene elegir una corrección que no requiera datos ni credenciales de producción, y utilizar ejemplos de los que se haya eliminado la información sensible o dobles de prueba. Si no se puede establecer un entorno de verificación fiable, la tarea todavía no es adecuada para avanzar sin supervisión hasta estar lista para fusionarse.

La documentación de Cursor indica que Cloud Agents tiene acceso a Internet de forma predeterminada y ejecuta automáticamente los comandos de terminal. Puede seguir ejecutando pruebas, pero también puede verse afectado por una inyección de prompts tras leer contenido malicioso. Una rama independiente puede aislar los cambios de código, pero no recuperar datos que ya se hayan enviado al exterior. Considerar que «al final alguien revisará la PR» constituye un límite de seguridad durante la ejecución no es suficiente.

Antes de empezar, se deben limitar los destinos externos permitidos y proporcionar solo los permisos y las credenciales que necesite la tarea. Cursor ofrece Runtime Secrets, que oculta los valores en las salidas de herramientas, los historiales de chat y los commits. Sin embargo, esos valores siguen disponibles para los programas como variables de entorno y siguen siendo visibles para quienes interactúan con el entorno a través del terminal. Ocultar los valores en la salida no impide utilizar las credenciales ni sustituye la limitación del alcance de sus permisos.

Por eso, las migraciones de bases de datos de producción, los cambios en las reglas de pago o autorización y las modificaciones importantes que dependen de decisiones de producto aún sin resolver no son buenas opciones para una primera tarea sin supervisión. Esta es una recomendación para elegir tareas según el alcance de su impacto, no una afirmación de que el producto no pueda modificar ese código. Primero deben ser las personas quienes definan las restricciones del negocio y los riesgos; después, el trabajo se divide en cambios pequeños que puedan verificarse de forma independiente.

El proceso de entrega descrito oficialmente consiste en subir una rama y abrir una PR para revisión humana; también se puede solicitar un borrador. El equipo debe utilizarlo para aclarar responsabilidades: el agente aporta los cambios y las evidencias, mientras que la persona responsable decide si se cumplen los requisitos, si los riesgos son aceptables y si se fusiona el código. No se debe interpretar el mensaje de finalización del agente como autorización para fusionar.

Durante la revisión, primero hay que comprobar que las diferencias sigan dentro del alcance original y después volver a ejecutar las pruebas de regresión clave y las comprobaciones de integración necesarias. Se deben revisar las ramas de gestión de errores, los componentes que llaman al código, los cambios de dependencias y la posible exposición de datos en los registros. Las comprobaciones que no se hayan podido ejecutar deben quedar documentadas en la PR, indicando claramente quién las completará. Si los cambios no dejan de extenderse, se eluden repetidamente pruebas que fallan o hacen falta nuevas decisiones de negocio, hay que volver a una conversación interactiva y dividir de nuevo la tarea.

El beneficio de un agente en segundo plano depende de la calidad de la entrega. Se debe empezar por una corrección pequeña que pueda reproducirse sin permisos de producción, tenga un resultado claro y pueda revisarse por completo. Solo después de comprobar que tanto el entorno como el proceso de revisión resisten esta primera ronda conviene ampliar el alcance de la delegación.