Cómo configuramos nuestro entorno para Cloud Agents
Cuando decidimos darles computadoras a los Cloud Agents para que pudieran probar sus cambios, el primer paso fue asegurarnos de que supieran probarlos bien en nuestra propia base de código.
Lograr que nuestro monorepo funcionara con Cloud Agents nos enseñó que el entorno de desarrollo es un producto en sí mismo, aunque sus usuarios sean agentes. Hay que conseguir que la Cloud se comporte como el entorno de desarrollo local, que el repositorio sea lo bastante claro para que los agentes puedan ejecutar y probar código sin depender de conocimientos tácitos, y mantener ese entorno en buen estado a medida que evoluciona la base de código.
Crear ese entorno ha cambiado nuestra forma de trabajar. En diciembre, los Cloud Agents fueron autores de aproximadamente una de cada diez PR fusionadas en el monorepo de Cursor. Hoy, generan más de la mitad.
7-day rolling share of merged PRs from cloud agents
Adaptar la Cloud al desarrollo local
El primer paso para que los Cloud Agents funcionaran bien en nuestro repositorio fue lograr que este funcionara bien en una máquina virtual de la Cloud. Esta etapa resulta familiar para cualquier ingeniero que haya configurado un entorno de desarrollo remoto por primera vez.
La mayoría de los desarrolladores de Cursor trabajan localmente en equipos Mac, pero nuestras máquinas virtuales en la Cloud se ejecutan en Linux. Esto implicó adaptar varias utilidades de desarrollo y scripts de configuración para que funcionaran en máquinas virtuales Ubuntu. Agregamos dependencias de desarrollo críticas a un Dockerfile definido por Cursor que sirve como imagen base para los Cloud Agents.
También trabajamos con nuestro equipo de seguridad para incorporar funcionalidades de seguridad al producto de Cloud Agent, de modo que los usuarios pudieran inyectar con confianza los secretos necesarios en el entorno del agente. Estas funcionalidades incluyen restricciones de salida de red, acceso a repositorios remotos de Git limitado por ámbito y mediante proxy, análisis de secretos en commits y mensajes de commit, y redacción de secretos en los resultados de las herramientas, lo que evita que el agente lea los valores de los secretos incluso si lo intenta.
Una interfaz más sencilla para los agentes
Incluso después de tener nuestro entorno de desarrollo funcionando en máquinas virtuales Ubuntu, los agentes seguían teniendo dificultades para ejecutar nuestro código. No era sorprendente, porque nuestra experiencia de desarrollo era desordenada e implicaba aprender y recordar numerosos comandos y opciones de compilación, además de scripts de utilidad.
Escribimos skills sobre cómo compilar y ejecutar muchas partes del sistema, pero esto solo ayudó de forma marginal. Los skills pueden documentar los comandos adecuados, pero los propios comandos eran complejos y estaban llenos de trampas.
Para reducir esa complejidad, creamos una CLI llamada anydev, que los agentes pueden usar para iniciar todos los servicios. También canalizamos los scripts de utilidad habituales a través de anydev y lo equipamos con varios menús de --help que explican cómo usar cada subcomando. anydev también cuenta con un proceso supervisor que supervisa y reinicia comandos de compilación de larga duración, eliminando por completo esa responsabilidad del modelo.
anydev simplificó lo suficiente la experiencia de desarrollo como para que los agentes pudieran ejecutar su código de forma fiable. Los skills ayudaron a documentar cómo usarlo, pero el cambio más importante fue que los agentes ya no tenían que lidiar con comandos de compilación especializados de varios pasos, evitar trampas ocultas o supervisar procesos de larga duración.
Fue entonces cuando los Cloud Agents, cada uno con su propio ordenador, comenzaron a aportar un valor real frente a los agentes locales. Con el uso del ordenador, su herramienta recordScreen y un entorno de desarrollo funcional, los agentes ya podían probar sus cambios de principio a fin y demostrar al usuario la corrección de su trabajo.
También podían compartir demostraciones grabadas por el agente en Slack cuando alguien solucionaba un reporte de error, o en una PR al abrir un cambio. Para muchas tareas, los ingenieros ya podían fusionar y desplegar con confianza código de Cloud Agents sin siquiera consultar la rama localmente.
Un entorno autorreparable
El entorno del agente cambia constantemente, por lo que mantenerlo operativo implica actualizar continuamente cómo se ejecuta y a qué puede acceder.
Para diagnosticar y recuperar entornos inestables, creamos Cursor Cloud MCP. Elegimos MCP porque nos proporcionaba herramientas detectables dinámicamente con interfaces que podíamos modificar sin tener que reconstruir el bucle del agente. Los Cloud Agents lo usan para inspeccionar su propio entorno en busca de fallos de configuración, políticas de salida, secretos modificados y mucho más. Esto les permite diagnosticar y solucionar incidencias a medida que surgen, y recuperar antes los entornos inestables.
Con Cursor Cloud MCP implementado, configuramos una automatización llamada Cloud Doctor, que comprueba periódicamente si hay fallos, distingue entre errores que podrían ser transitorios y errores relevantes, realiza análisis de causa raíz y puede abrir PR para solucionar incidencias con un alto grado de confianza.
Mejorar la experiencia de los agentes
Incluso en un entorno estable, los agentes a veces siguen rutas largas o innecesariamente complejas para verificar sus cambios. Pueden usar la skill equivocada, encontrarse con incidencias evitables en la máquina virtual o seguir flujos de trabajo que tardan más de lo necesario.
Aquí también usamos Cursor Cloud MCP. Los agentes de Cloud Doctor inspeccionan trazas para identificar dónde se equivocó otro agente, qué skills o comandos resultaron engañosos y qué flujos de trabajo son sistemáticamente lentos. A partir de esos hallazgos, Cloud Doctor corrige la skill, simplifica la ruta o modifica el entorno para facilitarle el trabajo al siguiente agente.
Este ciclo mejora continuamente la experiencia de los desarrolladores al trabajar con los propios agentes. Cuando el entorno es estable y se autorrepara, los agentes se ejecutan de forma fiable y los desarrolladores confían a los Cloud Agents tareas más importantes.
Esto nos ha permitido ampliar internamente la adopción de los Cloud Agents, que ahora generan la mayor parte del código que lanzamos.
Prepara tu entorno para los Cloud Agents
La productividad de los Cloud Agents depende en gran medida del entorno. Para saber si tu base de código está lista, empieza por responder tres preguntas:
- ¿Los agentes tienen acceso a las mismas herramientas y datos que tendría un desarrollador?
- ¿Los agentes pueden encontrar skills que documenten cómo trabajan realmente tus desarrolladores?
- ¿Los agentes pueden probar y verificar los flujos de trabajo principales?
Si necesitas ayuda para preparar tu entorno, contáctanos.
También puedes leer cómo Faire duplicó el rendimiento semanal de PR con Cloud Agents.
