vibe coding
desarrollo-asistido-por-ia
estándares-de-codificación
arquitectura-de-software
mejores-prácticas-de-desarrollo
Imagina que todo va bien en tu desarrollo, estas vibrando con el codigo y, de pronto, la IA propone algo que no sigue tus convenciones; duplica lógica, cambia de patrón o mezcla estilos. No es “capricho”, es falta de contexto cercano al código. La solución no es un manual de 50 páginas, sino reglas cortas y vivas que la IA pueda leer justo donde trabaja.
Una regla de contexto es un archivo breve (Markdown) que vive junto a tu código (por ejemplo, en .cursor/rules/) y explica cómo debe lucir y comportarse un archivo o módulo concreto:
Cuando tu editor con IA (p. ej., Cursor) genera o modifica código, lee esas reglas como guía para mantener consistencia. No reemplaza linters ni tests; es una especificación ligera que orienta a la IA.
Mini-ejemplo (.mdc):
1# Objetivo 2Respuestas REST consistentes. 3 4# Convenciones 5- JSON con `{ data, error }`. 6- Errores con `code` y `message`. 7 8# ✅ Correcto 9return res.json({ data: user, error: null }); 10 11# ❌ Incorrecto 12Responder `{ result }` en unos endpoints y `{ payload }` en otros.
Regla práctica: si corregiste dos veces el mismo tipo de salida de la IA, ya es hora de escribir una regla corta.
Elige un archivo “VIP”. Algo que marque el tono del resto: routes.py, UserService.ts, Form.tsx, theme.ts, etc.
Pide a la IA que redacte la regla. En Cursor, con el archivo abierto, solicita:
1Genera una regla corta para mantener este archivo consistente. 2Incluye: objetivo, 3–5 convenciones y 1 ejemplo correcto (mínimo). 3No agregues prosa fuera de la regla.
.cursor/rules/ y guarda como api-endpoints.mdc (usa un nombre descriptivo).1# Objetivo 2<qué estandariza y por qué> 3 4# Convenciones 5- <regla 1 concreta> 6- <regla 2 concreta> 7- <regla 3 concreta> 8 9# ✅ Correcto 10<snippet mínimo con el formato esperado> 11 12# ❌ Incorrecto 13<snippet típico que no queremos>
1# Objetivo 2Estandarizar endpoints REST con respuestas consistentes. 3 4# Convenciones 5- Responder JSON con `{ data, error }`. 6- Errores con `code` y `message`. 7- Evitar lógica de negocio en el controlador; delegar a servicios. 8 9 10# ✅ Correcto 11router.get('/users/:id', async (req, res) => { 12 try { 13 const user = await svc.getUser(req.params.id); 14 return res.json({ data: user, error: null }); 15 } catch (e) { 16 return res.status(400).json({ data: null, error: { code: 'USER_GET_FAILED', message: String(e) } }); 17 } 18}); 19 20# ❌ Incorrecto 21Responder `{ result }` en un endpoint y `{ payload }` en otro.
Frontmatter YAML y globs son opcionales en este módulo básico.
Para probar la regla, pídele a la IA una modificación real sobre el archivo VIP (por ejemplo, “añade GET /users con paginación”) y comprueba si la respeta. Si se desvía, ajusta la regla con un único cambio (delta prompting), por ejemplo: “agrega que las respuestas de éxito usen status 200 y los errores ≥400; no cambies nada más”. Repite hasta que las sugerencias salgan consistentes y añade siempre una sección con ejemplos correctos e incorrectos, porque ver lo que sí y lo que no quieres ayuda al modelo a fijar el estándar.
Imagina que estás agregando una nueva función de chat a tu aplicación que usa WebSockets. Así es como podrías usar las reglas, crea una archivo hat-websocket.mdc por ejemplo y plantea lo siguiente:
1# Objetivo 2Errores y reconexión consistentes en WebSocket (chat). 3 4# Convenciones (por qué) 5- `onerror` + `onclose` (visibilidad y estabilidad). 6- Backoff exponencial máx. 30s (evita loops agresivos). 7- Conexión encapsulada (evita estado global frágil). 8 9# ✅ Correcto 10const socket = new WebSocket(URL); 11socket.onerror = (err) => { log('ws_error', err); attemptReconnect(); }; 12 13# ❌ Incorrecto 14Solo `console.error` sin reconexión ni encapsulación.
Ahora pide “typing notifications” y la IA debería mantener onerror + reconexión sin recordatorios adicionales.
Para tener las reglas organizadas, guárdalas en .cursor/rules/ con nombres claros y, si aporta, subcarpetas por módulo o capa. Versiona todo como código, súbelas a git y revísalas en PRs. En cada PR explica por qué existe o cambia la regla (qué problema resuelve) para que el equipo entienda el contexto. Por otro lado, al escribir y mantener reglas, evita los tropiezos típicos. Si una regla se alarga, reduce a lo esencial y lleva los ejemplos grandes a un archivo aparte. Cambia las vaguedades (“código limpio”) por acciones concretas (“usar try/catch en fetch asíncronos”). Si hay duplicadas o conflictos, unifica o documenta la precedencia (“si coincide con X, prima X”). Y no te saltes la prueba, pide una modificación real y verifica que la IA respeta la regla.
Crear reglas en medio del desarrollo suele ser más fácil porque tienes código real del que partir. Si, en cambio, repites un patrón muy conocido (p. ej., una API REST simple que ya construiste), puedes preparar 1–2 reglas desde el día uno. También existen colecciones públicas de reglas preescritas que puedes adaptar (p. ej., cursorrules).
/Generate Cursor Rules y refines la salida, mejores serán tus prompts, ¡y mejor será la IA para ayudarte!No necesitas un sistema perfecto para empezar. Con una buena regla en un módulo clave ya notarás menos fricción y más consistencia. Crea la primera hoy, pruébala y ajústala con cambios pequeños; mañana, tu IA ya sugerirá código más alineado con tu proyecto.