Cuatro de nueve
El 3 de septiembre revisamos las nueve apps que se publicaron ese día con wanno. Era una revisión de rutina: abrir cada una, mirar la primera pantalla, anotar qué funcionaba y qué no.
El color variaba bien entre una y otra. La tipografía también. El radio de los bordes, el espaciado, el tono de los textos: todo distinto. El header, no. Cuatro de las nueve mostraban exactamente la misma composición.
Un cuadrado con esquinas redondeadas a la izquierda, relleno con un degradé verde y un icono blanco encima. Al lado, el nombre de la app en negrita. Debajo, un subtítulo en gris. A la derecha, un botón. Una app para reservar clases de gimnasio, un catálogo de plantas, un panel para llevar gastos y una web de una cafetería. Productos distintos, pedidos distintos, el mismo arranque de página.
Si has usado cualquier builder de apps con IA, ya conoces esa composición. Es el header. El que aparece en cada demo, en cada captura de Twitter, en cada landing generada en treinta segundos. Nosotros también lo estábamos produciendo, y no teníamos claro por qué.
Lo primero que sospechas es del modelo
Es la explicación cómoda y tiene algo de verdad. Los modelos tienen costumbres. Piden un header y devuelven ese header, igual que piden un botón y devuelven uno azul con rounded-lg. Otros builders con el mismo pedido producen la misma composición, y eso parecía cerrar el caso: no es nuestro problema, es el modelo.
Pero había una señal que apuntaba a nosotros. La clase CSS que dibujaba ese degradé verde no la había inventado el modelo en cada app. Aparecía con el mismo nombre en las cuatro, y ese nombre venía de nuestro template.
Eso cambiaba la pregunta. Ya no era "por qué el modelo hace siempre lo mismo", sino "qué le estamos dando nosotros antes de que empiece". Y cuando miramos eso con cuidado, encontramos dos cosas.
Dos cosas que le dábamos para empezar
Cuando alguien describe su app, wanno no le pasa el mensaje al modelo tal cual. Antes hay un plan, que estructura el pedido, y un template, que es el proyecto base sobre el que el agente escribe. Los dos existen por buenas razones. Los dos estaban empujando hacia el mismo header.
El plan era un menú. Para ayudar al modelo a decidir cómo arrancar la página, el plan le ofrecía ocho formas de header con nombre: "hero con icono", "barra con logo y CTA", "título centrado", y así. La idea era darle vocabulario. El efecto fue otro. Una lista de opciones se convierte en un menú, y un modelo frente a un menú elige del menú. Casi siempre la primera opción, o la que más se parece a lo que ya vio mil veces.
El template tenía una estética terminada. Nuestro proyecto base no era un esqueleto neutro. Traía un degradé definido como clase, dos sombras con nombre y una animación de entrada marcada como "recomendada" en un comentario. Todo eso estaba ahí para que las apps se vieran bien desde el primer segundo, y funcionaba: se veían bien. Pero el modelo no estaba decidiendo cómo se vería la app. Estaba ensamblando piezas que ya venían con la decisión tomada.
Juntas, las dos cosas hacían que el camino de menor resistencia fuera siempre el mismo: elegir el header del menú, rellenarlo con el degradé del template, ponerle la sombra recomendada. Cuatro de nueve.
Qué cambiamos
La regla que nos quedó cabe en dos frases:
El template entrega un sustrato, nunca una estética. Sus comentarios describen mecánica, nunca preferencias.
Dicho más simple: el proyecto base tiene que darle al modelo las herramientas para construir, no la casa ya amueblada. En la práctica fueron tres cambios.
- Le quitamos el estilo al proyecto base. Fuera el degradé, fuera las sombras, fuera la animación de entrada. Quedó un lienzo en blanco con las reglas de cómo pintar: dónde se define un color, cómo se elige una tipografía. Qué color y qué tipografía, eso lo decide el modelo para cada app.
- Cambiamos el tono de las notas internas. El proyecto base tiene notas para explicarle al modelo cómo funciona cada cosa. Varias sonaban a consejo: "usa esta sombra para las tarjetas", "animación recomendada para la portada". Un consejo escrito ahí el modelo lo lee como una orden. Ahora las notas solo explican qué hace cada pieza, sin opinar.
- Dejamos de ofrecerle un menú. Las ocho formas de header con nombre desaparecieron. En su lugar le pedimos que describa la primera pantalla con palabras de quien la visita: qué ve al llegar, qué entiende primero, qué puede hacer. El diseño sale de esa descripción, y no de una lista.
El tercer cambio fue el que más discutimos. Sin menú, el modelo tenía que diseñar solo, y no sabíamos si lo haría bien. La alternativa era seguir dándole el menú y aceptar que todas las apps se parecieran. Preferimos probar y medir.
Qué medimos después
En las primeras cuatro apps publicadas después del cambio hubo cero degradés, cero cuadrados con icono y tres formas distintas de header. La cuarta app directamente no tenía header: era una lista de turnos que arrancaba en la lista.
| Antes (9 apps, 3 sep) | Después (4 apps) | |
|---|---|---|
| Header con la composición repetida | 4 | 0 |
| Degradé del template | 4 | 0 |
| Formas de header distintas | 6 | 3 (+1 sin header) |
El caso que más nos interesaba era el pedido explícito. Cuando alguien escribió "agrega un header", sin más, obtuvo una línea fina arriba, el título de la app y un enlace. Sin icono, sin subtítulo gris, sin botón a la derecha. El modelo, sin menú, eligió lo mínimo que resolvía el pedido.
Cuatro apps no son una muestra; son una señal. Lo que sí sabemos es que el header repetido no volvió a aparecer en las semanas siguientes, y que ninguna de las apps nuevas se ve peor que las de antes. Se ven distintas entre sí, que era el punto.
La regla que nos quedó
Sirve para cualquier sistema que le da contexto a un modelo, no solo para builders de apps. Antes de agregar una estructura (una lista de opciones, un ejemplo, un default con nombre, un "recomendado"), pregúntate si es un andamio o un menú.
Un andamio le da al modelo algo donde apoyarse sin decidir por él: el sistema de tokens, la forma de declarar un color, el contrato que tiene que cumplir. Un menú le da opciones cerradas, y el modelo va a elegir una de ellas aunque ninguna sea la correcta para ese pedido. La diferencia no está en la intención con la que lo escribiste; está en si el texto describe un mecanismo o expresa una preferencia.
Las webs hechas con IA se ven iguales porque todas arrancan del mismo menú. El modelo tiene sus costumbres, sí, pero la mayor parte del problema está en lo que le damos nosotros antes de que escriba una línea. Y eso sí lo podemos cambiar.