Hoy cualquiera puede pedirle a una IA “hazme una landing” y obtener algo presentable. El problema aparece al día 7: cuando hay que sumar una segunda página, un formulario, variantes de layout, tracking, y cambios de marca sin romper nada.

La IA puede generar UI. Pero un sitio real se sostiene en arquitectura: decisiones que controlan consistencia, escalabilidad y performance. Ahí es donde se gana o se pierde.

1) El problema típico: el “Franken-site”

Se ve bien en una pantalla, y se descompone al escalar.

Señales claras de un sitio sin arquitectura

• Cada página tiene estilos distintos “porque se generó diferente”.
• Tipografías y espaciados inconsistentes (no hay tokens).
• Componentes duplicados con nombres diferentes.
• CSS que “arregla” un caso y rompe otro.
• Lighthouse cambia sin control: scripts, imágenes, y bundles crecen.
• Nadie sabe dónde tocar sin miedo.

Resultado: el sitio se vuelve caro. No por diseño, sino por retrabajo.

2) Regla de oro: IA puede escribir código, pero tú debes definir el sistema

Regla de oro: Primero define el sistema (tokens, componentes, layout, performance budget). Después generas pantallas.

Si haces lo contrario (pantallas primero), el sitio se convierte en una colección de excepciones.

Lo que “define el sistema” en términos prácticos:

• Design tokens: tipografía, colores, espaciado, radius, sombras.
• Component library: botones, inputs, cards, headers, footers, modales.
• Layout primitives: contenedores, grid, breakpoints, spacing rules.
• Routing + IA: estructura de información y navegación.
• Performance budget: límites explícitos (JS, imágenes, third-parties).

3) Decisión crítica: estilos globales vs scoped (y por qué importa)

Esta es una de las decisiones que más rápido destruye consistencia si se toma mal.

Estilos globales (pros y riesgos)

Pros

• Consistencia inmediata (si hay tokens).
• Menos repetición.
• Más rápido para cambiar branding.

Riesgos

• Fugas: un cambio en una clase global rompe páginas no previstas.
• Difícil de depurar si no hay convención estricta.

Estilos scoped (por componente) (pros y riesgos)

Pros

• Aislamiento (menos “efecto dominó”).
• Componentes portables.
• Más fácil testear visualmente.

Riesgos

• Duplicación de reglas.
• Inconsistencia si no usas tokens.
• Cambiar branding requiere tocar muchos archivos.

La recomendación operativa (lo que funciona en equipos)

• Tokens globales + componentes scoped.
• Global solo para: reset, tokens, tipografía base, layout primitives.
• Scoped para: variaciones de componente y estilos contextuales.

Traducción: global para el “lenguaje”, scoped para las “frases”.

4) Ejemplo real: “IA generó 5 páginas, y en 2 semanas ya era ingobernable”

Contexto: sitio con home + pricing + about + blog + contact.
Se generó rápido con IA, cada página “bonita” por sí misma.

Problema: cambios de marca (nuevo color primario y tipografía) rompieron:

• botones con estilos distintos por página
• paddings inconsistentes
• layouts que no respetaban breakpoints

Solución arquitectónica (en 3 decisiones):

1. Definir tokens: --font, --color-primary, --space-1..8, --radius, etc.
2. Crear 12 componentes base: Button, Input, Card, Navbar, Footer, Section, Grid, Modal…
3. Performance budget + limpieza: eliminar duplicados, lazy-load, imágenes responsivas.

Resultado: el rediseño pasó de “re-hacer pantallas” a “cambiar el sistema”.

5) Performance: la arquitectura invisible que define conversión

La IA tiende a “resolver” agregando:

• librerías que no necesitas
• animaciones pesadas
• imágenes sin optimizar
• scripts de terceros sin control

Regla práctica: performance no se optimiza al final; se gobierna desde el inicio.

Performance budget mínimo (simple y efectivo)

• JS total en landing: objetivo < 200–300KB gz (según stack)
• 0–2 scripts de terceros críticos (el resto, bajo auditoría)
• Imágenes: siempre responsive + formatos modernos + lazy-load
• LCP objetivo: < 2.5s en móvil “real”

Checklist de arquitectura (para “sitio hecho con IA” que sí escala)

A) Sistema de diseño (no negociable)

• Tokens definidos (tipografía, colores, spacing, radius)
• 10–15 componentes base reutilizables
• Convención de variantes (size, intent, state)
• Documentación mínima: “cómo usar / cómo no usar”

B) Estilos globales vs scoped

• Global: reset + tokens + typography base + layout primitives
• Scoped: estilos de componentes y variantes
• Prohibido: estilos “por página” sin tokens (solo excepciones justificadas)

C) Consistencia y mantenimiento

• Nomenclatura estándar (componentes, rutas, clases)
• Librería única (no duplicar Button 5 veces)
• Revisión de UI (visual QA / snapshots si aplica)

D) Performance (budget y control)

• Definido budget de JS y third-parties
• Imágenes optimizadas (sizes, lazy, format)
• Medición recurrente (Lighthouse/CrUX si aplica)
• Evitar “features” no medibles (animaciones sin objetivo)

E) Analítica (sin esto no hay “mejora”)

• Eventos base: view, CTA click, form start, submit, error
• Naming convention de eventos
• Dashboard con 1 métrica primaria + guardrails

Conclusión

El mito es pensar que “hacer un sitio con IA” es un problema de pantallas. No lo es. Es un problema de arquitectura: decisiones sobre sistema de diseño, estilos, consistencia, performance y medición. La IA acelera la producción. La arquitectura asegura que el resultado sea mantenible y rentable.

Si me dices tu stack (Next.js/Svelte/Webflow/etc.) y el tipo de sitio (landing, ecommerce, SaaS), te armo una arquitectura base: tokens, componentes mínimos, convención de estilos (global vs scoped) y performance budget listo para implementar.