Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

Empecé a trabajar mis proyectos con agentes de IA usando Codex, y después llegó Claude Code. Al poco me di cuenta de que, proyecto tras proyecto, le estaba diciendo al agente lo mismo una y otra vez. Que no commitee en main. Que revise en móvil antes de dar algo por hecho. Que deje escrito qué hizo y por qué. Que antes de diseñar decida la paleta y la tipografía, no a mitad de un componente. A eso se sumaban las librerías y las skills de otros que iba encontrando: una muy buena para diseñar interfaces, otra para animar con GSAP, otra para 3D… Cada una funcionaba bien por su cuenta, pero no se conocían entre ellas. Yo era el pegamento, copiando y pegando instrucciones de un proyecto a otro. Así que decidí juntarlo todo en un recopilatorio en el que las piezas se ayudaran entre sí. Lo llamé dev-standards, porque era literalmente eso: mis estándares de trabajo. Hoy se llama Senzu. Y por el camino me siguieron pasando cosas como estas, todas en la misma semana: Prettier, con su configuración por defecto, le metió 204 punto y coma a un archivo de un proyecto que no los usa. El agente lo dio por bueno. El instalador de mis propias normas vació el .mcp.json de un proyecto Laravel y se llevó por delante un servidor MCP que estaba configurado. El agente me dijo que había verificado la web en móvil. Las capturas existían, sí: en una carpeta temporal que yo nunca iba a abrir. Un loader y una barra de carga «centrados». A ojo lo estaban. Midiendo, no. Y mi favorita: yo daba por hecho que Codex no ejecutaba hooks. Sí los ejecuta. Lo que pasaba es que mis hooks no entendían cómo Codex describe una edición, así que dejaban pasar todo sin decir nada. Ninguna de estas cosas es grave por separado. Juntas, son la diferencia entre fiarte del agente y tener que revisarle cada línea. Ahí está el problema de fondo. Puedes escribir en el CLAUDE.md o en el AGENTS.md que no se commitea en main, que se verifica en móvil antes de cerrar una tarea o que no se toca el .env. El agente lo lee. Y casi siempre lo cumple. «Casi siempre» no vale cuando es un proyecto de verdad. Por eso el recopilatorio no se quedó en un montón de instrucciones: lo que podía ejecutarse, lo convertí en algo que se ejecuta, no que se lee. Y el nombre: si viste Dragon Ball de pequeño, ya sabes por qué Senzu. Una semilla y el proyecto se recupera. Un paquete para Claude Code y Codex, en castellano, con tres piezas que trabajan juntas: Skills: las mías y las de otros proyectos (con su autor y su licencia), con una capa en castellano encima. El agente carga solo la que toca: diseño de interfaz, calidad de código, DDD, animación, despliegue… Un enrutador decide cuál leer según lo que pides y en qué orden: primero se decide el diseño y después se elige el efecto, no al revés. Así no se llena el contexto de cosas que no vienen al caso. Muros (hooks): no aconsejan, bloquean. Si el agente intenta algo que no debe, la acción no se ejecuta y le explican por qué. Comandos: /plan, /verificar, /brief, /propuestas… atajos para flujos que repito en todos los proyectos. Así se ve un muro cuando salta: [BLOQUEADO por Senzu] No se commitea en 'main'. Crea una rama (git switch -c feat/...) y commitea ahí. Hace unos días bloqueó al propio agente que me estaba ayudando a sacar la última versión de Senzu, cuando intentó commitear donde no debía. Ahí es cuando sabes que funciona. Son dieciséis, pero hay unos cuantos que se ganan el sueldo cada semana: guard: nada de git push sin que yo lo apruebe en ese momento, nada de rm -rf, de borrar la base de datos ni de desplegar a producción por las buenas. Para saltárselo hace falta una variable explícita y mi aprobación, y la norma es dejarlo apuntado en el devlog. secrets-guard y protect-files: el agente no escribe claves reales en el código (las de AWS, Stripe, OpenAI… se reconocen por su forma) ni toca el .env, las migraciones ya aplicadas o los archivos que se generan solos. stop-guard: este es mi favorito. El agente no puede dar la tarea por terminada si editó código y no pasó el build, el lint y los tests, si tocó la interfaz y no la verificó en móvil, o si no dejó escrito el devlog del día. Se acabó el «ya está» sin pruebas. backend-guard: bloquea migraciones que borran o renombran columnas de golpe (primero se añade lo nuevo y luego se quita lo viejo) y datos personales escritos en los logs. code-hygiene: fuera los console.log, los dd() y los .only olvidados en los tests. Y algo más, que cuento en el diseño. conventions-guard: en un proyecto que ya existe, /adoptar analiza cómo está escrito de verdad, lo pactamos y lo sella. A partir de ahí, el código que se salga de esas reglas no entra. Manda la convención del proyecto, no la del agente. Y uno que no bloquea pero que agradezco cada día: el formateo al guardar no impone estilo. Si el proyecto no tiene configuración del formateador, no formatea, y si al formatear cambian más líneas de las que tocó el agente, lo deshace y avisa. Lo de los 204 punto y coma no ha vuelto a pasar. Son más de cuarenta, pero el agente casi nunca carga más de una o dos por tarea. Las que más trabajan: ui-ux-pro-max (de Next Level Builder): la puerta de entrada de todo lo visual. Antes de escribir una línea de interfaz decide estilo, paleta, tipografía y patrón según el negocio y el stack, y lo deja guardado en un design system del proyecto. Encima lleva mi capa: perfiles para Laravel con Inertia, Next, Astro y Vue, y las guías de diseño que cuento más abajo. front-activation: el catálogo de efectos. Más de noventa, cada uno con su receta por stack, su versión para «reducir movimiento» y su coste en móvil. Pides «un marquee de logos» y el agente abre solo esa receta, no un manual entero. code-quality: buenas prácticas por lenguaje y un verify-build que entiende monorepos y lanza el lint, los tipos, los tests y el build de lo que has tocado. project-planner: /plan convierte una feature en fases y tareas pequeñas, cada una con la skill que toca y cómo se verifica. Luego /siguiente va una por una. backend-audit: audita el backend con herramientas de verdad, y cada hallazgo lleva su prueba: la salida del comando, el archivo y la línea, o un test que falla. Nada de «podría mejorarse la arquitectura». Para animación y 3D (GSAP, Three.js, React Three Fiber…) uso las de Claude Design Skills, también con su capa en castellano. Cada proyecto tiene un devlog (qué se hizo, por qué y cómo se verificó) y un archivo de memoria corto con las decisiones vigentes: D-012 · Esto se decidió así · ver entrada 063. Un hook lo inyecta al empezar cada sesión. Si el agente va a contradecir una decisión, tiene que citarla y preguntarme. Para lo que no está en la memoria hay un buscador sobre el devlog que entiende raíces, erratas y sinónimos. Parece poca cosa. Es la diferencia entre explicar dos veces por qué no usamos tal librería o no tener que explicarlo nunca más. Aquí es donde más se nota que las piezas se conocen entre ellas. 1. Primero pregunta. Si no hay brief ni design system, el primer intento de tocar la interfaz se bloquea. El agente tiene que preguntar antes: qué hace el negocio, qué tiene que hacer el visitante, si hay marca, y dos o tres webs que te gusten. La entrevista va en lenguaje llano (/brief), sin palabras como «hero» o «CTA», porque no todo el mundo habla así. 2. Estructura antes que estética. Con eso escribe un blueprint: las secciones de la página con texto real y, en cada una, qué cambia en móvil. Hasta que no lo apruebas, no se diseña nada. 3. Dos maquetas que se pueden abrir. /propuestas genera dos direcciones opuestas de verdad, en HTML que se abre con doble clic. Cada decisión lleva una etiqueta (A·T1 es la tipografía de la maqueta A, B·B2 los botones de la B…) y un panel «Tu opinión» para votar Sí o No pieza a pieza y copiarlo al chat. 4. Rondas. /ronda hace la siguiente: lo que te gustó queda fijado en todas las maquetas, lo que no te gustó desaparece y cada maqueta trae algo nuevo. Un verificador comprueba antes de enseñártela que se ha respetado todo eso. 5. Los vetos se cumplen. Lo que dices que no te gusta va a un archivo gustos.md. Y aquí vuelve code-hygiene: si vetaste un color o un carrusel, el agente no puede volver a escribirlo. Lo mismo con una lista negra de cosas que delatan una web hecha con IA, como los badges de «disponible», las secciones numeradas «01 / 02 / 03», el «trusted by» con logos en gris o las métricas inventadas. Están bloqueadas por defecto. 6. Construye sección a sección, enseñando cada una antes de pasar a la siguiente. Y cuando el logo ya está elegido, sus archivos finales quedan protegidos y el agente no se pone a hacer bocetos que nadie le ha pedido. Y al final, verifica. Esta parte nació del loader descentrado. «Debería verse bien» no es verificar, así que el verificador de interfaz ahora mide en píxeles: si algo que su contenedor centra está a 4 px del centro, te lo dice, con la causa probable (un margin-left: 8px que sobraba, por ejemplo). Lo calibré contra webs reales para que no fuera una máquina de falsos positivos. Empezó dando entre 33 y 41 avisos por página y lo dejé en 0-2. De paso encontró algo de verdad: en vuejs.org, un icono de play que está 3 px descentrado dentro de su propio SVG. En móvil hace lo que yo hacía a mano: abre el menú de verdad. Lo pulsa, mide si los enlaces se pueden tocar con el dedo, prueba que se cierra con Escape y te deja una captura con cada aviso numerado encima de su elemento. La cifra y la imagen, juntas. No todo son muros. Senzu también trae un catálogo de efectos con recetas por stack (Astro, Next, Vue con Inertia), y hace poco le pedí algo concreto: que la web se viera normal y de repente se partiera como un cristal. La demo, a media velocidad para que se vea algo: en tiempo real dura menos de un segundo. Lo que se rompe es la propia página, no una imagen encima. Cada trozo es una copia del DOM recortada con clip-path a la forma del cristal. Por eso se lee el texto real, nítido, mientras cae girando en 3D. Sin capturas de pantalla y sin librerías. Y con reglas, porque un efecto así puede acabar siendo un circo: una vez y con intención, se salta con Escape, quien tiene activado «reducir movimiento» solo ve un fundido, y al terminar no queda nada en el DOM. Tiene sus pruebas automáticas en un navegador real, como todo lo demás. En Claude Code: /plugin marketplace add petersonsenadevs/senzu /plugin install senzu-all@senzu En Codex se añade el mismo marketplace desde la app. Luego, en tu proyecto, abre una sesión y escribe /instalar: detecta el stack, te pregunta qué quieres (todo, por categorías o a medida) y lo deja listo. Repositorio: github.com/petersonsenadevs/senzu Documentación: getsenzu.vercel.app Lo que no es Es opinado: son mis normas de trabajo, no las de todo el mundo. Lo puedes adaptar (los muros se apagan por proyecto y los permisos se cambian), pero parte de cómo trabajo yo. Está en castellano, a propósito. Hay muchísimo para agentes en inglés y casi nada pensado para quien trabaja en español. Y no hace que el agente deje de equivocarse. Se sigue equivocando. La diferencia es que ahora se entera antes que yo. Es MIT. Usa skills de otros proyectos, cada una con su autor y su licencia en CREDITOS.md. Cada semana comprueba si esos proyectos han cambiado y me abre un PR para revisarlo. Si lo pruebas, me encantará saber qué muro le pondrías tú a tu agente. Seguro que hay alguno que se me ha escapado.