En el artículo anterior resumí tres costes de Vibe Coding; es decir, los problemas que aparecen al desarrollar sin leer el código.
Los bugs se vuelven imposibles de corregir, la misma funcionalidad aparece en varios lugares y se abre una brecha de seguridad silenciosa. Como solución, propuse leer solo las zonas críticas, leer resúmenes generados por IA y ejecutar escáneres.
Sin embargo, estas soluciones tienen algo en común: todas son verificaciones posteriores que detectan el problema después de que ocurre un incidente.
Este artículo va un paso más allá: cómo imponer restricciones para que la IA no pueda crear ese tipo de código desde el principio, antes de verificarlo.
Las herramientas ya están disponibles. Son archivos de reglas como CLAUDE.md, .cursorrules y AGENTS.md.
El resultado de Vibe Coding se decide al escribir el primer archivo de reglas, no al leer el código.
¿Por qué archivos de reglas? — La IA es una persona recién incorporada cada vez
Empecemos por una característica fundamental de las herramientas de programación con IA: cuando termina la sesión, la IA olvida la mayor parte de lo ocurrido.
Aunque ayer le dijeras «saca las claves de API a variables de entorno», en la nueva sesión de hoy esa conversación deja de existir.
Por eso, las instrucciones que se repiten en cada sesión deben quedar fijadas en un archivo, no en una conversación.
CLAUDE.md (Claude Code), .cursorrules (Cursor) y AGENTS.md (herramientas de propósito general como Codex) son ejemplos. Estos archivos de reglas se añaden automáticamente al prompt cada vez que comienza una sesión.
Para una persona, son como los documentos de incorporación que se entregan a alguien nuevo que llega a trabajar cada mañana.
Esto encaja especialmente bien con el vibe coding porque, por definición, consiste en que las personas no leen el código.
Algo debe cubrir el vacío que deja la revisión humana, y el primer candidato son las reglas aplicadas al generar código. Es mucho más barato evitar que aparezca código defectuoso que filtrarlo después.
A los tres problemas del episodio anterior sumaremos dos fallos propios de la IA que solo pueden detectarse leyendo el código: veremos cómo impedir los cinco mediante reglas.
Regla 1. Seguridad — Escribe no solo «no lo hagas», sino también «hazlo así»
Empecemos por las claves de API codificadas de forma fija que vimos en el episodio anterior. En el archivo de reglas escribimos lo siguiente:
## Reglas de seguridad (si se incumplen, detener la generación de código e informar)
- API No codificar claves, tokens ni contraseñas directamente en el código.
Leerlos siempre desde variables de entorno(.env) o un gestor de secretos.
- .env No hacer commit del archivo. .env.example; hacer commit solo de.
- No confiar en la entrada del usuario. SQL; usar vinculación de parámetros,
HTML Escapar siempre la salida por defecto.
- Al escribir código para eliminar archivos·DB , migraciones o llamadas API a pagos externos,
obtener siempre la confirmación del usuario antes de ejecutarlo.
- No instalar bibliotecas nuevas sin autorización. Primero propone el nombre del paquete y
el motivo de elegirlo y añádelo tras obtener aprobación.Aquí hay dos puntos clave.
Primero, escribe también la alternativa, no solo la prohibición. Si solo indicas «No hardcodear», la IA tendrá que buscar una solución alternativa por su cuenta.
Si especificas «Léelo de una variable de entorno», seguirá ese camino sin dudar. El cumplimiento de una regla es proporcional a la concreción de la alternativa.
Segundo, utiliza procedimientos distintos para tareas con diferentes niveles de riesgo. Si estableces que las eliminaciones, los pagos y las migraciones requieren «confirmar antes de continuar», el flujo frenará justo en esos puntos, incluso cuando todo lo demás siga un proceso de Accept All.
La regla de dependencias de la última línea también forma parte de la seguridad. Un estudio indica que entre el 5 y el 21 % de los nombres de paquetes recomendados por la IA no existen realmente en los registros, pero lo preocupante viene después.
Los atacantes se adelantan y registran nombres falsos que la IA suele inventar para publicar paquetes maliciosos con ellos. Los ataques de slopsquatting están ocurriendo en la práctica.
En el vibe coding, donde incluso los comandos de instalación pasan con Accept All, esta ruta puede convertirse directamente en un incidente de la cadena de suministro. Por eso es más seguro establecer como procedimiento que los paquetes nuevos se propongan y después se aprueben.
Regla 2. Duplicación — Formalizar «buscar antes de crear»
La causa de que la misma funcionalidad aparezca en varios lugares no es que la IA sea perezosa. La IA trata el código que no puede ver en su contexto como código inexistente.
A medida que el proyecto crece, el código completo deja de caber en el contexto, por lo que crear una función similar nueva se convierte en una decisión razonable desde la perspectiva de la IA.
Por eso imponemos la exploración mediante una regla.
## Regla de prevención de duplicados
- Antes de crear una función o componente nuevo, busca siempre en el código existente
para comprobar si ya existe algo con la misma función.
- El procesamiento de fechas src/utils/date.ts, API las llamadas van src/lib/api.tsa
Usa una función existente. Si no existe, añádela a ese archivo.
- Extrae de inmediato a un módulo compartido la lógica que se use en dos o más lugares.
- Si parece necesario crear una función casi idéntica a una existente, no la crees de nuevo
Primero comprueba si puedes ampliar la función existente y propónselo al usuario.La segunda línea es especialmente eficaz. Un mapa que indique «el procesamiento de fechas está en este archivo» funciona mucho mejor que la regla abstracta «no crees duplicados».
Aunque AI omita la búsqueda, las rutas escritas en el archivo de reglas siempre están a la vista. Mantener en ese archivo una lista de las ubicaciones de los módulos compartidos del proyecto reduce notablemente la creación de duplicados.
Regla 3. Arquitectura — Convertir la estructura de carpetas y la dirección de las dependencias en la constitución
De las tres, la arquitectura es la que se desmorona de forma más silenciosa. Los incidentes de seguridad se detectan cuando ocurren y los duplicados se ven al buscarlos, pero con la arquitectura, un día miras atrás y ya se ha convertido en espagueti.
AI tiende a escribir «el código que resuelve esta solicitud lo más rápido posible ahora». Por eso abre atajos entre capas sin darle importancia.
Por ejemplo, llamar directamente a la base de datos desde una vista.
Esto también puede bloquearse con reglas. La clave es especificar explícitamente la estructura y la dirección de las dependencias.
## Reglas de arquitectura
Estructura del proyecto:
- src/views/ : UI. Solo gestiona estados y eventos
- src/services/ : Lógica de negocio
- src/repositories/ : Acceso a datos. DB·API las llamadas solo se realizan aquí
La dirección de las dependencias es views → services → repositories unidireccional.
- viewsno repositoriesdirectamente import
- repositoriesno views import
- Las funciones nuevas también deben seguir esta 3estructura por capas.
Si existe un motivo para salir de la estructura, explícaselo al usuario antes de escribir códigoEl verdadero valor de esta regla aparece después de establecer el esqueleto inicial.
La IA tiende a imitar con fuerza los patrones del código existente. Si el código inicial respeta la arquitectura de tres capas, el código posterior seguirá naturalmente la misma línea.
En cambio, si al principio se abre aunque sea un atajo, la IA lo aprende como «un patrón permitido en este proyecto».
Por eso el subtítulo de este artículo es «El esqueleto inicial».
Justo después de crear el proyecto, establece primero el archivo de reglas y la estructura de carpetas cuando el código solo tenga 10 líneas. Esto cuesta cientos de veces menos que refactorizar 10.000 líneas después.
Regla 4. Criterio de finalización: distinguir entre «parece terminado» y «está terminado»
A partir de aquí veremos un tipo de razonamiento propio de la programación con IA que no se trató en el artículo anterior.
La IA tiende a decir «Completado» sin comprobar nada cuando termina de escribir el código. Incluso cuando el código ni siquiera compila.
En un flujo de trabajo donde una persona lee el diff, esto se descubre enseguida, pero en el vibe coding se confía en la palabra «completado» y se pasa a la siguiente solicitud. Por eso, la definición de completado debe establecerse como una regla.
## Regla de definición de completado
- Antes de declarar completado el trabajo, siempre typecheck·lint·ejecuta las pruebas
e informa también de sus resultados
- Si una prueba falla, corrige el código. No modifiques ni elimines las pruebas para hacer que pasen
Si consideras que la prueba en sí es incorrecta, no la fuerces a pasar; en su lugar
informa primero sin modificarla
- No envuelvas los try/catcherrores para tragártelos en silencio.
Registra siempre los errores capturados o propágalos hacia arribaLa segunda regla es la clave. Si el objetivo que se da a la IA es «haz que pasen las pruebas», en la práctica puede corregir las pruebas que fallan en lugar de corregir el código.
Ha encontrado el camino más corto para alcanzar el objetivo. Quien no lee el código puede limitarse a ver la luz verde sin darse cuenta de que el mecanismo de validación ha quedado inutilizado.
La tercera regla está directamente relacionada con el problema 1 de la entrega anterior (dejar de poder corregir errores).
La IA tiende a envolver el código en un try/catch que se traga los errores bajo la premisa de programar de forma defensiva. Así, aunque surja un problema, la pantalla puede parecer normal. Más tarde, los mensajes de error que realmente necesitas no aparecen en ningún sitio, lo que dificulta aún más la depuración.
Regla 5. Alcance — Haz solo lo que se te ha pedido
Otro fallo clásico de la programación con IA es hacer cosas que nadie ha pedido, lo que se conoce como scope creep. Pides cambiar el color de un botón y, “ya que está”, refactoriza el código cercano, extrae nuevas funciones auxiliares e incluso modifica la estructura de archivos.
Puede parecer una buena intención, pero en el vibe coding es peligroso. Si no lees el diff, quizá no detectes los cambios no solicitados y, cuando algo se rompa más tarde, las posibles causas se multiplicarán.
## Reglas de alcance
- Haz solo el trabajo solicitado. Enumera las mejoras detectadas durante el trabajo y sugiérelas
al terminar, sin modificar el código
- No modifiques archivos ajenos a la solicitud
- Refactoriza solo cuando se solicite por separadoEl efecto también puede medirse. Según los datos, añadir unas pocas reglas de alcance al archivo de reglas redujo del 41 % al 12 % la tasa de revert y de desviaciones del alcance.
Son cifras de un informe de medición en campo de 30 días. De los cinco tipos de reglas, este eje ofrece el mayor retorno de la inversión.
Las reglas por sí solas no bastan — añade un doble bloqueo
Al llegar hasta aquí, podrías pensar: “Entonces, si escribo bien las reglas, ya no necesito leer el código”. Pero hay una trampa: las reglas aumentan la probabilidad de cumplimiento, no lo garantizan.
La IA puede olvidar las reglas cuando el contexto se alarga y, si parece estar bajo presión, puede optar por atajos.
Por eso, cuanto más importante sea una regla, más debe combinarse con una verificación mecánica. La regla es el primer bloqueo; la herramienta, el segundo.
| Reglas (prevención durante la generación) | Herramientas (verificación en el commit y la CI) |
|---|---|
| No codificar secretos directamente | Hook pre-commit de gitleaks |
| No duplicar lógica | Un detector de duplicación como jscpd |
| Forzar la dirección de las dependencias entre capas | dependency-cruiser, eslint-plugin-boundaries |
| Criterio de finalización (pruebas · comprobación de tipos) | Puerta de la canalización de CI |
| No modificar archivos de pruebas sin autorización | Proteger la carpeta de pruebas con CODEOWNERS |
| Estilo de código | ESLint·Prettier·SwiftLint |
La fuerza de esta combinación está en el bucle de retroalimentación. Cuando una herramienta detecta una infracción de las reglas, su mensaje de error vuelve a la IA, que consulta de nuevo el archivo de reglas y corrige el problema.
El bucle prevenir → verificar → corregir funciona sin intervención humana. El principio del artículo anterior —«Si las personas no lo van a leer, haz que lo lea la máquina»— se completa al combinarlo con las reglas.
Traslada al linter todo lo que pueda imponerse mediante reglas de lint. Lo ideal es que el archivo de reglas conserve lo que las herramientas no pueden detectar: procedimientos de comprobación, intención de diseño y contexto del proyecto.
En la práctica: lista de comprobación de 10 minutos para iniciar un proyecto
Antes de empezar a programar con vibecoding en un proyecto nuevo, haz esto antes de escribir el primer prompt.
- Crea el archivo de reglas: cinco secciones sobre seguridad, duplicación, arquitectura, criterios de finalización y alcance. Copia el ejemplo anterior, adáptalo a tu proyecto y estará listo en 10 minutos.
- Confirma primero el esqueleto de carpetas: aunque estén vacías, establecer la estructura hará que la IA siga ese patrón.
- Instala un hook para analizar secretos: con gitleaks basta para evitar los peores incidentes.
- Crea .env.example: indica a nivel del código base que “las claves van aquí”.
Durante la operación, recuerda una sola cosa: si la IA comete el mismo error dos veces, no es culpa de la IA; es una señal de que falta esa regla en el archivo de reglas.
Refuerza las reglas línea por línea cada vez que ocurra un incidente. El archivo de reglas no se escribe una vez para olvidarlo, sino que crece junto con el proyecto.
P. ¿Es cierto que las reglas se cumplen menos cuando el archivo de reglas se hace demasiado largo?
R. Sí. Las reglas también consumen contexto, así que cuanto más largo es el archivo, más se diluye el peso de cada regla.
Mantenlo conciso según el criterio “¿hay que cumplirlo siempre?” y delega en las herramientas lo que puedan detectar. Por experiencia, cuando supera una pantalla —unas 100 líneas— necesita una reducción.
P. ¿También sirve para un proyecto que ya se ha convertido en un espagueti?
R. Sí, pero el orden cambia.
Primero, pide a la IA que analice la estructura actual y genere un borrador del archivo de reglas. Después, indica explícitamente una estrategia gradual: “El código nuevo debe seguir estas reglas, y el existente se corrige cuando se toque”.
P. ¿Tengo que gestionar CLAUDE.md, .cursorrules y AGENTS.md por separado?
R. Lo habitual es escribir el contenido una sola vez y duplicar únicamente los archivos.
Últimamente también se está extendiendo el uso de AGENTS.md como estándar, haciendo que otros archivos lo referencien. Si utilizas varias herramientas, recomendamos tomar AGENTS.md como fuente única de verdad.
En resumen: si la conclusión del artículo anterior era «la velocidad para la IA y el criterio para mí», la conclusión de esta entrega es la siguiente:
No tomes la misma decisión una y otra vez; convierte en una regla cada decisión que hayas tomado una vez.
Leer código consiste en descubrir el razonamiento que hay detrás; escribir reglas consiste en prevenir problemas. Los proyectos que mantienen la velocidad con Vibe Coding sin venirse abajo tienen algo en común: no son los prompts llamativos, sino unos archivos de reglas bien desarrollados.
Si el proyecto en el que trabajas hoy no tiene un archivo de reglas, crea primero las cinco secciones anteriores antes de pedirle que implemente la siguiente funcionalidad.
La diferencia entre los archivos de reglas y las funciones de memoria, así como qué contenido debe ir en cada lugar, se explica en detalle en otro artículo; te recomendamos leerlo también.
Material de referencia
- Claude Code Memory - Anthropic Docs
- Rules - Cursor Docs
- AGENTS.md - Estándar para archivos de reglas de agentes
- AI Agent Failure Modes - NimbleBrain
- CLAUDE.md Rules: How to Cut AI Coding Mistakes - DEV Community