🖼️ Interfaces: el agente que ve

"¿Nuevo por aquí? El front-end es la parte visual de un sitio o una app: los botones, colores, textos y diseño que aparecen en pantalla. Lo opuesto es el back-end, que se ejecuta oculto en el servidor." El agente escribe ambos, pero el front-end es lo primero que evalúa el cliente/usuario.

Sin este término claro, el resto de la ruta («skill de diseño», «screenshot») no tiene sentido — el front-end es el objetivo de todo lo que viene después.

Front-end, back-end, lo que el usuario ve frente a lo que se ejecuta detrás.

El agente aprendió viendo millones de páginas en internet. Sin una dirección específica, reproduce el patrón más frecuente, que tiende al promedio, no a lo excepcional.

Entender la causa evita la frustración: no es que «el agente sea malo para el diseño», sino que «necesita orientación, como alguien que acaba de empezar».

Regresión a la media, falta de dirección, «apariencia de IA» como síntoma.

Gris claro sobre gris oscuro, sombras genéricas, esquinas demasiado redondeadas, íconos de cohetes y estrellas por todas partes, degradado morado y azul: la «firma visual» que cualquiera reconoce de lejos como hecha por IA sin curaduría.

Saber reconocer el síntoma te ayuda a pedir una corrección específica en vez de «hazlo más bonito» (lo que no ayuda al agente a decidir nada).

Patrones reconocibles, comentarios específicos frente a vagos.

Por defecto, el agente lee y escribe texto (código); no abre la página en el navegador para "mirar" el resultado, a menos que tú —o una herramienta adicional— lo pidas explícitamente.

Esta es la brecha que cierran los módulos 5.2 y 5.3: darle al agente instrucciones de estilo (skill de diseño) y visión (ciclo de screenshots).

Escribir código a ciegas, sin feedback visual de forma predeterminada.

Sin nada, el resultado llega aproximadamente al 40% del camino hacia «parece profesional». Con una skill de diseño + un ciclo de screenshot, se acerca al 60%. El 40% final requiere criterio humano — no es un bug que haya que corregir, es tu trabajo.

Una expectativa realista evita dos trampas: rendirse pronto («no se puede hacer bien») o confiar demasiado («el agente lo resuelve solo»).

Ganancia parcialmente automatizable, límite estructural, papel del criterio humano.

Skill de diseño → ciclo de capturas de pantalla → límites del ciclo → referencia visual/rebranding → carpeta de marca → build de landing page publicada → reglas de publicación.

Ver el camino completo ayuda a entender por qué existe cada módulo antes de llegar a él.

Progresión: formar el gusto, dar visión, probar límites, aplicar la marca, publicar con reglas.

Una skill es un archivo de instrucciones que el agente carga cuando el pedido coincide con ellas (se ve en la Ruta 3). Una skill de diseño guarda tus preferencias visuales para todos los proyectos de front-end.

Sin esto, vuelves a escribir «usa colores sobrios, tipografía limpia» en cada conversación nueva — la skill elimina esa repetición.

Skill, reutilización entre proyectos, memoria de preferencias.

Paleta de colores preferida, fuentes aprobadas, reglas de espaciado ("nunca juntes elementos sin dejar espacio"), tono visual (sobrio, divertido, corporativo) y qué evitar (degradado morado-azul, ícono de cohete).

Cuanto más concreta sea la instrucción, menos probable será que el agente vuelva al promedio genérico del módulo 5.1.

Paleta, tipografía, espaciado, lista de "cosas que no hay que hacer".

Una skill de diseño «global» está en una carpeta que sirve para todos tus proyectos; una «de proyecto» está solo dentro de ese repositorio específico (tema que se estudia a fondo en Trilha 3.5).

Tu gusto personal (la tipografía que te gusta, por ejemplo) es global; la marca de un cliente específico corresponde a cada proyecto.

Alcance global, alcance del proyecto, cuándo usar cada uno.

Objetivo: generar el archivo de skill con tus preferencias de diseño. Bloque para copiar: "Crie uma skill global chamada 'meu-design' com estas preferências: paleta <suas cores>, fonte <sua fonte>, tom <sóbrio/divertido>. Evite gradiente genérico e ícones de foguete." Cómo verificar: pídele al agente que enumere el contenido del archivo de skill creado y comprueba que coincida con lo que pediste.

Es el ejemplo práctico que reúne la teoría de los temas anteriores en un resultado que puedes usar hoy mismo.

Prompt para crear una skill, verificación del archivo generado.

Cada vez que corriges algo que salió mal, conviene volver a la skill y agregar esa regla; por ejemplo: «nunca uses este color de fondo con este texto».

La skill mejora proyecto a proyecto; sin ese hábito, repites siempre el mismo error.

Iteración, aprendizaje acumulado, edición incremental.

La skill da instrucciones sobre el estilo, pero el agente sigue escribiendo a ciegas: no ve el resultado. Falta el paso de verificación visual, tema del próximo módulo.

Entender esta brecha evita pensar que la skill lo resuelve todo: es la mitad de la solución.

Instrucción y verificación, las dos partes de la solución.

Uno servidor local es un pequeño programa que muestra la página solo en tu computadora (una dirección tipo localhost) — como un ensayo antes de publicar de verdad para todo el mundo.

Es el primer paso del ciclo: si no levantas este servidor, no hay una página que fotografiar.

Servidor local, localhost, entorno de ensayo.

Uno screenshot es una captura de la pantalla en ese instante. Con la herramienta adecuada (un navegador automatizado), el propio agente toma esa captura de la página que acaba de construir.

Es esta captura la que transforma «escribir código a ciegas» (módulo 5.1) en «ver el resultado antes de entregártelo».

Captura de pantalla, navegador automatizado, feedback visual.

El agente compara la captura de pantalla con un "objetivo": puede ser la skill de diseño (módulo 5.2), una imagen de referencia (módulo 5.5) o una checklist descriptiva ("texto legible, botones alineados, espacio entre secciones").

Sin un objetivo claro, «comparar» se convierte en una opinión vaga — el objetivo es lo que hace que la corrección sea objetiva.

Objetivo de comparación, criterio objetivo, lista de verificación visual.

Después de corregir, el agente vuelve a iniciar el servidor, toma otra captura de pantalla, vuelve a comparar y repite hasta cumplir el criterio o agotar un número razonable de intentos.

Esta repetición es lo que diferencia un resultado de «primer intento, sin revisión» de uno «verificado antes de entregártelo».

Iteración, ciclo de cerrar-probar-corregir, límite de intentos.

Objetivo: hacer que el agente construya y verifique visualmente una página por su cuenta. Bloque para copiar: "Crie uma landing page para <seu produto>. Suba um servidor local, tire um screenshot, compare com a skill de design e corrija até ficar consistente antes de me mostrar." Cómo verificar: pídele al agente que te envíe (o describa) la captura de pantalla final y comprueba que coincida con lo solicitado.

Es el momento en que la teoría de los módulos 5.1/5.2 se convierte en acción: el ciclo se ejecuta de principio a fin.

Prompt del ciclo completo, verificación del resultado entregado.

Skill (gusto) + ciclo (visión) juntos corrigen errores evidentes: texto cortado, botón fuera de lugar, poco contraste; pero por sí solos no deciden si algo «es bonito» de verdad.

Prepara para el módulo 5.4, que detalla exactamente qué no resuelve el lazo.

Errores graves vs. criterio fino, ganancia automatizable.

Texto cortado de la caja, elementos superpuestos, botón sin espacio para hacer clic, contraste de color que dificulta la lectura: cosas que se pueden verificar de forma objetiva en la imagen.

Conocer la fuerza del loop evita que lo descartes: sí resuelve una gran parte de los errores molestos.

Error objetivo, verificable mediante una regla, ruptura estructural.

"¿Este color combina con la marca?", "¿este espaciado se ve elegante o vacío?", "¿este texto suena confiable?": preguntas de gusto que dependen del contexto, el público y la sensibilidad humana.

Es exactamente la parte que te queda — los «40% finales» mencionados en el módulo 5.1, aquí explicados de verdad.

Juicio subjetivo, contexto de marca, sensibilidad humana.

Sin un objetivo claro (módulo 5.3), el agente puede entrar en un ciclo intentando satisfacer un criterio vago y no detenerse nunca — por eso siempre conviene acordar un número máximo de intentos.

Evita gastar tiempo y dinero innecesariamente en un loop que nunca converge.

Loop sin criterio de detención, límite de intentos, costo.

Una página puede verse bien en el tamaño de pantalla probado y fallar en un celular o en una pantalla grande: el ciclo solo verifica lo que realmente se capturó.

Lleva a pedir explícitamente capturas de pantalla en más de un tamaño cuando el resultado realmente importa.

Diseño adaptable, varios tamaños de pantalla, cobertura de pruebas.

Incluso después de que el ciclo se ejecute y «apruebe» su propio resultado, el veredicto de «está listo para publicar» sigue siendo tuyo: el agente reduce el trabajo, no sustituye la decisión final.

Cierra el criterio honesto de la ruta: la automatización ayuda, pero no te quita la responsabilidad de revisar el resultado tú mismo antes de publicarlo (conexión directa con el módulo 5.8).

Aprobación humana final, automatización para reducir el esfuerzo, no para sustituir el criterio.

Una forma de reducir la subjetividad del módulo 5.4 es mostrar, en lugar de describir, lo que quieres: dándole al agente una imagen de referencia.

Es el enlace al siguiente módulo, que enseña exactamente esta técnica.

Mostrar vs. describir, imagen de referencia.

"Estilo minimalista y elegante" significa cosas diferentes para cada persona; una imagen de referencia elimina esa ambigüedad de una vez.

Es la forma más rápida de reducir la distancia entre lo que imaginas y lo que entrega el agente.

Ambigüedad del lenguaje, referencia visual como ancla.

La mayoría de los agentes de código acepta imágenes adjuntas en la conversación o la ruta de un archivo PNG/JPG guardado en el proyecto — el agente «lee» la imagen junto con el texto de la solicitud.

Sin conocer el mecanismo, la técnica de «mostrar» se queda en teoría.

Adjuntar imagen, ruta del archivo, lectura multimodal.

Sitios de galerías de diseño, un competidor que admiras o incluso una captura de tu propio material anterior: cualquier imagen real que refleje el estilo que buscas.

Tener un repertorio de referencias listas acelera cualquier pedido de diseño futuro.

Colección de referencias, selección personal.

"Rebranding" es actualizar la identidad visual de algo que ya existe. La misma referencia visual sirve aquí: muestra la nueva dirección y pide que la apliquen sobre lo que ya está listo.

Rara vez empiezas desde cero: la mayoría de las veces estás actualizando algo que ya existe.

Cambio de marca, actualización sobre una base existente.

Objetivo: guiar el resultado con una imagen en vez de solo palabras. Bloque para copiar: "Anexei uma imagem de referência (<caminho da imagem>). Recrie o layout dessa referência para <seu conteúdo>, mantendo a mesma sensação visual — cores, espaçamento e tom." Cómo verificar: compara lado a lado la captura de pantalla final con la referencia adjunta.

Es la aplicación directa de la técnica «mostrar en lugar de describir» con un resultado verificable.

Prompt con adjunto, comparación lado a lado.

Una referencia de estilo («esta vibra visual») es diferente de copiar contenido, logotipo o identidad de otra marca. Pedir que se inspire en algo es diferente de pedir que lo clone.

Te protege de un problema legal y ético antes de publicar cualquier cosa.

Inspiración frente a copia, identidad de terceros.

Una carpeta dentro del proyecto (o global) con los archivos del logo, la paleta de colores exacta y las fuentes utilizadas: la única fuente de verdad de tu identidad visual.

Sin ella, cada proyecto nuevo reinventa (mal) el logo o el color de la marca de memoria.

Fuente única de verdad, activos de marca, coherencia.

Guardar el código exacto del color (tipo #0d9488) en lugar de "ese verde azulado"; el agente usa el valor correcto sin adivinar.

Un color «casi correcto» rompe la consistencia de la marca de forma sutil, pero visible para quien la conoce.

Código hexadecimal de color, precisión vs. aproximación.

Nombre exacto de la fuente (y dónde descargarla), además de las versiones del logo (con fondo claro, oscuro y solo el ícono), listas para usar sin tener que recrearlas.

Evita que el agente «invente» una fuente parecida o distorsione el logo al intentar recrearlo desde cero.

Nombre exacto de la fuente, variaciones del logo listas para usar.

La skill de diseño (módulo 5.2) puede apuntar directamente a la carpeta de marca. Así, el gusto personal (skill) y la identidad específica de un cliente (carpeta) trabajan juntos sin conflicto.

Cierra la arquitectura: la skill global indica el «cómo hacerlo» y la carpeta de marca, el «con qué».

Skill que hace referencia a una carpeta, separación entre gustos e identidad.

Objetivo: organizar tus recursos de marca en un único lugar de consulta. Bloque para copiar: "Crie a pasta 'marca/' com um arquivo marca.md listando: cor primária <hex>, cor secundária <hex>, fonte principal <nome>, e onde estão os arquivos do logo." Cómo verificar: abre el archivo generado y comprueba que todos los valores coincidan con los tuyos.

Transforma la teoría de los temas anteriores en una carpeta que usarás en el próximo módulo de build.

Archivo marca.md, verificación de valores.

Con una skill de diseño, un ciclo de screenshots, una referencia visual y una carpeta de marca listos, tienes todo para construir y publicar una landing page de verdad.

Marca la transición de la teoría al proyecto práctico que cierra la ruta.

Herramientas listas, transición a la build.

"Landing page" es una página única de presentación (para un producto, servicio o proyecto personal): las secciones típicas son encabezado, qué es, cómo funciona y una llamada a la acción.

Definir el alcance antes de pedirlo evita idas y vueltas: el agente sabe exactamente el tamaño del proyecto.

Landing page, secciones típicas, alcance definido.

Antes de pedir el build, comprueba que la skill de diseño (5.2) esté activa, que la carpeta de marca (5.6) esté lista y que tengas a mano una referencia visual (5.5), si quieres.

Juntar los insumos antes evita pedir el build "a medias" y tener que corregirlo después.

Lista de verificación de insumos, preparación antes del pedido.

Objetivo: construir toda la landing page en un único pedido bien formulado. Bloque para copiar: "Usando a pasta 'marca/' e a skill de design, crie uma landing page para <seu produto/projeto> com seções: topo, o que é, como funciona, chamada para ação. Suba servidor local, tire screenshot, compare com a skill e corrija antes de me mostrar." Cómo verificar: revisa la captura de pantalla final y comprueba que estén las 4 secciones y que se haya aplicado la marca.

Es el ejercicio que reúne todo lo que la ruta enseñó hasta ahora en un resultado tangible.

Pedido completo, verificación con una lista de secciones.

Después de que el agente apruebe su propio ciclo, es tu turno: revisa el resultado con atención y pide ajustes específicos según tus preferencias (no «mejóralo», sino «este color de fondo se ve demasiado pesado»).

Es la aplicación práctica del límite explicado en el módulo 5.4: el juicio fino es tuyo.

Comentarios específicos, revisión humana final.

Deploy es el proceso de sacar la página del «ensayo» en el servidor local y ponerla en línea, con una dirección accesible para cualquiera; tema que se profundiza en la Ruta 4.

La landing page solo cumple su función cuando alguien de fuera puede acceder a ella.

Deploy, dirección pública, conexión con la Trilha 4.

La implementación está lista cuando está en línea, no tiene errores visuales graves, tiene la marca aplicada y tú —no el agente— confirmas que está bien.

Sin un criterio para detenerse, el perfeccionismo paraliza el proyecto — y el módulo 5.8 detalla las reglas antes de publicar de verdad.

Criterio de finalización, evitar el perfeccionismo paralizante.

Aunque puedas borrar una página después, alguien ya pudo haberla visto, guardado o compartido; publicar es, en la práctica, una acción irreversible.

Justifica por qué esta ruta termina con reglas explícitas en vez de dejarlo al sentido común.

Acción de una sola vía, cautela antes de lo irreversible.

La misma técnica del Recorrido 0.4: escribir «nada se publica sin mi aprobación explícita» en el CLAUDE.md del proyecto para que el agente lo lea siempre, en cada sesión nueva.

Una regla dicha una vez se pierde; una regla escrita se lee en cada conversación nueva.

Regla persistente, CLAUDE.md, aprobación explícita.

Antes de aprobar: revisa la captura final, comprueba la ortografía y los enlaces, confirma que no aparezcan datos personales o sensibles por error y prueba en al menos otro tamaño de pantalla.

Una checklist objetiva evita aprobar algo a simple vista y con prisa.

Lista de verificación de revisión, datos sensibles, varios tamaños.

Confirma que no haya quedado visible ninguna contraseña, clave de API o información privada en el código de la página publicada (tema de "Secretos", Trilha 4.4).

Una página bonita con un secreto filtrado es peor que una página fea sin filtraciones: la revisión de seguridad va antes que la estética.

Filtración de secretos, prioridad sobre la estética, conexión con la Ruta 4.

Objetivo: establecer permanentemente la regla de aprobación en el proyecto. Bloque para copiar: "Adicione ao CLAUDE.md a seção: 'Publicação — nunca fazer deploy ou publicar qualquer página sem antes me mostrar o resultado e receber minha aprovação explícita.'" Cómo verificar: abre el CLAUDE.md y confirma que la sección se agregó, palabra por palabra.

Es el ejercicio final que deja establecida de forma permanente la regla más importante de la ruta.

Regla permanente en el archivo, verificación literal del texto.

Con la interfaz visual construida, verificada y publicada con reglas claras, la Trilha 6 cambia el enfoque: de «lo que construye el agente» a «cuándo trabaja solo, sin que se lo pidas».

Cierra la ruta con claridad sobre el siguiente paso: programación y bucles.

Transición de trilha, de "construir" a "programar".