Para devs de Cursor viendo un buen repo pudrirse
Cursor no escribió spaghetti.
Erosionó tu arquitectura, sesión a sesión.
Tu repo antes tenía una forma. Después, cien sesiones de agente hicieron cada una elecciones localmente razonables — un helper acá, una query inline allá, un patrón de los defaults del modelo en vez de los tuyos — y la forma se disolvió. Eso es erosión, no explosión, y promptear "seguí los patrones existentes" nunca la frenó. useDeploy la frena estructuralmente: fronteras que el agente físicamente no puede cruzar, contratos que CI no deja driftear, y un loop de validación que convierte las malas ediciones en builds rojos.
Context rot: por qué un buen repo se degrada de a una sesión
El mecanismo ya está bien documentado, y no es un bug de Cursor — es lo que pasa cuando muchas ediciones chicas y confiadas se acumulan sin un contrapeso estructural. En cada sesión, el agente ve una porción de tu repo y edita racionalmente contra esa porción. Multiplicá por cien sesiones y la forma del proyecto driftea hacia los defaults de la IA — elecciones razonables en aislamiento, apiladas en algo que nadie habría diseñado. Tampoco hay auto-consistencia a la que recurrir: el código humano carga patrones contra los que podés refactorizar, mientras que el código de un LLM "no tiene nada de eso, y si lo tiene es de pura casualidad y no se repite" (news.ycombinator.com). Y la erosión desemboca en el doom loop: pasado cierto tamaño, la IA que lo construyó ya no puede refactorizarlo de forma confiable: el codebase superó la context window efectiva del modelo (morphllm.com). Los rules files lo frenan un poco. Pero las reglas son prosa, y la prosa es consultiva — lo que aguanta, a largo plazo, es lo que hace fallar el build.
Síntomas de erosión en un repo que era limpio
Tres patrones para todo
Tu repo tenía una manera de fetchear datos; ahora tiene la tuya, la del modelo de 2023 y la del modelo de 2025. El código nuevo copia la que el agente vio última.
La capa de servicios está goteando
Atajos de agente: controllers llamando a la base directo "solo por esta vez" — multiplicado por cuarenta. Cada uno razonable; la suma es pérdida de arquitectura.
Ediciones confiadas, bajas invisibles
El agente arregla el archivo que ve y rompe el caller que no ve. Te enterás por un usuario, no por un check.
Tus convenciones se volvieron sugerencias
Los rules files se obedecen cuando conviene. Nada falla cuando se ignoran, así que las violaciones sobreviven el review y se vuelven precedente.
Te agarró fatiga de review
Dejaste de leer cada diff hace meses. La entropía se acumula justo donde la atención aflojó — la confianza del agente nunca bajó, pero tu escrutinio sí.
Los refactors se siguen pateando
"La deuda técnica no se paga, se le sigue sumando" (news.ycombinator.com) — y cada sesión suma intereses mientras la limpieza queda siempre a un sprint de distancia.
La pared: la edición que el agente no puede hacer
Los rules files piden; los linters se niegan. En useDeploy el layering es flat-config de ESLint, así que el hábito más dañino del agente — cruzar capas porque no ve para qué existe la capa — choca contra una pared que rompe el build. El feedback loop incluso mejora al agente: un error de lint con nombre es una instrucción más clara que cualquier párrafo de convenciones, así que los reintentos convergen al patrón correcto en vez de driftear alrededor.
1 ● Agent: "I'll query Prisma directly from the
2 Subscription entity to save a round-trip."
3
4 + import { PrismaClient } from '@prisma/client'
5 // modules/billing/domain/subscription.ts
6
7 $ bun run lint
8
9 modules/billing/domain/subscription.ts
10 error domain/ may not import '@prisma/client'
11 ddd-boundaries/no-infra-in-domain
12
13 ✖ Build fails. The edit never lands.
14 ● Agent retries — through the repository port.
Un harness, no solo un starter
Blast radius acotado
Seis bounded contexts — iam, tenancy, billing, storage, ai, webhooks — hacen que una sesión de agente scopeada a billing físicamente no pueda reformar auth. Las porciones chicas se quedan chicas.
Fronteras como builds que fallan
El layering DDD es flat-config de ESLint, no una página de wiki: código de domain que importa express, @prisma/client o infraestructura mata el build. El atajo cross-capa no tiene dónde aterrizar.
Contratos a prueba de drift
Schemas Zod en @app/contracts, un cliente tipado por openapi-fetch y el gate de CI api-types-fresh: cuando una edición cambia lo que devuelve un endpoint, el merge se bloquea hasta que ambos lados vuelvan a acordar. Payload drift atrapado — no solo type drift.
Un loop de validación en el que el agente puede confiar
450+ tests y un gate E2E de Playwright le dan al agente algo real contra qué auto-chequearse — cerrando el loop code → validate → code en vez de declarar éxito.
Side effects detrás de un outbox
El event bus persiste a un outbox durable, así que un agente que agrega una feature nunca necesita meter inline un envío de email o una llamada de webhook en un handler — el atajo tentador no existe.
Un CLAUDE.md operativo
El rules file del repo no es prosa aspiracional — codifica las mismas fronteras que enforza el linter, junto a docs de arquitectura en /docs. Lo que el agente lee y lo que CI chequea coinciden.
El camino de migración: módulos primero, después strangler-fig
Un repo erosionado no se arregla con un refactor heroico — la erosión pasó porque nada era modular, así que los módulos tienen que venir primero. Levantá useDeploy al lado de tu repo. Las capas commodity — auth, orgs, billing, storage — ya están construidas y testeadas ahí, lo que significa que tus versiones erosionadas se borran, no se restauran; eso solo ya remueve una parte enorme de la entropía. Después migrá estilo strangler-fig, de a un dominio: apuntá Cursor a la base nueva, decile que porte la lógica de pricing (o proyectos, o notificaciones), y dejá que el lint de fronteras, el gate api-types-fresh y la suite de tests hagan el trabajo de reviewer agotado que venías haciendo a mano. El agente que erosionó tu repo viejo es genuinamente bueno en este trabajo cuando el destino tiene paredes — un error de lint con nombre le enseña más rápido que cualquier doc de convenciones. Estado final: mismo producto, mismo editor, mismo workflow. Pero el drift ahora muere en CI, en segundos, en vez de acumularse hasta volverse arquitectura.
Preguntas que hacen los devs de Cursor
¿No alcanza con un rules file?+
¿Tengo que cambiar mi forma de trabajar?+
Mi repo no está tan perdido. ¿Migro o arreglo in place?+
¿El agente no va a pelearse con el linter?+
Una licencia. Dos formas de tenerla.
CORE
Founder
Un snapshot congelado de UseDeploy. Tuyo para siempre, sin updates.
- Descarga del zip con versión frozen
- Código completo, uso comercial, proyectos ilimitados
- Los 800+ tests · todas las páginas de docs
- Refund a 14 días
LATEST + UPDATES
Lifetime
Siempre el último UseDeploy. Re-descargá cada release, gratis.
- Zip de la última versión — re-descargable para siempre
- Cada release futuro sin cargo extra
- Soporte Discord priority
- Los 800+ tests · todas las páginas de docs
- Refund a 14 días
Apuntá tu agente a una base que no puede erosionar
Mismo workflow de Cursor, otra física: fronteras enforzadas por ESLint, contratos a prueba de drift y un harness de CI que convierte las malas ediciones en builds rojos en vez de arquitectura.