Los agentes de programación siempre activos de Cursor ya están aquí. ¿Están sus equipos preparados?
La novedad
El jueves, Cursor presentó una funcionalidad llamada Automations. En pocas palabras: en lugar de que un desarrollador tenga que indicarle algo a un agente de IA cada vez que necesita realizar una tarea, Automations permite definir disparadores (un nuevo commit, un mensaje de Slack, una alerta de PagerDuty, un temporizador) que lanzan agentes de forma autónoma. Los agentes trabajan por su cuenta y solo llaman a una persona cuando se topan con algo que requiere criterio humano.
Jonas Nelle, responsable de ingeniería de Cursor, lo expresó con claridad: los ingenieros «no siempre son quienes inician el proceso. Se les llama en los momentos adecuados dentro de esta cadena de producción». La empresa afirma que ya ejecuta cientos de estas automatizaciones por hora en su propio código, gestionando desde la detección de errores hasta la respuesta a incidentes y los resúmenes semanales de cambios publicados en Slack.
Las cifras que respaldan esto son difíciles de ignorar. Bloomberg informó esta semana que los ingresos anualizados de Cursor han superado los 2.000 millones de dólares, duplicándose en aproximadamente tres meses. La empresa acumula alrededor del 25% de cuota de mercado entre los suscriptores de herramientas de IA generativa.
Por qué esto importa más de lo que parece
A primera vista, esto parece una simple mejora en el flujo de trabajo. Se define un disparador y se deja que un agente lo gestione. Interesante. Pero si se analiza con más detenimiento, lo que Cursor está haciendo en realidad es convertir el asistente de programación con IA en infraestructura. No es una herramienta que se abre y se usa, sino un sistema que funciona de manera continua.
Esto representa un cambio significativo. Hemos pasado del «autocompletado en el editor» a «procesos en segundo plano que hacen commits, revisan PRs, analizan problemas de seguridad y responden a incidentes en producción mientras usted duerme». Y todo esto en aproximadamente dos años.
Sigo volviendo al problema de la atención. Un desarrollador que gestiona decenas de agentes a la vez no puede revisar nada con detenimiento real: simplemente da el visto bueno sin más. Automations intenta resolver esto siendo selectivo sobre cuándo solicitar la intervención humana. Es un buen enfoque de diseño, pero también implica que la calidad del criterio de la automatización pasa a ser crítica. Si decide que algo no necesita revisión humana y se equivoca, nadie lo detecta.
Lo que observamos en la práctica
A través de nuestro trabajo de desarrollo web y de APIs, hemos seguido cómo ha evolucionado la conversación sobre herramientas de IA durante el último año. Al principio, los clientes querían saber si la IA podía acelerar el desarrollo de funcionalidades. Ahora las preguntas son distintas: ¿cómo controlamos lo que hacen los agentes de IA en nuestros repositorios? ¿Quién es responsable cuando un PR automatizado introduce una regresión? ¿Cómo auditamos esto?
No son preguntas hipotéticas. En nuestro trabajo con clientes empresariales, especialmente aquellos sujetos a los requisitos de cumplimiento suizos, «lo hizo un agente de IA» no es una respuesta aceptable cuando algo sale mal. Se necesita trazabilidad. Es necesario saber qué agente se ejecutó, qué cambió, por qué y quién lo aprobó.
El framework de Automations de Cursor parece entender esto, al menos en parte. La integración con PagerDuty, por ejemplo, consulta los registros a través de conexiones MCP y construye una línea de tiempo antes de proponer una solución. Es una especie de rastro de auditoría. Pero «una especie de» no es suficiente para entornos regulados.
El ángulo de seguridad del que nadie habla
Esto es lo que genuinamente me preocupa. En nuestros trabajos de pruebas de penetración con estudios de videojuegos y plataformas empresariales, uno de los vectores de ataque más comunes que encontramos son los procesos automatizados con permisos excesivos: pipelines de CI/CD que pueden desplegar en producción, cuentas de servicio con acceso de administrador que nadie ha revisado en dos años.
Los agentes de programación siempre activos representan el mismo tipo de riesgo, pero con mayor autonomía. Un agente que puede leer su código, consultar sus registros de producción a través de Datadog, abrir PRs y activar despliegues es un objetivo enormemente atractivo. Si un atacante compromete el mecanismo disparador (por ejemplo, mediante un mensaje de Slack manipulado), potencialmente obtiene acceso a nivel de agente a todo su flujo de trabajo de desarrollo.
Automations de Cursor actualmente se activa mediante mensajes de Slack, cambios en el código y alertas de PagerDuty. Cada uno de esos elementos es una superficie de ataque. Cuando configuramos herramientas como Cloudflare o Akamai para protección contra DDoS, siempre mapeamos la cadena completa de sistemas automatizados que pueden modificar el estado en producción. Los agentes de programación con IA ahora forman parte de ese mapa.
Qué debería hacer ahora mismo
Si su equipo está utilizando o evaluando herramientas de programación con IA que incluyen funciones de automatización, estos son los aspectos concretos que debe abordar esta semana:
Haga un inventario de los permisos de sus agentes. ¿Qué puede leer, escribir y ejecutar cada agente? Trátelo igual que trataría una auditoría de cuentas de servicio. Si un agente puede abrir PRs y consultar registros de producción, necesita el mismo escrutinio de seguridad que cualquier herramienta de despliegue automatizado.
Defina su política de supervisión humana antes de necesitarla. No deje que la herramienta decida qué es suficientemente importante para que lo vea una persona. Su equipo debe definir ese umbral en función del riesgo: todo lo que afecte a la autenticación, los pagos, la configuración de infraestructura o los datos de usuarios requiere revisión humana. Sin excepciones.
Registre absolutamente todo. Si está ejecutando agentes que realizan cambios de forma autónoma, necesita registros inmutables de qué se activó, qué cambió y qué se aprobó (y por quién). En nuestro trabajo desarrollando aplicaciones cloud-native para clientes empresariales, integramos esto en el pipeline de CI/CD desde el primer día. Si lo añade después, encontrará lagunas que habrá pasado por alto.
Trate las integraciones de agentes como parte de su modelo de amenazas. Si realiza algún tipo de revisión de seguridad o prueba de penetración, incluya las configuraciones de sus agentes de IA. En nuestros proyectos nativos de iOS y Android, hemos visto equipos que blindan la seguridad de su aplicación móvil mientras dejan su cadena de herramientas de desarrollo completamente expuesta. El mismo principio aplica aquí.
El panorama general
El espacio de la programación agéntica avanza rápido. Los dos principales laboratorios de IA han lanzado funcionalidades competidoras en el último mes, y la dirección está clara: las herramientas de programación quieren estar siempre activas, ser autónomas y estar profundamente integradas en su stack.
Probablemente hacia ahí se dirigen las cosas. No sugiero que los equipos eviten estas herramientas. Nosotros mismos usamos desarrollo asistido por IA, y las ganancias de productividad en código repetitivo, scaffolding de pruebas y refactorizaciones rutinarias son reales.
Pero hay una diferencia entre usar herramientas de IA y dejar que las herramientas de IA gestionen su proceso de desarrollo sin supervisión. La línea entre ambas acaba de volverse más difusa. Los equipos que traten a sus agentes de IA con el mismo rigor que aplican a cualquier otro sistema automatizado con acceso a producción estarán bien. Los que no lo hagan aprenderán la lección de la manera más difícil.
Ya hemos visto este patrón antes. Cuando los pipelines de CI/CD se generalizaron, los equipos que los trataron como infraestructura crítica para la seguridad desde el primer día evitaron las brechas que golpearon a todos los demás años después. Los agentes de programación con IA se encuentran ahora en ese mismo punto de inflexión.
Si gestionar las herramientas de IA en su equipo de desarrollo es su dolor de cabeza actual, hablemos.