Cuando decidimos reconstruir la web de MM Shopy Devs, nos marcamos un objetivo más exigente que "que quede bonita". Queríamos paridad de píxel con nuestros diseños de Figma, un CMS a medida que todo el equipo pudiera usar, tres idiomas y una IA (Claude) haciendo el trabajo pesado de la construcción. Nuestra propia web se convirtió en el banco de pruebas de un flujo de trabajo que ahora usamos con clientes.
Este es un relato honesto de lo que funcionó, lo que falló y lo que le diríamos a cualquiera que intente lo mismo. También es una respuesta honesta a quienes siguen afirmando "lo construimos en Claude con unos pocos prompts". Creednos: no es el caso.
Primer paso: el CMS
El primer paso fue construir el propio CMS, con controles de backend y un editor visual. Nuestro equipo vive y respira Liquid, así que lo usamos como lenguaje de plantillas base.
Los resultados fueron excepcionales. Claude hizo un trabajo realmente impresionante construyéndolo, pero podemos garantizar que no fue cosa de "unos pocos días". Hicieron falta muchísimas iteraciones y pasos. Y aquí viene lo interesante: esta ni siquiera fue la parte técnicamente más compleja del proyecto. Sí, hay que estar preparado técnicamente, saber exactamente qué pedir y tener un conocimiento de 360 grados del campo. Pero el verdadero reto llegó después.
Segundo paso: diseño y testing
Todo empieza en Figma, exactamente igual que en nuestros proyectos de diseño web Shopify, construido como un sistema de diseño real: componentes, variantes y variables, no frames sueltos. Nuestra diseñadora UX construye desktop y móvil como diseños separados y deliberados, con sus propias escalas tipográficas.
¿Por qué Figma y no Claude Design? Simple: queríamos reproducir lo que nuestros clientes reales de Shopify van a exigir, es decir, consistencia y un sistema de diseño escalable, y hoy solo Figma puede ofrecerlo.
La idea suena sencilla: Claude lee el archivo directamente a través de la API de Figma y su integración MCP, y lo construye en el CMS. En la práctica, este fue el verdadero reto y donde pasamos la mayor parte del tiempo probando, iterando y volviendo a probar.
También fue donde nuestra diseñadora UX tuvo que trabajar más duro. No en cómo se veían los diseños, sino en cómo estaban construidos. Pasamos por muchos ciclos de exportar e importar al CMS para verificar qué puede leer Claude realmente, qué no, y dónde hacían falta correcciones.
Componentes es la palabra clave. Para construir con precisión, lo más importante son los componentes y cómo están estructurados. Después descubrimos que la forma en que un diseño está construido técnicamente importa muchísimo: qué está contenido dentro de qué, cómo está configurado cada contenedor, etcétera. Sinceramente, muy pocos diseñadores llegan a este nivel de detalle al construir en Figma. En nuestra experiencia es realmente poco común. Pero al trabajar con IA, la jerarquía de elementos y las reglas de estilo correctamente aplicadas son de los factores clave para que Claude entienda cómo debe comportarse cada elemento.
Luego llegan las anotaciones, otra herramienta esencial que permite decirle a Claude "este elemento debe comportarse así y asá, necesita este conjunto de controles", etcétera. Sin anotaciones, Claude está ciego. Pero cuidado: es muy fácil que una anotación contradiga el diseño, y nunca deben usarse como atajo para no configurar el diseño correctamente.
Podríamos escribir un artículo entero solo sobre lo que descubrimos en esta etapa. En resumen: esto no es un proceso lineal de diseñar y entregar. El diseñador debe saber exactamente lo que hace y corregir el rumbo sobre la marcha.
Primer reto: el resultado difiere del diseño
Aquí es donde más nos golpeamos la cabeza. El diseño es perfecto, Claude tiene toda la información correcta y puede leerlo todo. Entonces, ¿por qué lo que construye es diferente?
Tenemos que ser honestos: no encontramos la forma de eliminarlo. Claude siempre se desviará del diseño, a veces en un porcentaje pequeño, a veces mayor.
¿Cómo lo resolvimos? "Fácil": construimos un sistema de puertas de QA. Claude construye, después la construcción se revisa contra el diseño (y creednos, esta puerta ejecuta cerca de cien reglas y comprobaciones), después los errores se corrigen automáticamente y, por último, se rastrea el origen de cada error y se convierte en una nueva regla para que no pueda repetirse en la siguiente construcción.
Suena simple. Solo este punto nos llevó semanas de pruebas hasta clavarlo. Lo construimos de forma que, tras cada primera construcción, podemos medir el porcentaje de diferencia respecto al diseño, y os garantizamos que nunca está por debajo del 10%. Sin una puerta de QA adecuada (una compleja, que combine varias metodologías de QA), Claude sencillamente no es preciso.
Algunos lectores pensarán: un 10% está bien. Depende. Nuestros desarrolladores son pixel perfect, y los clientes con los que trabajamos esperan exactamente eso. Una desviación del 10% repartida por todas las páginas crea una cascada de feedback e incidencias que no nos podemos permitir.
Segundo reto: código caótico
Esto es lo que más nos asustó cuando empezamos a leer el código real que producía Claude.
Descubrimos algo interesante: una página puede ser pixel perfect respecto al mockup y parecer impecable a primera vista. Pero abres el código y te encuentras todo hecho con CSS inline, o cientos de clases creadas una por elemento. Para quien no lo sepa: visualmente, esto produce el mismo resultado. Técnicamente, es un desastre enorme y una catástrofe de rendimiento.
La razón es bastante simple: Claude no puede estandarizar los design tokens por ti si tú no lo has hecho primero. Esto conecta con las reglas de diseño, pero va más allá. Todo el diseño debe usar design tokens, con propiedades estandarizadas como variables.
Y esto es lo que más nos preocupó. Nosotros somos expertos y lo detectamos rápido. Pero de todos los que están construyendo sitios en producción con Claude, estamos bastante seguros de que la mayoría no está revisando esto.
Lo que realmente aprendimos
La IA no es el sistema de calidad. El proceso lo es. Claude es notablemente rápido y realmente bueno traduciendo un archivo de Figma bien estructurado a código limpio. Pero velocidad sin puertas de control solo produce respuestas erróneas más rápido. La combinación que funciona es: un archivo de diseño disciplinado, una IA que lee datos en lugar de imágenes, comprobaciones automáticas que no negocian y un humano que sigue revisando cada página contra el mockup.
Causas raíz por encima de parches. Cuando algo se rompía, rastreábamos la causa estructural y arreglábamos eso, normalmente convirtiéndolo en una nueva puerta de control. Parchear síntomas es la forma en que una base de código se pudre en silencio.
Los sistemas de diseño rinden por partida doble. Cada hora que nuestra diseñadora dedicó a componentes y variables limpios en Figma ahorró varias veces ese tiempo en la construcción, porque un input limpio es la mayor palanca de calidad en el output de la IA.
La web ya está en marcha, trilingüe, gestionada desde el CMS y verificada al píxel, y el mismo pipeline se está convirtiendo en la base de cómo construimos para clientes. Si eres una marca o una agencia pensando en construcciones asistidas por IA, escríbenos y hablamos de cómo aplicarlo a tu proyecto.
