Si alguna vez te has dado un paseo por un PAU (Programa de Actuación Urbanística (se abre en una pestaña nueva)) en Madrid (Sanchinarro, Las Tablas, Valdebebas… elige tu “barrio dormitorio”), sabes a qué me refiero. Sobre el plano, el urbanista se coronó: avenidas de seis carriles, cuadrículas perfectas, edificabilidad al milímetro. Un triunfo de la geometría. Pero a pie de calle, sobre todo en sus primeros años, la cosa era otra: distancias enormes, avenidas donde el viento te congelaba y muy poca vida en la calle.
Hoy muchos de estos barrios tienen vida, pero gracias a la gente que vive en ellos y que los ha ido transformando, no al plano. Cumplían toda la normativa técnica, sí. Pero se olvidaron de un pequeño detalle: diseñar para que la gente viva ahí.
Como arquitecto, vi este error muchas veces. Ahora, como diseñador de producto, lo empiezo a ver en el software.
Hace poco me embarqué en la comunidad de Raúl Marín (se abre en una pestaña nueva) en Shift+R (se abre en una pestaña nueva), y ahí nos enseñó esta pedazo de charla (se abre en una pestaña nueva) de Katie Dill (Head of Design en Stripe). Ella compara el boom actual de la IA con el pelotazo inmobiliario que hubo tras la Segunda Guerra Mundial: tanta prisa por construir que se levantaron edificios clónicos, baratos y sin alma. Hoy estamos construyendo los PAUs del software, pantallas llenas de lo que Katie llama “Zombie UI” (interfaces zombi). Cosas que funcionan, que tienen sus bordes redondeados y sus sombritas, pero que están más muertas que un disquete.
Ryo Lu (del equipo de Cursor) lo explica muy bien en su artículo reciente Convergence to the mean (se abre en una pestaña nueva): cuando todos nos miramos a todos para decidir qué hacer, acabamos sin hacer nada propio. Copiamos lo que funciona y lo llamamos “buenas prácticas”. La IA quita toda la fricción a ese bucle. Pero, como dice Ryo, tener acceso a todas las referencias del mundo no significa tener un punto de vista. Si le pedimos a la IA que elija por nosotros sin aportar ninguna intención propia, obtenemos algo plausible, fácil de aprobar. Lo lanzamos, lo medimos, lo copiamos y vuelta a empezar. Resultado: lo que él llama a tidal wave of mid, un tsunami de mediocridad.
Un ejemplo de mi día a día
En PIX4Dcloud, los usuarios suben cientos de fotos de dron para generar mapas y modelos 3D. En el equipo siempre estamos buscando formas de mejorar esa experiencia, y gran parte de las ideas salen de escuchar a nuestros usuarios: dónde se atascan, qué les hace perder tiempo, qué les gustaría que el producto hiciera por ellos. Y la dirección apuesta claramente por la innovación para resolver esos problemas reales de nuestros clientes, también teniendo en cuenta las posibilidades que nos puede ofrecer la IA a partir de ahora. ¿Por qué no?
Por eso me hago mucho esta pregunta: ¿qué diferencia a un agente útil de uno zombi? Imagina un agente que ayuda a los usuarios a procesar sus vuelos.
La versión zombi te dice: “¡Tus imágenes se han subido correctamente! ¿En qué más puedo ayudarte?”. Rápida, correcta y totalmente inútil. Es lo que Katie llama “el dilema del burrito de microondas”: nos enamora tanto pasar de tener hambre a tener algo caliente en el plato en 90 segundos, que nos da igual que sepa a cartón.
La versión con alguien al volante se da cuenta de que en una zona del vuelo las fotos no tienen suficiente solape, y te avisa antes de que pierdas tiempo y créditos de procesado en un modelo con agujeros.
La diferencia no está en la pantalla. Está en todo lo que hay detrás. Por eso los diseñadores tenemos que dejar de ser “ensambladores de pantallas” y empezar a hacer de arquitectos. La infraestructura tiene que cambiar.
1. Del prompt castigador al contexto
Un system prompt estático (“eres un asistente útil, no alucines, sé educado”) es como la ordenanza municipal de un PAU: reglas rígidas para que no pase nada malo, pero que tampoco dejan que pase nada bueno. (Y spoiler: escribir “no alucines” en un prompt sirve de bastante poco.)
El problema no es el prompt. El problema es que el agente no sabe en qué situación está el usuario. ¿Tiene prisa? ¿Viene de un error? ¿Es la primera vez que usa el producto? Esa información le llega por el contexto: la memoria, el estado de la aplicación, el resultado de lo que acaba de hacer. A esto se le empieza a llamar context engineering, y aquí es donde tú inyectas tu intención. Decides a qué debe prestar atención el agente en cada momento.
2. Herramientas y fontanería
Darle autonomía a un agente sin darle herramientas (tools) es como hacer un rascacielos sin cañerías. Si no puede llamar a una API, leer datos del backend o lanzar un proceso, lo único que va a hacer es darte palique y pedirte disculpas como un robot roto, y siempre de manera muy educada.
Las “cañerías” las instalan los desarrolladores. Pero decidir por dónde pasan es trabajo de diseño:
- Qué acciones puede hacer el agente solo.
- Cuándo tiene que pedir confirmación al usuario.
- Qué se puede deshacer y qué no.
- Cómo enseña lo que ha hecho.
En un edificio nadie ve las tuberías, pero todo el mundo se entera cuando fallan.
3. Design Systems AI-Ready (o por qué Gutenberg era un crack)
Un sistema de diseño genérico es como un catálogo de piezas prefabricadas: con él solo puedes construir el mismo bloque una y otra vez.
Katie cuenta una anécdota increíble: cuando Gutenberg inventó la imprenta, no hizo solo 52 letras. Hizo unos 290 caracteres distintos, con ligaduras y anchos diferentes, para que la máquina justificara el texto y la página pareciera hecha a mano por un monje. Como dice Katie: el sistema de diseño de ayer escalaba consistencia; el de hoy tiene que escalar intención.
Necesitamos Design Systems AI-Ready: componentes que la máquina entienda (esquemas JSON, tokens semánticos) y guías de uso que pueda leer, no solo una documentación bonita para humanos. Porque la UI generativa no consiste en que el agente invente componentes nuevos, sino en que combine bien los que ya existen. Si tus piezas son genéricas, el agente construirá PAUs clónicos. Si tienen carácter, construirá algo que realmente huela a tu marca.
4. Guardrails: portero e inspector de obra
Antes, filtrábamos las malas ideas en las reuniones de producto. Hoy, como la IA te hace 20 ideas en una tarde, buena parte del filtro va después.
Por eso los guardrails tienen que trabajar en dos momentos. Antes, como el portero de discoteca: el sistema de diseño solo deja al agente usar componentes aprobados. Y después, como un inspector de obra: validadores automáticos que revisan si lo que el agente ha construido cumple la normativa antes de que el usuario lo vea.
Menos fábricas, más talleres
Ryo Lu lo resume muy bien: si podemos hacer casi cualquier cosa, decidir qué merece la pena que exista es más importante que nunca. La velocidad nos da más oportunidades de usar nuestro criterio, pero no nos quita la responsabilidad.
Nuestros usuarios no van a aplaudir porque un agente les monte un dashboard en dos segundos. Se van a quedar por esos pequeños detalles (una interacción inteligente, adelantarte a un problema, un tono de voz exacto) que demuestran que alguien se preocupó por ellos.
Ryo no quiere un mundo donde todos seamos distribuidores más eficientes de las mismas ideas. Yo tampoco quiero llenar internet de PAUs digitales. Prefiero usar estas herramientas para mancharme las manos, aportar mi punto de vista y hacer que en el software, aunque lo dibuje una máquina, se note que hay un humano al volante.