Los 5 doom loops de Cursor que te queman USD 500/día

Pedís a Cursor que arregle un bug. Tres horas después: USD 89 facturados en tokens, y el bug sigue exactamente en el mismo lugar.

Las herramientas de generación de código parecen mágicas los primeros días. Le tirás un prompt a Cursor, Claude Code, Cline, Aider o Lovable, y en diez segundos tenés un módulo entero funcionando. Pero esa velocidad tiene un lado oscuro: cuando el modelo de lenguaje (LLM) pierde el hilo, lo hace a la misma velocidad. Entrás en un bucle donde la IA intenta arreglar su propio error, rompe otra cosa, vuelve al estado inicial y te cobra financieramente por cada intento inútil.

Cada uno de estos bucles te puede costar entre USD 50 y USD 200 en consumo de tokens, sumado a la frustración y el tiempo perdido. En un solo día de estar atrapado en uno de estos ciclos, podés quemar fácilmente entre USD 300 y USD 500 sin subir una sola línea de código estable a producción.

La anatomía del desastre automatizado

Hace poco leía a Stephan Schmidt, que categorizó muy bien este problema en su artículo "Why AIs Struggle With Coding". Haciendo sparring técnico real todas las semanas con founders, tomé esa base y adapté los patrones a los casos concretos que hoy están frenando en seco a quienes arman SaaS.

La máquina no se cansa, pero tampoco razona. Si no aprendés a identificar el momento exacto en el que el modelo de lenguaje deja de avanzar y empieza a patinar en el barro, vas a seguir quemando plata.

Los 5 doom loops que aprendí a reconocer

1. Loop del estado distribuido

El bug no está en un solo archivo, sino en cómo interactúan tres archivos distintos en tu arquitectura. El problema es que la IA tiende a mirar de a un archivo a la vez. Te propone una solución modificando el archivo A, pero eso rompe la lógica en el archivo B. Le pegás el nuevo error, arregla el B, pero rompe el C. Se disculpa, toca el C, y vuelve a romper el A. Estás en un loop infinito.

El fix: Tenés que darle los tres archivos de una sola vez en el mismo prompt para que entienda el estado distribuido. Si el contexto es muy grande y se marea, frená el código y pedile primero que te dibuje un mapa de cómo interactúan. Recién cuando el mapa sea correcto, le pedís el código.

2. Loop del framework version mismatch

Tu proyecto, por ejemplo, está en Next.js 14. Los datos de entrenamiento más fuertes de la IA o su memoria de la documentación asumen que estás en Next.js 15. Le pedís un feature y te propone consumir una API que no existe en tu versión. Vos confiás, le das a aceptar. El compilador explota. Le pasás el error de la terminal, la IA te pide perdón y te da otra solución... usando otra función exclusiva de la versión 15.

El fix: Pasale el package.json al principio de la sesión. Si el LLM es terco, usá el protocolo MCP (Model Context Protocol) con documentaciones actualizadas, como Context7, para inyectarle las reglas de tu versión exacta.

3. Loop del type narrowing

Estás trabajando con TypeScript. El compilador te tira un error de tipos complejo que frena el build. La IA intenta arreglar las interfaces un par de veces, falla, se frustra algorítmicamente y decide tomar la salida fácil: te escribe un as any. Resolvió el error de la terminal, pero no resolvió tu bug. El sistema va a explotar en tiempo de ejecución, le vas a pasar el nuevo error y el ciclo vuelve a arrancar.

El fix: NO aceptes jamás un as any generado por un agente. Es la bandera roja definitiva de que el modelo no entiende el flujo de tus datos. Rechazá el cambio y exigile que analice los tipos reales.

4. Loop del side effect oculto

Le pediste un fix hiper puntual para un componente visual. La IA te arregla eso, pero de paso decide que un useEffect que andaba por ahí abajo le parecía feo y lo reescribe "para optimizar". Acaba de introducir un side effect oculto que rompe la carga de datos principal. Vos le diste a aceptar porque solo estabas mirando el fix visual.

El fix: Siempre usá la vista de diff o un comando --dry-run. Rechazá sistemáticamente cualquier línea de código modificada que caiga fuera del scope estricto que le pediste.

5. Loop del test que pasa pero no testea nada

Para salir de dudas, le pedís a la IA que escriba tests unitarios para validar que arregló el bug. Corrés la suite y la terminal da verde. Vas a producción y el bug sigue ahí. Cuando entrás a revisar el archivo del test, descubrís que la IA escribió una prueba que solo verifica si la función existe (expect(function).toBeDefined()), pero no testea el comportamiento, ni el retorno, ni los casos límite.

El fix: Leé el test antes de aceptarlo. Si el test no valida el comportamiento real que vos entendés que tiene que tener el sistema, la cobertura verde es una mentira cara.

El criterio técnico sigue siendo tuyo

Quiero dejar algo claro: esto NO es contra los LLMs. La velocidad que te dan es brutal y negarla es una estupidez. Esto es contra la fantasía de que el LLM siempre tiene razón y de que no hace falta entender lo que está pasando por debajo. Aprender a frenar al LLM cuando patina vale muchísimo más que el LLM mismo.

Llevo casi 40 años escribiendo software. Los bucles de frustración y fricción inútil siempre existieron. Cuando yo arrancaba con Turbo Pascal y un manual en papel, el loop de la muerte era pasar horas esperando entender por qué un puntero mal declarado te colgaba la memoria. Hoy, el loop es delegar ciegamente la lógica en un modelo estadístico y mirar la pantalla mientras la herramienta alucina tres horas con el mismo archivo.

La fricción cambió de lugar, pero el requisito para superarla es el mismo de siempre: oficio.

Cuando alguien contrata mi Mentoría 1:1, el 50% del trabajo es esto: enseñarles a ver los doom loops venir desde lejos antes de quemar tres horas. La velocidad bruta de la IA no sirve absolutamente de nada si te quedás trabado en el mismo día.