Cómo Cursor creó en tres días y por 180 dólares un prototipo que dividió a un equipo de desarrollo

En una gran empresa de TI, un experimento con Cursor se convirtió pronto en una disputa sobre qué importa más: la velocidad de entrega o la mantenibilidad del código. Un arquitecto de sistemas gastó 180 dólares en tres días y mostró al negocio un resultado clicable, mientras el equipo pasó tres meses construyendo un módulo tipado y cubierto por pruebas.

Tres días contra tres meses

Todo empezó como un piloto corriente de una herramienta de IA. El equipo tenía cinco desarrolladores y la empresa aceptó reembolsar a cada uno una suscripción a Cursor de 20 dólares al mes. Al cabo de un mes, las cifras parecían tranquilas: tres empleados habían gastado 60 dólares en conjunto. Pero luego se supo que el arquitecto de sistemas había consumido 180 dólares en solo tres días.

Usó el modo Agent, cargó en el editor una maqueta de Figma, un componente antiguo y un prompt de texto, y después casi no escribió código a mano. Cursor generaba las interfaces, leía los errores del terminal, los corregía y volvía a lanzar la compilación.

En el otro extremo estaba el equipo, que durante tres meses construyó su módulo con las reglas clásicas. Tenían TypeScript, code review, Storybook, JSDoc y unas 300 pruebas unitarias con una cobertura de al menos el 85 %. En el mismo tiempo, el arquitecto obtuvo un prototipo clicable con más funciones, pero en Vanilla JS y con unas cinco pruebas.

Cuando pusieron ambas versiones una junto a otra, el negocio no vio disciplina de desarrollo, sino dos ritmos de entrega distintos: lento y fiable frente a rápido y vistoso.

Por qué ganó el prototipo

La decisión se tomó en una reunión con analistas de negocio y directivos. Para el equipo de ingeniería, su versión era madura: encajaba con el stack y los estándares y cualquier desarrollador podía mantenerla. Pero para el negocio fue decisivo otro criterio: un resultado visible ya.

El prototipo del arquitecto se podía clicar, desplazar y presentar como un producto casi terminado. El módulo del equipo era mejor por dentro, pero por fuera impresionaba menos, porque la mayor parte del esfuerzo se había ido en los cimientos y no en funciones de demostración.

«Las pruebas se pueden añadir después; el mercado no va a esperar».

Esa lógica fue el punto de ruptura. El equipo no quiso trasladar su trabajo a la solución del arquitecto: otro stack, casi nada de documentación y demasiado pocas comprobaciones. El arquitecto, por su parte, pensaba que sus colegas complicaban el proceso y perdían tiempo cuando ya existía una versión funcional.

Como resultado, un mismo proyecto tiene ahora dos soluciones paralelas para la misma tarea. Sobre el papel hay progreso, pero la empresa ya no tiene una arquitectura única, sino un conflicto entre velocidad, estándares y responsabilidad sobre el mantenimiento futuro.

La cara oculta de la velocidad de la IA

El principal riesgo de esta historia no es solo la deuda técnica, sino lo que los autores llaman deuda de IA. Con las prisas habituales, el equipo al menos sabe qué tendrá que reescribir más adelante. Aquí el problema es más profundo: el código se genera tan rápido que su propio autor puede no entender los detalles de la implementación. Si más tarde aparece un error o cambia una regla de negocio, habrá que volver a delegar el mantenimiento en el modelo, con la esperanza de que reconstruya bien el contexto y no empiece a alucinar sobre código ya generado.

• No hay un stack ni una tipificación comunes con los que cuente el equipo
• Casi no hay pruebas ni documentación, así que los cambios son menos predecibles
• El bus factor tiende a uno: el mantenimiento depende de un solo autor y de la misma herramienta
• Cualquier requisito nuevo aumenta el riesgo de romper código que nadie entiende del todo

Los autores del caso no piden prohibir Cursor. Su conclusión es práctica: el problema no es la herramienta, sino la falta de reglas antes de empezar. Si el equipo hubiera fijado de antemano un stack obligatorio, un mínimo de pruebas y un formato de revisión para el código generado por IA, la disputa podría no haber surgido. Cursor puede servir para acelerar la búsqueda de soluciones, los borradores y los prototipos, pero no para sustituir el pensamiento de ingeniería. De lo contrario, el desarrollador deja de escribir un sistema y se dedica a ver cómo el sistema se escribe solo.

Qué significa

La historia de Cursor muestra que la IA ya no cambia solo la velocidad del desarrollo, sino también la política interna de los equipos. En estas disputas no ganará quien tenga el modelo más potente, sino quien antes acuerde los límites: dónde vale un prototipo rápido y dónde un código sin pruebas, sin tipificación y sin un stack común simplemente no puede darse por terminado.