Por qué un manifiesto, no un portfolio
Un portfolio clásico responde a una demanda implícita: muéstrame lo que sabes hacer, y luego decidiré si me interesas. Este sitio parte de otro lugar. Busca hacer legible una postura: cómo pienso el design leadership, cómo formalizo métodos, cómo aprendo trabajando con agentes IA.
La diferencia cambia la fabricación. Un portfolio puede vivir sobre algunos casos bien pulidos. Un manifiesto tiene que sostener una voz, una arquitectura, pruebas y una capacidad de actualización. No basta con tener páginas bonitas. El sistema tiene que permitir seguir pensando en público sin rehacerlo todo cada vez.
Claude Code entró por esa puerta. No como una herramienta mágica para generar un sitio, sino como un binomio de ejecución capaz de ir rápido si la dirección estaba clara. Codex tomó el relevo después, con otro entorno y otras restricciones. El verdadero tema apareció muy rápido: cuando el agente puede producir mucho, la calidad de lo que se le da se vuelve el trabajo principal.
El code-first como aprendizaje público
El primer choque no fue técnico. Astro, Tailwind, MDX, GitHub, Vercel: cada pieza se aprende. El choque estaba en otra parte, en construir en público, sobre un repo real, con commits visibles, hooks que bloquean, errores que quedan en el historial.
Para alguien que no viene del desarrollo, el primer push Git no es un detalle. Hace visible una postura: aprender haciendo, aceptar que el aprendizaje deja huellas, no esperar a ser experta para probar. La frase que quedó de ese momento es simple: tenía miedo, fue magnífico.
Esa vulnerabilidad no fue decorativa. Le dio coherencia al sitio. No se puede defender la curiosidad como doctrina y esconder los lugares donde una sigue aprendiendo. El sitio tenía entonces que mostrar una capacidad, pero también una forma de volverse más capaz.
Salvaguardas antes que volumen
Las primeras semanas sirvieron sobre todo para instalar límites. No porque el proyecto fuera técnicamente complejo, sino porque un agente que va rápido también amplifica lo que está borroso. Sin salvaguardas, cada sesión redefine las convenciones, la voz, la estructura, la manera de publicar.
El sistema tomó forma por capas: una voz documentada, reglas de escritura, un scanner que señala los inicios de párrafo prohibidos y los marcadores demasiado automáticos, hooks Git, commitlint, Prettier, ESLint, Astro check, controles de paridad entre idiomas, y luego una CI que repite las mismas barreras.
Estas herramientas no reemplazan el juicio. Liberan atención. Cuando el linter vigila la sintaxis, cuando el scanner de voz recuerda los desvíos, cuando el build rechaza una página rota, la energía puede volver donde importa: el ángulo, la prueba, la decisión, la frase que de verdad carga algo.
Una pasada de craft, y luego un retiro
La fase de craft visual produjo varios ajustes que se quedaron: tipografía, ritmo, dark mode, transiciones, playground interno. También produjo una experimentación que no se quedó. La idea era apoyar una lectura activa: cuando alguien seleccionaba una frase, el sitio conservaba una huella local y la volvía a mostrar en la visita siguiente.
La intención era buena. Correspondía al contrato del sitio: leer, volver, reencontrar lo que había llamado la atención. Pero la implementación tocaba demasiado profundamente el texto renderizado. Para resaltar una selección, había que cortar el DOM, inyectar etiquetas, gestionar espacios, títulos y navegación entre páginas. Dos ciclos de corrección bastaron para mostrar el riesgo: residuos visuales, layout fragilizado, pérdida de estabilidad en páginas largas.
El componente fue retirado. No porque la idea fuera mala, sino porque su costo de mantenimiento superaba su valor. Esa decisión cuenta tanto como los componentes que se quedaron. El craft no es la acumulación de gestos visibles. También es saber retirar un efecto cuando pone en riesgo la primera calidad de un sitio editorial: seguir siendo legible.
Traducir, poner en línea, verificar lo real
A principios de agosto, el proyecto cambió de naturaleza. Mientras el sitio vivía en local, seguía siendo un taller. Cuando los contenidos pasaron al español y al inglés, el dominio se conectó a Vercel y la V1 salió en línea, se volvió una superficie pública. Ese cambio obliga a mirar los detalles de otra manera.
La puesta en producción reveló una lección simple: el build de producción manda. En desarrollo, los borradores siguen visibles para permitir la revisión. En producción, solo salen los contenidos publicados. El playground existe en local, pero se retira del build público. Lo que se ve en el navegador mientras se trabaja no es automáticamente lo que las demás personas verán en línea.
La capa SEO llegó dentro de esa lógica: canonical, hreflang, Open Graph, sitemap, robots.txt, llms.txt, datos estructurados. No como una capa de marketing añadida al final, sino como una manera de decirles correctamente a los motores qué es el sitio, en qué idiomas existen las páginas, y qué versiones no deben inventarse.
El bug que los checks verdes no vieron
Un incidente volvió el sistema más sólido. Las versiones españolas e inglesas de algunos templates habían quedado más pobres que la versión francesa después de una refactorización. Las traducciones estaban en paridad, el build pasaba, los checks estaban verdes. Sin embargo, las páginas no contaban visualmente lo mismo.
El problema no era la ausencia de control. Era el control equivocado para ese riesgo preciso. La paridad i18n verificaba las claves de traducción, no la forma de las páginas. El correctivo añadió entonces dos salvaguardas: un control que compara los templates [slug].astro entre idiomas, y un control que compara la estructura de las páginas generadas en dist/.
Esta parte resume gran parte del aprendizaje. Una salvaguarda solo prueba lo que se le pidió medir. Si la dirección tiene que sobrevivir a varias semanas de trabajo, varios idiomas, varios agentes y varias sesiones, tiene que volverse verificable.
Lo que este sitio prueba ahora
Unas semanas después de la puesta en línea, el sitio ya no es solo un relato de aprendizaje. Se volvió la prueba de su propio método. Los contenidos viven en colecciones MDX. Las páginas públicas se construyen desde una fuente clara. Las traducciones pueden llegar sin romper los slugs. La producción se verifica con un procedimiento documentado. Los errores descubiertos se convierten en tests.
Claude Code aceleró las primeras semanas. Codex sostiene ahora la continuación. Ese cambio no es un detalle de herramientas, dice algo del sistema: si el método solo se sostiene con un agente preciso, todavía no es un método. El tema sigue siendo la dirección: saber qué pedir, qué rechazar, qué documentar, qué probar, qué retirar. Un agente puede producir código. Solo, no sabe qué debe seguir siendo verdadero dentro de seis meses.
Ahí es donde el proyecto se vuelve interesante para el design leadership. El design-to-code no es solamente una nueva velocidad de producción. Es una nueva responsabilidad de encuadre. Cuanto más rápido ejecuta la herramienta, más visible se vuelve la calidad del sistema que la rodea.