Estás leyendo la prueba. Este portafolio —dos casos de estudio, una Bio, un blog en tres idiomas, analítica— pasó de un archivo de Figma a un sitio en vivo en dos días de trabajo. No porque yo tipeara más rápido, sino porque cambié quién hace qué. Acá está exactamente cómo se construyó, incluyendo lo que salió mal.
Primero Figma, siempre
Cada pantalla que ves acá existió en Figma antes de que se escribiera un solo componente: el Home, las páginas de casos de estudio, la Bio, incluso el arte del hero de cada post del blog. Eso no es nostalgia por el lienzo. Es donde tomo las decisiones que importan —jerarquía, ritmo, qué mostrar y qué cortar— y es donde las apruebo, de un vistazo, antes de que alguien invierta tiempo en código.
La regla es simple: ¿página nueva, sección nueva, lenguaje visual nuevo? Figma, revisión, aprobación. Recién ahí, código.
El puente
La mitad del pipeline es BridgeUX, una herramienta que construí que le permite a un agente leer y escribir Figma desde la terminal: más de cien operaciones, desde "dame el padding exacto de esta tarjeta" hasta "clona este glow en cuarenta y siete nodos" hasta "exporta este frame como PNG".
Eso cambia lo que significa "pixel-perfect". Las tarjetas de proyecto del Home no se calcularon a ojo desde una captura de pantalla. El agente leyó el nodo de Figma —576 por 652, 32 de padding, un título bold de 21 puntos, una caja de métrica de 172 de ancho, 68 de aire antes de la imagen— y escribió el componente de React a partir de esos números. Cuando más tarde quise las tarjetas un poco más anchas, el cambio fue en el otro sentido: ajustar en código, reflejar en Figma, una fuente de verdad en cada dirección.
Quién hace qué
Esta es la parte que todo hiring manager realmente quiere saber.
El agente escribe los componentes, conecta las rutas, traduce el contenido al español y al portugués, convierte treinta imágenes a WebP, construye el favicon a partir del propio glifo de la tipografía, genera el sitemap y la vista previa social, y corre el build en el servidor.
Yo decido. Cuáles dos proyectos de quince años merecen un caso de estudio. Qué único número va en cada tarjeta. Que el dorado es el lenguaje visual y dónde se le permite aparecer. Que el post del blog "innovador" tenía que ser reemplazado por este. Cada cambio se revisa en la URL real, en escritorio y en el celular, antes de que yo diga "publica".
El principio sobre el que escribí en otro post aplica también a las herramientas: el modelo interpreta, el código ejecuta —y yo apruebo.
Nada está listo sin evidencia
La regla de trabajo que hizo posibles los dos días es la misma que uso en StratNova, el SaaS de WhatsApp que estoy construyendo con un equipo de agentes: nunca código en mi laptop. El código fuente vive en el servidor, el agente lo edita ahí, lo construye ahí, y cada afirmación de "listo" viene con prueba: una captura de la página en vivo, un curl mostrando un 200, una fila de base de datos mostrando que el evento de analítica llegó.
"Debería funcionar" no es evidencia. "Lo reinicié" no es evidencia. Esto suena pedante hasta que ves a un agente declarar victoria con total confianza sobre una página que renderiza en negro.
Los números
Dos días. Dos casos de estudio con treinta imágenes. Tres idiomas, cien por ciento traducidos, incluyendo las notas escritas a mano. Una Bio, un CV descargable, un favicon, vistas previas sociales, un sitemap. Analítica respetuosa de la privacidad. Todo eso en unos 180 KB de JavaScript, con las páginas de casos cargadas bajo demanda.
Lo que salió mal
Porque un making-of sin fallas es marketing:
- El favicon que no quería cambiar. Una regla vieja de Cloudflare solía redirigir este dominio a un prototipo de Figma, así que los navegadores tenían cacheado el rayo morado de Figma como "mi" ícono. El ícono nuevo se sirvió correctamente durante una hora antes de que alguien pudiera verlo. Solución: un
favicon.icofaltante, URLs versionadas, y paciencia. - Las capturas diminutas. La primera versión de las galerías de casos renderizaba pantallas de celular a 172 píxeles de ancho dentro de una caja de 1.200 píxeles. Era fiel a un layout que nadie había cuestionado. Un vistazo a la página real, una frase mía, un commit.
- El comentario que mató la hoja de estilos. Un comentario CSS que contenía los caracteres
*/dentro de su texto se cerró solo antes de tiempo y desactivó todas las reglas después de él. Sin error, solo una página sin dorado. Ahora el build verifica que los comentarios abren y cierran en cantidades iguales. - El build que no se publicó. Durante una tarde, el sitio en vivo estuvo sirviendo un build de las 15:47 mientras cada mejora vivía solo en la URL de desarrollo. El agente había hecho el trabajo; el paso de deploy había sido bloqueado por un prompt de permiso que nadie vio. La evidencia lo detectó: un diff entre las marcas de tiempo de dos
index.html.
Ninguno de estos fue un "error de IA". Fueron incidentes normales de ingeniería, encontrados de la manera normal: mirando la cosa real.
Por qué esto importa para un Senior Product Designer
Durante la mayor parte de mi carrera, la distancia entre una decisión de diseño y una pantalla publicada se medía en sprints. Ahora se mide en minutos, siempre que se cumplan dos cosas: que el diseñador pueda especificar con precisión —en Figma, en tokens, en una frase— y que alguien insista en evidencia antes de creer cualquier cosa.
Ese es el trabajo ahora. No dibujar más pantallas. Decidir mejor, especificar más ajustado, y verificar más duro. Las herramientas finalmente alcanzaron la forma en que yo quería trabajar. Este sitio es cómo se ve eso.