Para devs con Cursor

Vos shippeaste las features.
El agente salteó la capa de ops.

Con Cursor la velocidad de features es real: rutas, pantallas y CRUD aterrizan tan rápido como los describís. Lo que no aterriza es el sustrato operacional — webhooks idempotentes, colas con reintentos, sesiones revocables, observabilidad, un gate E2E — porque los agentes generan el promedio del código público, y el promedio incluye los bugs. useDeploy es un backend DDD donde esa capa ya está construida, cubierta por 450+ tests y exigida por lint, para que tu agente siga shippeando rápido sin erosionar la fundación.

Los agentes promedian el training set — y el promedio tiene bugs conocidos

Los reviews de seguridad de código SaaS generado por agentes encuentran las mismas tres fallas una y otra vez: sesiones que sobreviven un cambio de contraseña — reseteás tu contraseña, pero el token viejo sigue funcionando — handlers de webhooks de Stripe que no son idempotentes, así que un provider reenviando el mismo evento cobra o acredita al usuario dos veces, y gaps de row-level security filtrando datos entre usuarios. Alejá el zoom y se acumula: la investigación de Uplevel midió que los desarrolladores con asistentes de IA shippean cerca de 41% más bugs, y el arco es conocido — el mes uno se siente eléctrico; al mes seis los equipos van más lento que antes de adoptar IA. El fix no es promptear más fuerte. Es darle al agente un codebase donde los invariantes peligrosos ya están codificados — en tipos, reglas de lint y tests que no puede mergear por encima.

La capa operacional que tu agente nunca construyó bien

Webhooks de pago idempotentes

Las entregas se deduplican por externalOrderId antes de cualquier mutación de estado — la clase de bug del doble cobro se cierra estructuralmente, no por disciplina del handler.

Efectos secundarios durables

Un event bus con outbox persiste los efectos antes de ejecutarlos; un crash a mitad de handler significa reintento, no pérdida silenciosa.

Colas con semántica real

BullMQ con schedulers y reintentos — no un setTimeout enterrado en un route handler.

Sesiones que mueren al cambiar la contraseña

El bug exacto que los agentes siguen regenerando está resuelto en la capa de auth, con la revocación cableada.

Tenant isolation debajo del caso de uso

Repositorios org-scoped más un query guard de Prisma: las lecturas entre orgs dan 404 en la capa de datos aunque un controller se olvide de chequear.

Observabilidad como config, no como sprint

Logs estructurados con Pino, OpenTelemetry, Sentry y un endpoint /metrics de Prometheus — cada uno desactivado hasta que una env var lo prende.

El harness adentro del que corre tu agente

El repo está construido como lo que el discurso de harness engineering llama “an execution environment for agents” (un entorno de ejecución para agentes) — zeyu2001 en dev.to: fronteras de capas DDD exigidas por ESLint — domain no puede importar express ni Prisma — un contrato OpenAPI regenerado desde el server con un gate de frescura en CI, y un golden path de Playwright que camina registro → org → invitación → billing en un navegador real en cada cambio. Tu agente itera libre; el harness rechaza cualquier cosa que erosione la arquitectura.

CI — main gate
 1  $ bun run lint          # DDD boundaries enforced
 2  $ bun run typecheck     # end-to-end typed contract
 3  $ bun run test          # 450+ unit + integration
 4  $ bun run test:e2e      # golden path, real browser
 5  ✓ api-types-fresh: openapi.json matches server
 6  ✓ all gates passed — merge allowed

Construido una vez, para que el agente no tenga que adivinar

Bounded contexts, con fronteras exigidas

iam, tenancy, billing, webhooks, storage — layering domain/application/infrastructure/interfaces que ESLint vuelve estructural, no aspiracional.

Un port de pagos, tres providers

IPaymentProvider abstrae Stripe, suscripciones preapproval de MercadoPago y Polar — las mañas de cada provider se quedan en los adapters.

Contratos como fuente de verdad

Schemas Zod compartidos en @app/contracts; los tipos del cliente se generan desde el OpenAPI del server. El drift de payloads rompe CI, no producción.

RBAC y API keys

Los strings de permisos fluyen por la superficie OpenAPI; orgs, roles, invitaciones y keys están modelados, no improvisados.

Disciplina de arranque

Env validado con Zod y cuatro vars requeridas; cada adapter opcional — Redis, S3, Sentry, OTel — degrada a no-op.

Artefactos de deploy en el repo

Dockerfile, docker-compose, configs de Railway y Dokploy, con migraciones de Prisma aplicadas al boot.

Tu camino de migración desde un codebase hecho con Cursor

Sos developer, así que va el encuadre honesto: esto es un port, no un merge. Las features que shippeaste con Cursor son la parte valiosa; la infraestructura improvisada alrededor es el pasivo. Mové las features de a un bounded context por vez — entidades e invariantes a domain/, orquestación a casos de uso en application, repositorios de Prisma en infrastructure/, controllers de Express finitos con schemas Zod en el borde — después corré bun run generate:api y dejá que el cliente tipado traiga la superficie nueva al frontend. Tus tests existentes se portan como tests de casos de uso; el E2E del golden path cubre la integración. De ahí en más, Cursor funciona mejor que antes: las convenciones del repo y las fronteras exigidas son contexto que tu agente lee en cada tarea — que es exactamente el setup que mantiene al mes seis tan rápido como el mes uno.

Preguntas de Cursor, respondidas

¿Por qué un backend Express aparte en vez de API routes de Next.js?+
Pasadas unas decenas de endpoints, los backends de route handlers pierden separación de responsabilidades y los agentes aceleran el deterioro. Un servicio Express en DDD con capas lint-enforced le da al agente reglas de ubicación sin ambigüedad — y el frontend igual tiene type safety completa por el contrato generado.
¿Qué frena a mi agente de romper la arquitectura?+
Tres gates mecánicos: reglas de frontera de ESLint (domain no puede importar express ni @prisma/client), el chequeo de frescura del OpenAPI (tipos viejos rompen CI) y la suite de tests con el golden path de Playwright. Las violaciones rompen el build — sin depender de la vigilancia de un reviewer.
¿Qué tan real es el gate E2E?+
Una suite de Playwright corre el golden path — registro, crear org, invitar, suscribirse — contra un navegador y una base reales en CI en cada cambio, con una suite más completa cada noche. Es un gate de merge, no un smoke test.
¿Puedo cambiar partes del stack?+
Dentro de los ports, sí: pagos, storage, email y observabilidad están detrás de interfaces con múltiples adapters incluidos. El núcleo (Bun + Express + Prisma + Next.js) es la parte opinada — y esa opinión es lo que hace aplicables los guardrails del agente.

Una licencia. Dos formas de tenerla.

CORE

Founder

$99pago único

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
RECOMMENDED

LATEST + UPDATES

Lifetime

$199$249pago único

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

Dale a tu agente una base que no puede romper

Mantené la velocidad. Sumá la capa operacional — idempotencia, outbox, colas, observabilidad, gates E2E — construida y exigida antes de tu próximo prompt.