AI workflow con Cursor: cómo el equipo frontend construye reglas compartidas sin perder consistencia
Cómo un miembro nuevo del equipo que usaba Cursor nos llevó a construir reglas compartidas, salidas de los code reviews, para que cualquier dev generara código alineado a los estándares del producto.
La IA en ingeniería no se discute más. Lo que se discute, y lo que casi nadie cuenta bien, es cómo se introduce IA en un equipo sin romper la consistencia del código, el criterio técnico y la cultura del equipo.
Esto no surgió de una decisión mía. Un miembro nuevo del equipo llegó trabajando con un nuevo flujo de trabajo que no era el nuestro, usaba ai para todo, maquetaba con ai, etc. El código que generaba era funcional, pero no se parecía al resto del producto: patrones distintos, convenciones que no eran las nuestras, estilo diferente. Cada PR levantaba eran frecuente los mismos comentarios.
En lugar de pedirle que dejara de usar IA, construimos las reglas juntos. Cada observación que salía en un code review se convertía en una regla nueva para el archivo de configuración de Cursor. Con el tiempo, ese archivo pasó a ser el estándar compartido: cualquier miembro del equipo que usara Cursor generaba código alineado a los estándares del producto.
La IA es una herramienta. Nosotros dirigimos, la IA ejecuta. Pero ese “nosotros dirigimos” solo funciona si el agente sabe claramente cómo trabajar. Si no, hace lo que sabe hacer por defecto y termina generando código que no se parece a tu producto. Este post cuenta cómo lo encaramos, qué errores hay que evitar y cómo logramos que el equipo entregue rápido sin perder consistencia.
El problema: IA sin reglas es ruido productivo
Lo primero que hay que entender es por qué hace falta un workflow.
Cuando uno trabaja solo con un agente, el código sale parecido a tu estilo personal porque tú lo guías todo el tiempo. Pero cuando tienes un equipo de varios devs trabajando con Cursor, sin reglas comunes, pasa algo que nadie quiere ver:
- Cada PR usa un estilo distinto.
- Hay funciones que nadie habría escrito así.
- Aparecen patrones que no son los del producto.
- Las convenciones de naming bailan.
- El equipo empieza a pelearse en review por cosas que la IA decidió por su cuenta.
El problema no es la IA. El problema es falta de dirección compartida. Y eso es responsabilidad del lead, no del agente.
Cuando lo entiendes así, el siguiente paso se vuelve obvio: necesitas que el agente trabaje con tus reglas, no con las que trae de fábrica.
Qué es el archivo de reglas de Cursor
El .cursorrules es básicamente el manual del equipo, escrito para que Cursor lo entienda. No es magia. Es disciplina puesta por escrito.
La idea es simple: si quieres que Cursor escriba código que se parezca al tuyo, tienes que decirle cómo escribes. Cómo nombras. Qué patrones usas. Qué evitas. Qué priorizas cuando hay tradeoffs.
.cursorrules es ese contrato, cargado por Cursor en cada sesión. Y lo que lo hace valioso es que no lo construyó nadie solo: cada observación que aparecía en un code review se convertía en una nueva línea del archivo. El equipo entero lo fue llenando sin darse cuenta.
Las secciones que fuimos incluyendo:
- Stack y versiones — React, TypeScript, librerías clave.
- Convenciones de naming — archivos, componentes, hooks, utils.
- Patrones arquitectónicos — cómo separamos lógica, vista, data fetching.
- Política de comentarios — cuándo sí, cuándo no.
- Política de tests — qué se testea, cómo se testea, qué NO se testea.
- Estilo de escritura — código limpio, lo más explícito posible, nada de hacks.
- Política de dependencias — cuándo agregar una nueva, cuándo no.
- Tradeoffs aceptados — performance vs claridad, abstracción vs duplicación, etc.
- Cosas que NO queremos — anti-patrones, fórmulas viejas, atajos prohibidos.
Cada equipo va a tener el suyo distinto. Lo importante es que exista y que lo construya el equipo, no una persona sola.
Por qué el code style explícito vale tanto como el .cursorrules
.cursorrules define el “qué” y el “por qué”. El code style explícito define el “cómo” fino.
Y esto es donde muchos equipos fallan. Porque configuran un .cursorrules hermoso, pero después dejan el code style implícito y la IA tiene que adivinar.
El code style explícito incluye, mínimo:
- TypeScript estricto bien configurado. Sin tipos
anycolados. - ESLint con reglas claras, no las que vienen por defecto, sino las que reflejan tu estilo.
- Prettier compartido para formateo.
- Path aliases que la IA pueda leer y respetar.
- Reglas para naming en archivos.
- Reglas para imports (orden, agrupación).
- Reglas para componentes (cuándo memoizar, cuándo no, cuándo extraer un sub-componente).
¿Por qué importa tanto? Porque la IA respeta el linter. Si el linter te marca algo, la IA va a corregirlo. Si el linter es flojo, la IA hace lo que se le canta.
El linter es tu primera línea de defensa contra la inconsistencia generada por agentes.
Linters: la baranda que la IA respeta
Voy a ser muy claro acá. Si quieres que tu equipo trabaje con IA y mantenga consistencia, invertir en linters fuertes es no-negociable.
No estoy hablando del config por defecto. Estoy hablando de un setup pensado:
- TypeScript estricto, sí o sí.
- ESLint con reglas para hooks de React.
- Reglas para imports, exports, ciclos, archivos huérfanos.
- Reglas para tests (consistencia en describe/it/expect).
- Reglas para accesibilidad (jsx-a11y).
- Reglas para naming.
Y, todavía más importante: reglas que reflejen patrones propios del equipo. No alcanza con airbnb o standard. Esas son guías genéricas. Tú necesitas reflejar tus decisiones.
Cuando el linter está afinado, la IA empieza a generar código que pasa el linter. Y código que pasa un linter bien afinado se parece muchísimo al código que tu equipo escribiría.
El flujo de trabajo con Cursor en el equipo
Más allá del archivo de reglas, lo más importante es el flujo. Cómo se usa Cursor en el día a día.
Acá hay reglas que dejé claras desde el principio:
1. La IA propone, el dev decide. Nunca al revés. La salida del agente no es decisión final. Es punto de partida. El dev sigue siendo responsable.
2. Code review se mantiene exactamente igual. PRs hechos con IA pasan por el mismo Ship/Show/Ask que cualquier otro. Sin excepciones. Sin “es que lo hizo Cursor”.
3. Pensar antes de pedir. Si no entiendes el problema, ningún prompt te va a salvar. Primero entiendes, después pides ayuda.
4. Nada de copiar código que no entiendes. Si la IA te tira algo y no puedes explicarlo, no merece estar en el repo. Punto.
5. Iteración corta y específica. Mejor mil prompts chicos y precisos que uno enorme y vago. La IA es muy buena ejecutando, pero necesita dirección clara.
6. La IA no decide arquitectura. Decisiones grandes (qué stack, qué patrón general, qué librería elegimos) las toma el equipo, con cabeza humana, sin delegarlas.
7. La IA es para acelerar lo claro, no para sustituir lo difícil. Un refactor mecánico, un boilerplate, un test obvio: ideal. Una decisión de diseño compleja: el equipo.
Concepto clave: la IA es tan buena como el contexto que le das
Esto vale por sí solo y lo digo seguido al equipo: la IA no es mágica, es contextual.
Si la IA escupe código malo, casi siempre el problema es uno de tres:
- Le diste poco contexto.
- Le diste contexto contradictorio.
- Le diste un objetivo poco claro.
La IA refleja la calidad del input que recibe. Cuando un dev se queja de “Cursor me dio cualquier cosa”, la pregunta correcta es: ¿qué le pediste y con qué contexto?
Por eso .cursorrules y un code style explícito ayudan tanto. Porque le dan a Cursor el contexto correcto desde el principio.
Errores típicos al introducir IA en un equipo
Te resumo los que veo seguido:
- Sin reglas. El equipo entrega cualquier cosa porque la IA decide por defecto. Caos.
- Demasiadas reglas. Reglas inútiles que nadie sigue. Igual de malo.
- Linter flojo. La IA mantiene la inconsistencia y nadie la atrapa.
- Asumir que la IA va a aprender el estilo del equipo sola. No lo hace.
- Confiar en code review humano para corregir consistencia. Eso no escala.
- Usar IA en lugares donde no aporta. Decisiones difíciles, arquitectura, dominios complejos sin contexto.
- No revisar lo que la IA escribió. Recipe for disaster.
Lo que ganamos con este workflow
Voy a ser honesto. No tengo números mágicos para tirarte. Lo que sí puedo afirmar:
- Los PRs son más consistentes entre miembros del equipo.
- El review se vuelve más rápido porque el código se parece menos a “estilo de la persona” y más a “estilo del equipo”.
- Los devs nuevos onboardean más rápido porque las reglas están escritas.
- La IA acelera el trabajo aburrido sin contaminar el código creativo.
- El equipo entiende mejor las decisiones técnicas porque están explicitadas en
.cursorrules.
Y, sobre todo, mantenemos el control técnico. La IA no termina dictando cómo se ve el producto.
Lecciones para liderar un equipo con IA
Si tuviera que dejar las más importantes:
1. La IA no reemplaza criterio. Lo amplifica. Si tu equipo tiene buen criterio, la IA lo multiplica. Si tu equipo no lo tiene, la IA lo vuelve invisible.
2. La consistencia se diseña, no se espera.
Sin .cursorrules, sin code style explícito y sin linters fuertes, la consistencia es solo un deseo.
3. Disciplina humana > prompts mágicos. No hay ningún “prompt secreto” que reemplace tener procesos claros.
4. Documentar las reglas es invertir en escala. Cada decisión escrita es una decisión que no vas a tener que repetir.
5. La IA es maravillosa para tareas claras y mecánicas. No la uses como reemplazo de pensamiento difícil. La usas como reemplazo de tipeo aburrido.
6. El responsable del código sigue siendo el dev. Lo digo al equipo y lo repito acá: si lo mergeaste, lo escribiste. La IA no tiene firma en el commit.
Conclusión
Trabajar con IA en un equipo no es instalar Cursor y rezar. Es construir el contexto correcto para que la IA trabaje con tus reglas, no con las suyas. .cursorrules clarifica el cómo y el por qué. El code style explícito ordena el detalle. Los linters mantienen la baranda viva. Y el flujo de trabajo se mantiene humano: la IA propone, el equipo decide.
Esa es la diferencia entre un equipo que usa IA con criterio y un equipo que se deja arrastrar por ella.
Si estás liderando un equipo frontend y quieres introducir IA en serio, la lección más importante que me dejó esto es que las reglas no las impone el lead: las construye el equipo, en los code reviews, de a una por vez. Empieza por ahí. La herramienta viene después, casi sola.
Es así de fácil. Y así de difícil.