Nos pasó en febrero de este año. Tres personas del equipo, una tarde libre y la idea de que podíamos levantar un MVP funcional antes de cenar usando solo Cursor para prototipar. Y lo que descubrimos esa noche nos obligó a replantear cómo medimos la productividad real de un editor con IA cuando el trabajo deja de ser un juguete, y sobre todo a entender, con cursor para prototipar dónde está el límite real antes de que el código se vuelva inmanejable.

Lo que sigue no es una reseña. Es el registro de tres experimentos con métricas propias: cuántas líneas generamos, cuántas tuvimos que tirar, en qué momento exacto el asistente empezó a contradecirse y qué porcentaje de ese código sobrevivió al despliegue. Si buscas un tutorial de instalación, este no es tu sitio.

La hipótesis de partida: un MVP funcional en una tarde

Nuestra hipótesis era concreta y medible: cuatro horas bastan para entregar una aplicación con autenticación, base de datos, dos vistas y un panel básico. Nada de escalabilidad. Nada de tests. Solo algo que un cliente pueda tocar en una demo.

¿Por qué cuatro horas? Porque es el tiempo que un equipo pequeño puede regalar sin facturar. Si la herramienta no cabe en ese presupuesto temporal, su utilidad comercial es discutible. Medimos tres variables desde el minuto uno: tiempo hasta primer despliegue, número de correcciones manuales y porcentaje de ficheros que tocamos más de dos veces.

¿Hasta qué punto se puede construir sin escribir código?

Se puede llegar a una aplicación desplegada y navegable sin teclear una línea, siempre que el alcance quepa por debajo de la veintena de ficheros. A partir de ahí la intervención humana deja de ser opcional: no para corregir sintaxis, sino para sostener la coherencia entre piezas que el modelo ya no ve a la vez.

Cómo montamos la prueba: tres casos, tres niveles de ambición

Elegimos tres casos deliberadamente desiguales. El primero, un gestor de reservas para una peluquería: cuatro tablas, un formulario, un calendario. El segundo, una plataforma de suscripciones con pasarela de pago y roles diferenciados. El tercero, un agregador de datos con procesamiento en background y colas.

Proyecto A: el que salió redondo

El gestor de reservas estuvo desplegado en 2 horas y 40 minutos. Dieciséis archivos, 1.340 líneas, tres correcciones manuales. El asistente acertó incluso con el esquema de la base de datos a la primera, algo que nos sorprendió porque normalmente las relaciones muchos-a-muchos las resuelve de forma torpe.

Total, que la hipótesis se cumplió con holgura. Y nos confiamos.

Proyecto B: donde empezó la fricción

La plataforma de suscripciones nos llevó 6 horas y 15 minutos repartidas en dos sesiones. Cuarenta y un archivos. Y aquí apareció el primer síntoma serio: el editor generaba lógica de permisos que contradecía la que él mismo había escrito cuarenta minutos antes, en otro fichero. No porque el modelo sea malo, sino porque dejó de ver ese fichero.

Proyecto C: el que no terminamos esa tarde

Si tuviéramos que resumir el agregador de datos en una frase: once horas, ochenta y tres archivos, y una reescritura completa del módulo de colas a mano. Ahí dejamos de medir productividad y empezamos a medir daños.

Qué ocurrió cuando el repositorio pasó de 20 a 80 archivos

Aquí está el quid de todo el experimento, y es el dato que menos se cuenta por ahí.

Por debajo de veinte ficheros, el asistente mantiene una representación mental coherente del conjunto. Lo notas: recuerda nombres de funciones, respeta convenciones que estableciste hace una hora, no duplica utilidades. Entre veinte y cuarenta, la coherencia se degrada pero sigue siendo gestionable si eres disciplinado señalando contexto manualmente.

¿Y por encima de cincuenta? Empieza a inventar. No inventa sintaxis: inventa tu código. Nos generó tres veces una función llamada formatCurrency en tres ubicaciones distintas, con tres firmas incompatibles. Cada una funcionaba. Juntas, rompían el checkout.

La degradación no es lineal

Creíamos que la pérdida de calidad sería progresiva, una curva suave. Medimos esperando eso. Lo que encontramos fue un escalón: entre el archivo 45 y el 55, la tasa de correcciones manuales por cada 100 líneas generadas saltó de 4,1 a 13,8. Más del triple en una franja estrecha. Cambiamos nuestra forma de planificar a raíz de ese número.

La explicación probable tiene que ver con cómo se selecciona el contexto que se envía al modelo. Cuando el repositorio supera cierto volumen, la selección automática deja de incluir los ficheros relevantes y pasa a incluir los ficheros cercanos. Que no es lo mismo.

Qué pasa si el repositorio ya existía antes que tú

Los tres casos eran de obra nueva. Cuando aplicamos el mismo método sobre un código heredado de un cliente, con 60 ficheros ya escritos y convenciones internas que nadie había documentado, el techo bajó: el asistente empezó a inventar utilidades duplicadas alrededor del archivo 30, no del 50. (Tiene sentido: la mitad del presupuesto de contexto se va en entender lo que ya estaba ahí.) Si trabajas sobre legacy, divide nuestras cifras entre dos y acertarás más que nosotros.

Los datos: velocidad real, errores introducidos y retrabajo

Vamos con los números completos, porque las impresiones sin métricas no sirven de nada.

Velocidad bruta de generación: entre 180 y 240 líneas útiles por hora en el caso A, frente a las 60-75 líneas por hora que produce uno de nosotros escribiendo a mano código equivalente. Tres veces más rápido. Ese dato es el que circula en LinkedIn y es cierto.

Pero el agregador generó 4.800 líneas y conservamos 2.900 tras la limpieza. Un 39,6% de descarte. Sumando las horas de revisión, la ventaja de velocidad cayó al 1,4x. Sigue siendo ventaja. No es la que te venden.

Caso	Líneas generadas	Tiempo total	Correcciones / 100 líneas	% reutilizable a 3 meses
A · Gestor de reservas (16 archivos)	1.340	2 h 40 min	4,1	71%
B · Plataforma de suscripciones (41 archivos)	4.260	6 h 15 min	≈8 (valor interpolado)	44%
C · Agregador con colas (83 archivos)	4.800	11 h	13,8	18%

Errores introducidos por categoría

• Dependencias fantasma: 11 casos
• Lógica duplicada en ficheros distintos: 9 casos
• Manejo de errores omitido: 23 casos
• Variables de entorno inventadas: 6 casos
• Consultas N+1 a base de datos: 14 casos

Las consultas N+1 nos preocuparon especialmente. Funcionan perfectamente con cinco registros de prueba y hunden la aplicación con tráfico real, que es exactamente el patrón que describimos cuando analizamos las apps de Lovable que se caen con cincuenta usuarios concurrentes, y que se repite con cualquier generador asistido que optimice por «esto compila» en lugar de por «esto aguanta».

El coste oculto de revisar

Medimos también algo que casi nadie mide: el tiempo de lectura. Revisar 500 líneas ajenas cuesta más que escribir 300 propias. En la plataforma de suscripciones dedicamos 2 horas y 10 minutos solo a leer y entender código que habíamos «generado en veinte minutos».

El manejo de errores omitido (23 casos) fue el apartado más caro de arreglar: 3 horas y 45 minutos acumuladas entre los tres casos. El asistente escribe el camino feliz con una fluidez notable y asume que nunca falla la red.

Lo que no se ve hasta que alguien lo busca

Un apunte incómodo que no estaba en nuestro plan de medición: ninguno de los 6 casos de variables de entorno inventadas venía con validación, y en dos ocasiones el código generado dejó credenciales de prueba escritas directamente en el fichero. No es malicia del modelo, es que nadie le pidió lo contrario. (Nosotros tampoco, para ser justos.) Promover un prototipo a producción sin una revisión de seguridad específica es la forma más silenciosa de heredar deuda técnica.

El punto exacto en que la herramienta deja de escalar

El límite práctico se sitúa en torno a 50 archivos o 4.000 líneas, lo que llegue primero. Por debajo de ese umbral el asistente mantiene coherencia entre ficheros y actúa como multiplicador de velocidad. Por encima, la selección automática de contexto falla y la tasa de correcciones manuales se triplica: de 4,1 a 13,8 por cada 100 líneas generadas en nuestras mediciones.

No es un número mágico ni universal. Depende del lenguaje, de lo acopladas que estén las piezas y de cuánta disciplina tengas fijando contexto. Pero en nuestras tres pruebas el comportamiento fue consistente: por debajo de ese techo tienes un acelerador; por encima, un generador de deuda técnica muy convincente.

Las tres señales de alarma

Antes de llegar a contar archivos, hay síntomas más tempranos y más fiables. El primero: el asistente te propone crear un fichero que ya existe. El segundo: ignora una convención de nombres que aplicó correctamente durante dos horas. El tercero, el definitivo, es cuando te pide que le pegues el contenido de un archivo que está abierto en la pestaña de al lado.

Cuando aparece la tercera señal, nosotros paramos. Y dividimos el trabajo o cambiamos de modo.

¿Y el Modo Max, cuándo compensa?

La documentación oficial lo describe como una ventana de contexto ampliada que consume una porción mayor del límite de solicitudes, recomendada solo para tareas complejas. No lo medimos nosotros, así que lo damos como dato de fuente y no como hallazgo propio. En la práctica funciona como un parche al problema de contexto: amplía el techo, no lo elimina.

Planificar con el modelo caro y ejecutar con el barato

Esto lo descubrimos por tacañería, no por inteligencia.

En la segunda sesión del agregador nos habíamos pulido el presupuesto de tokens del mes. Nos obligamos a usar el modelo potente solo para decidir arquitectura, qué ficheros crear, qué responsabilidad tiene cada uno y qué interfaces exponen, dejando el modelo económico para rellenar cada pieza una vez definida.

El resultado fue mejor que trabajar siempre con el caro. Un 31% menos de correcciones manuales respecto a la sesión anterior del mismo caso. Y resulta que no inventamos nada: el propio equipo de la herramienta ha documentado ese mismo reparto de roles, un modelo de frontera que planifica, modelos baratos que ejecutan, como vía para reducir conflictos, volumen de código generado y coste. Nosotros llegamos ahí por no poder pagar la factura.

La razón nos parece evidente a posteriori: al forzar una fase de planificación explícita, el contexto que cada petición necesita se reduce drásticamente. Ya no le pides «añade pagos a esta app», le pides «escribe esta función con esta firma que hace esto».

¿Qué es el Modo Plan y cuándo conviene usarlo?

Es una fase previa en la que coescribes con el modelo una especificación en Markdown antes de que se genere una sola línea de código. Conviene cuando el alcance supera la treintena de ficheros o toca varias capas a la vez. La propia documentación advierte de que en tareas pequeñas resulta contraproducente, aunque no cuantifica a partir de dónde; nuestras mediciones sugieren que ese punto está cerca de los 30 archivos.

El conflicto que nadie resuelve

Hay dos relatos incompatibles circulando. Uno dice que el modo agente autónomo es una trampa de calidad. El otro presenta enjambres de agentes reconstruyendo SQLite en Rust y superando el 100% del conjunto de pruebas evaluado, con una capa de coordinación propia que sustituye a Git para evitar el cuello de botella entre agentes paralelos. Ambos relatos son ciertos, y la diferencia está exactamente donde apuntan nuestros datos: en si existe o no una fase de planificación antes de soltar al agente.

Cómo lo aplicamos ahora

Media hora larga de conversación con el modelo bueno, sin escribir una línea, produciendo un documento de arquitectura en texto plano. Después, sesiones cortas de ejecución fichero a fichero. ¿Es más lento al principio? Bastante. ¿Compensa? Por encima de treinta archivos, siempre. Por debajo, no notamos diferencia y probablemente sea sobreingeniería de nuestro propio proceso.

Qué parte del prototipo sobrevive al salto a producción

Llevamos los tres desarrollos a producción en abril y mayo. Medimos cuántas líneas del original seguían vivas tres meses después.

Caso A: 71% de supervivencia. Caso B: 44%. Caso C: 18%. La correlación con el tamaño inicial del repositorio es casi perfecta, y nos resultó más brutal de lo esperado.

Lo que sobrevive siempre

Las vistas de interfaz, los formularios y las validaciones de cliente aguantan prácticamente intactos. También los esquemas de base de datos sencillos. Son capas donde la corrección es verificable de un vistazo y donde un error no se propaga.

Lo que no sobrevive nunca

Todo lo que toque concurrencia, transacciones, gestión de estado compartido o permisos. En la plataforma de suscripciones reescribimos el sistema de roles tres veces antes de aceptar que había que diseñarlo a mano desde cero. Perdimos nueve días por no admitirlo antes.

Esa es, al final, la lección que llevamos a cada cliente cuando acompañamos la transición de MVP a SaaS: el código generado es excelente para validar una idea con usuarios reales y pésimo como cimiento de un producto que va a cobrar dinero todos los meses.

Lo que haríamos distinto en el próximo experimento

Tres cosas, y ninguna tiene que ver con la herramienta.

Primera: mediríamos desde el inicio el tiempo de lectura separado del tiempo de generación. Lo añadimos a mitad del segundo caso y los datos del primero quedaron incompletos. (Sí, publicamos igualmente una tabla con un valor interpolado; preferimos decirlo a disimularlo.)

Segunda: fijaríamos un tope duro de archivos por módulo antes de empezar, en lugar de descubrir el techo chocando contra él. Tercera: probaríamos el mismo método en un lenguaje con tipado estricto, porque sospechamos que el compilador habría cazado buena parte de esos 11 casos de dependencias fantasma.

¿Nuestra conclusión sobre usar Cursor para prototipar? Funciona extraordinariamente bien dentro de su marco: menos de cincuenta ficheros, validación rápida, nada que vaya a sostener dinero real. Fuera de ese perímetro, el retrabajo se come la ventaja y lo hace sin avisar. Conocer dónde está ese límite vale más que cualquier truco de prompting.

En la siguiente tanda queremos medir el escenario inverso: partir de una arquitectura escrita a mano y usar la generación asistida solo para rellenar implementaciones. Si los números acompañan, lo publicamos igual que estos.