Cursor sacó el 29 de junio su app iOS en beta pública, disponible para todos los usuarios de pago. La idea es dejar de mirar al monitor para revisar lo que escriben tus agentes y pasar a supervisarlos desde el móvil mientras haces otra cosa. Llega con un 75% de descuento en runs de Composer 2.5 hasta el 5 de julio.
Qué hace la app
Desde iPhone o iPad puedes arrancar un agente nuevo en la nube de Cursor, eligiendo cualquier modelo frontera (Composer 2.5, Claude, GPT, Gemini), o conectarte a tu Mac vía Remote Control para controlar agentes locales. La interacción es por voz (describir ideas en lenguaje natural) o slash commands para guiar el agente con precisión.
Las notificaciones son la pieza clave. Live Activities en el lock screen muestran el progreso del agente sin abrir la app. Push notifications avisan cuando el agente termina, se atasca esperando una decisión, o deja un pull request preparado. Apruebas, rechazas o ajustas desde el móvil.
El feature más interesante operativamente es el handoff entre entornos. Empiezas un plan desde el móvil en el sofá. Lo mandas a un agente cloud para que tarde lo que tarde compilando, escribiendo tests y ejecutándolos. Vuelves al ordenador, recoges la sesión en local con todo el contexto intacto, ejecutas la batería de tests que requiere acceso a infra interna, y mergeas. Es un modelo asíncrono de desarrollo, no "editor móvil".
Cursor declara que el roadmap va hacia hacer indistinguible correr agentes en cloud o en local. Por ahora la app es solo iOS; no hay fecha para Android, lo que es coherente con la base de usuarios de Cursor (skew muy fuerte a Mac/iPhone).
El contexto: el código se vuelve supervisión
Boris Cherny, lead de Claude Code en Anthropic, lo soltó esta semana: "la mayoría de mi código ahora lo hago desde el móvil. Habría dicho que estás loco si me lo cuentas hace seis meses, pero aquí estamos". No es una boutade. Cuando un agente puede correr 30-45 minutos en una tarea no trivial, lo último que quieres es estar sentado mirando la terminal. Quieres notificación cuando haya algo que decidir y silencio el resto del tiempo.
Cursor llega tarde a móvil pero con dos ventajas. Una, base instalada: probablemente el editor agentic más usado del mundo entre developers profesionales. Dos, respaldo financiero: SpaceX cerró la compra de Anysphere (matriz de Cursor) por 60.000 millones de dólares en stock en junio. Anthropic ya tiene Claude móvil con integración Code, OpenAI lanzó Codex móvil hace semanas, GitHub tiene Copilot mobile en preview. La carrera por el "control remoto del developer" está abierta.
El cambio cultural: del IDE al supervisor
La parte que mucha gente no ha procesado todavía: cuando aprobar o rechazar un diff cuesta dos toques en un móvil, el modelo mental de "desarrollar" cambia. Pasas de escribir código a definir intención, revisar trabajo y dar feedback. Es más parecido a gestionar un equipo junior que a programar.
Eso tiene efectos secundarios. La calidad del code review baja cuando se hace desde un pantalla pequeña entre dos paradas de metro. La fragmentación de atención sube. Pero también desbloquea casos que antes eran impensables: bugs reportados un viernes por la tarde que se arreglan ese mismo sábado por la mañana sin abrir el portátil, refactors largos lanzados antes de cenar y aprobados después.
Por qué importa
Si lideras un equipo técnico en España, esto cambia tu modelo de productividad. Antes un developer estaba "trabajando" cuando tenía el VSCode abierto. Ahora puede tener 3 agentes corriendo en cloud mientras va en metro, y solo necesita responder cuando llega una notificación. La productividad por persona sube, pero también la fragmentación de la atención y la tentación de aprobar trabajo apresurado.
Para founders no técnicos: no es ciencia ficción que tu CTO mergee PRs desde el móvil un sábado. Está pasando ya. Lo importante es ajustar tres cosas. Las expectativas de respuesta (no asumas que cualquier hora es buena; el burnout sigue siendo real). Los flujos de revisión (define qué se aprueba en móvil y qué requiere sesión sentada). Los criterios de calidad (cuando aprobar un diff cuesta dos pulgares, el riesgo de mergear basura sube).
Para un equipo de 10 developers, el ahorro estimado por tener agentes activos fuera del horario sentado puede ser equivalente a 1-2 developers más sin contratar. Para un equipo de 50, hablamos de 8-10 plazas equivalentes. Esa es la magnitud, no "un poco más rápido".
Hay un efecto cultural más sutil. Cuando un PR se aprueba desde el móvil, la trazabilidad de la decisión se degrada (no hay logs de qué archivos abriste, qué tests ejecutaste localmente, qué consideraste). Para equipos en sectores regulados (banca, salud, seguros), esto requiere protocolos explícitos: qué se documenta automáticamente desde la app, qué requiere comentario escrito en el PR, qué se prohíbe directamente. Un CTO español que vende a banco no puede permitirse que un PR de cambio de pricing del motor de scoring se apruebe en 30 segundos desde el metro.
El impacto en contratación también merece atención. Si tu próximo developer puede trabajar productivamente desde el móvil 30-40% del tiempo, el rango geográfico de candidatos se amplía y la presión salarial puede aliviarse marginalmente. A la inversa, los developers senior que adopten este modelo primero van a poder cobrar más por ofrecer disponibilidad asíncrona real, lo que crea estratificación interna nueva.
Qué hacer
- Si tu equipo usa Cursor y tienes plan de pago: instala la app esta semana en una tarea no crítica y mide cuánto tarda en aprobarse un PR comparado con flujo solo desktop. Aprovecha el 75% de descuento de Composer 2.5 antes del 5 de julio (puede bajar el coste por PR de ~3 EUR a 0,75 EUR en pruebas).
- Si lideras desarrollo: redacta hoy una política de 1 página sobre qué tipos de PR pueden aprobarse desde móvil (hotfixes, bumps de dependencias, copy changes) y cuáles requieren revisión sentado (cambios de arquitectura, seguridad, infra). No todo merece el mismo nivel de escrutinio.
- Si eres founder no técnico: pregunta a tu CTO si vuestro stack permite agentes asíncronos largos sin romper builds o tests. Si no, es buen momento para invertir 2-4 semanas de equipo en preparar la base (containers de test estables, datos sintéticos, secrets bien gestionados). Sin esa base, la app móvil queda como gimmick.