Le pides a la IA que te haga una portada, una sección, una landing. Sale bien hecha y sale igual a todas las demás. Gradiente morado, tipografía Inter, tres tarjetas redondeadas en fila.
Entonces le echas la culpa al prompt. Escribes uno más largo, con más adjetivos, con referencias. Sale otra vez lo mismo con otro color.
El prompt no es el problema. El problema es que la IA no tiene nada tuyo que leer, y cuando no tiene nada tuyo, promedia lo que vio en internet.
Es el mismo error que ya te cuesta dinero cuando repites prompts a mano: estás pagando cada vez por describir algo que deberías tener escrito una sola vez.
¿Por qué todo lo que diseña la IA se ve igual?
Porque le estás pidiendo que adivine tu marca, y lo que adivina es el promedio de todas.
Ese promedio es real y tiene una historia. Cuando Tailwind publicó su librería de componentes eligió un índigo para las demos, no porque significara algo, sino porque tenía que elegir algo. Millones de páginas de ejemplo después, ese índigo es lo que un modelo cree que se ve "profesional".
Lo mismo con la tipografía, con el radio de las esquinas, con la sombra debajo de las tarjetas. La IA no tiene mal gusto. Tiene el gusto de la mediana de su entrenamiento.
Descriptivamente esto se arregla fácil: si le apuntas a algo tuyo en vez de describirle lo que quieres, clona lo tuyo. Charlie Hills lo cuenta bien en su método de los cuatro archivos: un archivo con tus reglas, un archivo con cómo se construye, una carpeta con cinco cosas que ya te gustaron. Dejó de describirle a la IA el diseño que quería y le apuntó a uno que ya tenía.
Ahí empecé yo. Y ahí me estrellé.
¿No basta con darle un archivo con mis reglas de marca?
Esa es la parte que nadie te cuenta, y me costó descubrirla en mi propio repo.
Yo no tenía cero archivos de reglas de marca. Tenía tres. Y se contradecían entre sí.
El más viejo definía el azul de la marca en un tono. El de mayo definía otro, mandaba títulos en mayúsculas con el peso más grueso disponible, y se declaraba a sí mismo "la fuente de verdad para agentes al generar interfaz nueva". El de agosto, escrito cuando rediseñamos el sitio, decía lo contrario: títulos en serif y caja baja, y prohibía explícitamente el peso que el anterior exigía.
Lo peor no era que dijeran cosas distintas. Era que usaban las mismas palabras para cosas distintas. El token ink significaba gris oscuro en un archivo y azul profundo desaturado en el otro. Un agente que leyera los dos producía piezas que se veían de dos marcas diferentes, y ninguno de los dos archivos estaba equivocado desde su propia lógica.
Los tres seguían en el repo. Ninguno apuntaba a los otros. Y el archivo de mayo, el que ya estaba desactualizado, era el único que un agente encontraba por nombre.
Un archivo de reglas de marca no se rompe porque esté mal escrito. Se rompe porque el código sigue avanzando y el archivo se queda quieto.
Te dejo algo gratis para arrancar. La estructura de carpetas, los prompts y las plantillas que uso con clientes para montar su primer agente están en gabrielneuman.com/como-instalar-claude-code. Es gratis y no pide tarjeta.
¿Cómo saco mis reglas del trabajo que ya me gustó?
No las inventes. Sácalas de lo que ya hiciste y te funcionó.
Junta cinco piezas tuyas que te hayan gustado: una landing, una portada, un carrusel, la sección de tu sitio que sí quedó. Ábrelas y anota los valores reales. No "azul corporativo", sino el código hexadecimal exacto que usaste. No "tipografía moderna", sino el nombre de la fuente, el tamaño y el interlineado.
Después escribe tres cosas que un archivo de referencia necesita y casi nunca tiene:
Para qué sirve cada color, no solo cuál es. En el mío, el azul es para vínculos y detalles; el azul profundo es para bloques oscuros grandes; el acento cálido existe solo para botones de alta intención sobre fondo oscuro, porque un botón azul sobre fondo azul no se ve. Esa última frase vale más que el código hexadecimal.
Cinco cosas que tu marca nunca hace. Las mías: nada de gradientes en superficies grandes, nada de sombras, nada de fotos de stock, nada de emojis decorativos en los títulos, nada de color de la semana. Las prohibiciones guían más que los permisos, porque la IA por defecto hace todo lo que no le prohibiste.
Un ejemplo completo, descrito. Una pieza tuya explicada de arriba abajo: qué hace bien y por qué. Es lo que convierte una carpeta de capturas en un sistema.
Si esto te suena a lo que ya haces con el texto, es lo mismo. Yo tengo desde hace meses un archivo con las palabras que mi marca no usa, y lo aplico en cada pieza de contenido. Lo escribí porque la IA escribía en argentino y yo escribo en mexicano.
Ese archivo no vive suelto: vive dentro de una carpeta que la IA carga sola cuando le toca escribir. Si nunca has visto cómo se ve un skill por dentro, es exactamente eso — instrucciones tuyas empaquetadas para que no las tengas que repetir. Lo visual es la misma idea, aplicada a los colores en vez de a las palabras.
¿Por qué la IA ignora el archivo aunque se lo des?
Porque un archivo que el modelo tiene que acordarse de leer es una promesa, y las promesas se rompen.
En mi repo tengo una regla marcada como crítica desde hace meses: todo vínculo interno lleva diagonal final, porque sin ella el servidor responde una redirección y eso se multiplica por las quinientas páginas del sitio. La regla está escrita en mayúsculas, en el archivo de instrucciones que la IA carga en cada sesión.
Ese archivo es el que la mayoría trata como si fuera magia. Ya escribí antes sobre las doce reglas que hacen que sirva y sobre por qué el tuyo probablemente te está mintiendo. Todo eso sigue siendo cierto, y aun así:
El error volvió tres veces en un mes.
No porque nadie leyera la regla. Volvió porque el cambio entró por lugares donde nadie estaba leyendo nada: un merge, un script generador, una edición desde el editor. Dejó de volver el día que se convirtió en un check automático que revienta el pull request.
Esa es la pieza que le falta al método de los cuatro archivos, y es la que más trabajo me ha ahorrado.
Un gate es código que revisa tu trabajo aunque el modelo se distraiga. Hay dos tipos y la diferencia importa:
- Si el error solo puede entrar cuando alguien escribe un archivo, un enganche al momento de escribir basta.
- Si el error puede entrar sin que nadie escriba ese archivo, hace falta un check que revise el árbol completo. Este es el caso que casi todos se saltan.
Lo aprendí de la manera cara. Mi documentación interna apuntaba a veinticuatro archivos de código que ya no existían. Nadie la había editado mal: habíamos reorganizado el código y la documentación se quedó quieta. Un enganche al escribir nunca se hubiera enterado, porque nadie escribió nada.
Así que escribí dos checks. Uno revisa que ningún archivo nazca fuera del sistema visual. El otro revisa que ninguna ruta citada en la documentación esté muerta.
¿Qué encuentras el día que enciendes el gate?
Más de lo que quieres, y ese es justamente el punto.
El primer check, corrido sobre todo el sitio, encontró 2,586 hallazgos en 266 archivos. No eran falsos positivos. Era la deuda real: doscientas noventa y cinco páginas escritas antes de que existiera un sistema, cada una con el diseño copiado y pegado adentro. Cambiar el radio de una esquina significaba editar ciento noventa y cinco archivos.
Ahí tomé la decisión más importante de todo esto: el check en integración continua revisa solo los archivos que toca cada cambio, no el sitio completo. Si hubiera fallado sobre los 266, habría bloqueado todo desde el primer día y alguien lo habría apagado en una semana. Un gate que grita en todo es ruido, y el ruido se apaga.
El segundo check encontró algo mejor. Me atrapó a mí, cuatro veces, en el mismo cambio en el que lo estaba escribiendo. Una de esas veces alcanzó a colarse: borré un archivo y dejé el mapa apuntándole, y el check me lo devolvió antes de que llegara a la rama principal.
También destapó dos errores viejos que llevaban meses invisibles. Uno: mi configuración declaraba una tipografía serif que la aplicación nunca cargaba, así que todo el texto que yo creía en esa fuente venía cayendo a la de respaldo del sistema. Un valor puede estar declarado y no existir en la realidad. El otro: un botón con fondo de marca sin color de texto explícito, ilegible sobre fondo claro.
Ninguno de los dos lo encontró una persona. Los encontró el check el día que existió.
¿Vale la pena si mi sitio todavía no tiene tráfico?
Voy a ser honesto con esto, porque es la pregunta que yo me hice.
Mi sitio lleva 307 clics en dieciséis meses. Con ese número, rediseñar mejora la conversión de un tráfico que todavía no existe. Lo escribí así en mi propio registro cuando lo hicimos, para que nadie dentro de tres meses lo leyera como una palanca de crecimiento. No lo es.
Lo hice de todos modos por una razón distinta: es donde aterrizan los que sí llegan, y sobre todo porque cada pieza que produzco después sale del sistema. La portada de este post, el carrusel que va a LinkedIn, la próxima landing. El sistema no me trajo tráfico. Me quitó la discusión con la IA sobre las fuentes, que me costaba horas por pieza.
Si estás empezando, ese es el orden que yo seguiría: primero las reglas sacadas de tu trabajo real, después el gate, y la migración de lo viejo por olas cuando haya con qué medirla.
Lo que no haría es lo que hice al principio: acumular archivos de reglas sin nada que los verifique. Terminas con tres, contradiciéndose, y cada uno convencido de ser la fuente de verdad.
¿Quieres armar el tuyo con tu caso concreto? Si ya usas IA para producir y estás cansado de pelearte con el resultado, agenda una llamada de diagnóstico. Son treinta minutos, sin costo, y salimos con el mapa de qué archivo te falta y qué gate te ahorraría más tiempo.
El método de los cuatro archivos que menciono arriba es de Charlie Hills. Lo que agrego aquí es la capa del gate, que salió de mi propio repo y de haber visto la misma regla romperse tres veces.
