El equipo dev en MorgansMedia es chico: 3 personas operando Cerebro RevOps, integraciones con Kommo, Google Ads API, Meta Ads API, GA4, GSC y los scripts internos que sostienen la operación consultora. En el papel deberíamos estar siempre atrasados. En la práctica delivery sube trimestre a trimestre. La diferencia es el workflow de vibe coding con Cursor + Claude Code que documenté al detalle.
La semana pasada hablé del Trust Paradox: el código IA funciona pero pocos lo entienden. Hoy doy la vuelta: documento el workflow específico que aplica MM para usar Cursor + Claude Code sin caer en esa paradoja. Es la receta operativa, paso a paso, con números propios.
El stack que usamos
Cursor como IDE primario. Versión Pro (USD 20 mensuales por seat). Tres seats activas (Andrés, Francisco para tareas específicas y yo).
Claude Code como herramienta de terminal para tareas grandes. Plan API directo (Anthropic Console). Costo variable: entre USD 60 y USD 200 por dev al mes según intensidad.
GitHub como repo + GitHub Actions para CI/CD.
Vercel y Cloudflare Workers como deployment targets. Vercel para frontend y APIs Next.js, Workers para edge logic ligera.
Costo típico por dev al mes: entre USD 60 y USD 80 que cubren herramientas. Para una operación que entrega features productivas semana a semana, se amortiza en menos de una semana de trabajo evitado.
El workflow paso a paso
El orden importa. Cuando lo respetamos, las cosas salen bien. Cuando saltamos pasos, aparecen los problemas del Trust Paradox.
Paso 1: brief humano detallado antes de tocar IDE. Antes de abrir Cursor, el dev redacta brief de 200-400 palabras describiendo: qué problema resuelve la feature, qué input recibe, qué output entrega, qué sistemas externos toca, qué edge cases conocidos hay que cubrir, qué alternativas se descartaron y por qué.
El brief vive en un README al lado del archivo principal. No es burocracia. Es la doc que explica al dev de 6 meses adelante por qué esta solución existe.
Paso 2: prompt inicial a Cursor con contexto pegado. Abro Cursor en el archivo correcto. Selecciono el brief del README. Prompt típico:
Lee el brief de arriba. Genera implementación en TypeScript usando los patrones que ya existen en este repo (revisa /lib/integrations para ejemplos de manejo de APIs externas). Antes de codear, dame plan en 3-5 bullets de tu approach. Después del plan, espero confirmación para continuar.El plan en bullets es lo que separa vibe coding bueno de vibe coding malo. Si Cursor propone approach que no me convence, lo discuto antes de generar código. Eso evita refactor masivo después.
Paso 3: generación y revisión inmediata. Confirmo el plan. Cursor genera código. Yo leo línea por línea (no skim) antes de aceptar. Para cada función, debo poder explicar en una frase qué hace. Si no puedo, prompt extra: «Explicame qué hace esta función y por qué elegiste esta solución vs alternativas».
Es paso lento. Toma 50-70% del tiempo total de la feature. Pero es el paso que evita acumular deuda técnica invisible.
Paso 4: tests escritos a mano. Esta es la regla operativa contraintuitiva más importante: los tests los escribo yo, no Cursor. Si Cursor escribe código y tests, hay riesgo de que la IA omita casos edge que ella misma no anticipó.
Los tests humanos sobre código IA descubren bugs reales. Hemos encontrado en MM 11 bugs distintos en los últimos 6 meses por aplicar esta regla. Si los tests fueran generados por IA, esos bugs hubieran llegado a producción.
Paso 5: Claude Code para tareas grandes en terminal. Cuando la tarea es masiva (refactor de 30 archivos, migración de patron, generación de docs completas, análisis de codebase), abro Claude Code en terminal. La diferencia con Cursor: Claude Code maneja mejor contexto largo, opera sobre múltiples archivos coordinadamente y resume su trabajo al final.
Típicamente uso Claude Code 2-3 veces por semana. Cursor todos los días.
Paso 6: PR con descripción redactada por humano. La descripción del PR la escribo yo a mano. Resume: qué cambia, por qué cambia, qué testing se ejecutó, qué limitaciones quedan, qué followups habilita.
Esta descripción vale más que el código mismo cuando alguien revisa el PR en 6 meses. Cursor puede ayudarme a redactarla, pero la curo manualmente.
Los números propios de MM
Mediciones de los últimos 14 meses:
Features sencillas (CRUD típicos, integraciones API conocidas, UI components estándar): reducción de tiempo entre 55% y 65% versus desarrollo sin asistencia IA. Lo que antes tomaba 8 horas, ahora toma 3-3.5 horas.
Features complejas (lógica de negocio custom, optimizaciones de performance, arquitectura nueva): reducción entre 25% y 40%. Lo que antes tomaba 24 horas, ahora toma 14-17 horas.
Scripts one-shot (migraciones, data manipulation, análisis puntuales): reducción del 75-85%. Lo que antes tomaba 4 horas, ahora toma 30-45 minutos.
Documentación automática de funciones existentes: reducción del 90%. Lo que antes era trabajo de tarde completa, ahora es 30 minutos.
El payback del costo (USD 60-80 mensuales por dev) ocurre en la primera semana del primer mes. Cualquier dev que recupera 4-6 horas de trabajo al mes ya justificó el costo. En MM recuperamos 20-40 horas semanales por dev. La proporción es absurda.
Lo que no funciona y vale la pena evitar
Tres prácticas que probé y descartamos:
Una. Aceptar código sin leer línea por línea. Tentación constante. La velocidad de aceptar código aparente cuando el output parece razonable. El costo aparece 60-90 días después cuando hay que modificar algo que nadie revisó.
Dos. Auto-generación de tests con IA. Resultado: tests que se sienten bien pero no descubren bugs reales. La calidad del testing baja silenciosamente. Mejor menos tests, escritos a mano, con criterio humano.
Tres. Refactor masivo sin plan previo. La IA puede refactor mil líneas en un prompt. Si el refactor no fue planeado, el código nuevo introduce inconsistencias. Mejor refactor por iteraciones pequeñas con plan en bullets antes.
Cuatro. Cursor para tareas que requieren contexto largo. Cursor opera bien con context de 1-3 archivos. Cuando la tarea cruza 5-10 archivos, conviene pasar a Claude Code que maneja mejor el contexto extendido.
El balance que vale la pena buscar
La pregunta correcta no es "¿vibe coding sí o no?" sino "¿qué balance de disciplina y velocidad funciona para mi equipo?".
En MM operamos con balance "productivo con criterio". Eso significa: aceptamos 55-65% reducción de tiempo en tareas estándar pero mantenemos protocolos que evitan deuda técnica acumulada. La inversión extra (lectura línea por línea, tests a mano, docs vivas) cuesta 30-40% del tiempo ganado. Resultado neto: 20-30% de reducción real con calidad mantenida.
Equipos que aplican vibe coding sin protocolos consiguen reducción del 65-75% inicial. Pero acumulan deuda que aparece en mes 6-9 como velocity caída en mantenimiento. La reducción real a 12 meses suele estar entre 15% y 20% una vez que se factoriza el costo del rework.
La diferencia entre los dos modos es disciplina operativa, no herramientas. Las mismas Cursor + Claude Code rinden distinto según cómo el equipo las opere.
Lo que vamos a iterar en los próximos 6 meses
Evaluaciones activas que vamos a probar:
Browser-use agents para QA automatizado. Hoy QA manual sobre features nuevas. Si funciona, podríamos automatizar parte del QA.
Claude Code en modo bot para tareas periódicas. Hoy lo usamos manualmente. Vamos a probarlo como cronjob para tareas como "limpia logs viejos", "actualiza dependencias menores", "genera reporte semanal del repo".
Integración más profunda de MCP servers en Claude Code. Hoy MCP es uso interactivo. Queremos workflows agentáticos que combinen Claude Code + MCP de GitHub + MCP de nuestro deployment para coordinar releases.
Preguntas frecuentes
¿Puedo usar el workflow con un dev junior recién contratado?
No desde el día uno. Recomendación: primeros 12 meses, programación clásica con asistencia IA puntual en tareas mecánicas. El junior aprende fundamentos sin que la IA piense por él. Después del año, vibe coding completo con el protocolo. Saltar este orden produce devs con buena tasa de delivery pero criterio débil cuando la IA falla.
¿Qué pasa si mi cliente prohibe enviar código propietario a APIs externas?
Valido. En esos casos, alternativas: GitHub Copilot Business (acepta NDAs corporativas), modelos open-weight on-premise (Llama, Mistral) con Continue o Cline. La calidad es menor que Cursor + Claude Code pero cubre compliance. Costó mensual típico USD 19-39 por seat vs USD 60-80 de Cursor Pro + Claude Code.
¿Mi proyecto es muy chico para justificar este workflow?
La unidad de tiempo recuperado importa más que el tamaño del proyecto. Si recuperas 4+ horas mensuales, ya justifica USD 60-80 mensuales. Para proyectos chicos pero con varios devs, el ROI total es atractivo. Para proyecto chico con un dev, evalúar uso por sprint (no compromiso anual).
El cierre
Vibe coding con Cursor + Claude Code es palanca operativa real cuando se aplica con disciplina. El workflow que documenté es el que aplica MM tras 14 meses de iteración. No es teórico: es la receta que sostiene el delivery del equipo dev de 3 personas operando Cerebro RevOps + integraciones para 14 clientes activos.
El costo es USD 60-80 mensuales por dev. El payback ocurre en la primera semana del primer mes. La condición para que rinda es disciplina del workflow, no la herramienta misma. Los equipos que aplican workflow sólido tienen 24-36 meses de ventaja operativa sobre los que adoptan sin protocolo o se quedan en programación clásica.
El DMC (Diagnóstico de Madurez de Crecimiento) de MorgansMedia incluye auditoría de procesos de desarrollo del cliente cuando hay equipo dev interno. Mapea workflow actual, identifica oportunidades de integrar IA con protocolo sólido y propone roadmap específico. La salida no es "usen Cursor". Es "este workflow específico, calibrado a su equipo y stack, va a generar 25-40% de velocity extra sin acumular deuda técnica".
