El proceso de diseño no está muriendo. Está dejando de escalar.
Durante años, una parte de mi trabajo ha sido nombrar y estructurar capacidades core para explicar por qué, en diseño, algunas personas mueven resultados (no sólo pantallas) y otras se quedan atrapadas en ejecución. En mi caso, eso se tradujo en un modelo, un curso de Capacidades Estratégicas que di durante 2025 y un curso en con eje en las capacidades del diseñador con IA que actualmente está activo.
Con equipos builder y con IA acelerando la ejecución, el marco de diseño se vuelve todavía más relevante: el proceso tradicional no es “malo”, pero hoy se estresa rápido.
Por “no escala” me refiero a esto: sube el retrabajo por drift (deriva entre intención, design system y código en producción), la coordinación se vuelve cuello de botella y el ciclo idea → validación se alarga justo cuando el contexto exige acortarlo.
Qué entiendo por contexto builder (y qué no)
No hablo de una realidad homogénea para toda la industria. Hablo de presiones de frontera que ya están empujando al resto.
Uso “builder” como atajo para ese conjunto de presiones y prácticas: equipos en tecnologías de IA, incluyendo muchas startups con foco tecnológico y equipos de aceleración internos, que tienen ciclos de diseño y código muy cortos e integrados, shipping continuo, procesos de diseño maduros (DS integrados a código y a IA, por ejemplo) y alta autonomía. Las presiones concretas son:
- más velocidad de ejecución por IA, agentes y codegen
- más variabilidad por experimentación continua
- más riesgo de incoherencia cuando el sistema no tiene guardrails fuertes
La consecuencia organizacional es la que subraya Ignasi Boza: si diseño “vive dentro del código”, el límite entre diseñar y construir se vuelve borroso. Y la consecuencia operativa es la que describe Jenny Wen: el rol se desplaza desde producir mocks hacia acompañar ejecución, pairing, pulir en código, y sostener dirección de corto plazo (3–6 meses) para evitar que el equipo construya cosas aleatorias.
Para hacerlo concreto: hace dos años, prototipar un onboarding funcional tomaba semanas de coordinación entre diseño e ingeniería. Hoy, con codegen y agentes, puede salir en días. Esa misma aceleración hace que el drift, la incoherencia y el retrabajo por falta de criterios también lleguen mucho más rápido.
En ningún caso planteo esto como receta universal. En contextos regulados o de baja cadencia, el cambio existe, pero su ritmo y forma son distintos.
Cuatro señales que están contando la misma historia
En mi proceso cotidiano de leer y oír señales de la industria, en pocos días encontré cuatro miradas distintas que convergen:
- Jenny Wen (Head of Design en Claude) dice que el “proceso de diseño” tratado como dogma está “básicamente muerto”, porque ya no hay tiempo para “bocetos lindos” y el rol se desplaza hacia ayudar a ejecutar, cohesionar y decidir.
- Ignasi Boza explica el quiebre de paradigma: si el diseño vive dentro del sistema y el canvas es una vista del software, el handoff deja de ser central. Lo que diseñas es lo que se ejecuta.
- Nurkhon lo enmarca como cambio de skills: no gana quien “optimiza herramientas”, gana quien “entrega outcomes“. La brecha está en criterio, juicio y capacidad de operar el trabajo end-to-end.
- Nate Jones, desde una mirada vinculada al desarrollo, habla de nuevas capacidades para integrar IA en procesos de trabajo y su marco, aunque no habla de diseño, está muy alineado con la necesidad de repensar cómo diseño encaja ahí. Formaliza el cambio como disciplina: “prompting” se divide en capas (context, intent, specification, eval/constraints), y el diferencial real pasa por diseñar artefactos operables (SPEC, intent layer, eval harness, constraint architecture). Aunque muchas de sus afirmaciones son un tanto extremas y a veces al borde del clickbait, su lógica de las capas de pensamiento me parece muy útil.
Estas cuatro opiniones claramente no son representativas del estado actual de toda la industria. Son señales de frontera, pero es justamente lo que hacemos cuando tratamos mirar hacia adelante para intentar proyectar el futuro.
Con eso en consideración, mi lectura: el proceso de diseño no “muere”. Lo que muere es la ilusión de que un flujo lineal de discovery → mock → handoff → build puede seguir siendo la unidad principal de trabajo cuando construir es más barato, continuo y delegable.
El cambio real: de entregables a sistema operable
En ese mundo, el trabajo valioso no es “generar artefactos” con IA. El trabajo valioso es evitar que la velocidad destruya el sentido.
Lo que une con más fuerza a estas cuatro opiniones no es “IA”, sino el tipo de trabajo que ahora se necesita:
- Antes: el diseño funcionaba como una cadena de entregables (mocks, flows, specs visuales) que otros traducían.
- Ahora: el diseño funciona como un sistema operable que permite construir rápido sin perder coherencia, calidad ni intención.
En la práctica, eso significa que cada vez más la unidad de valor deja de ser una tarea aislada (diseñar pantallas, escribir copy, preparar presentaciones) y pasa a ser un flujo:
- intención y criterios al inicio
- ejecución distribuida (humanos + agentes + herramientas)
- guardrails que previenen errores “smart-but-wrong“
- evaluación continua para sostener calidad y confianza
Nate Jones lo hace tangible cuando insiste en que las disciplinas “compuestas” se convierten en artefactos: un documento de contexto, una especificación real, un framework de delegación/intención y un eval harness.
Y Jenny lo hace tangible cuando explica que su tiempo se movió desde hacer mocks hacia el trabajo emparejado con desarrolladores y hacia sostener dirección mientras el equipo hace delivery.
La tesis: diseño en contexto builder es diseño de operación
Mi conclusión es simple, pero incómoda para el paradigma anterior:
En equipos builder, diseñar ya no es principalmente producir representaciones del producto. Es diseñar y operar el sistema que convierte ideas en software coherente.
Eso no significa que craft, research o exploración desaparezcan. Significa que:
- cambian su proporción
- cambian su timing
- cambian su formato (menos “fase”, más “capacidad integrada”)
Y esto conecta con una idea que viene rondándome hace años: muchas “core skills” estratégicas no son un plus, son el núcleo del rol cuando la ejecución deja de ser el problema. Ahora estas capacidades pasan de “diferenciadoras” a “infraestructura mínima”.
Las capacidades del diseñador con IA que se vuelven no negociables
Aquí es donde las cuatro fuentes convergen con claridad: el cambio de proceso exige nuevas capacidades, no “nuevas herramientas”.
1. Dirección e intención operable
Jenny dice que la visión ya no puede ser “dos años, cinco años, diez años”; se vuelve 3–6 meses y muchas veces se expresa como prototipo que orienta, no como deck.
Traducción builder:
- construir dirección suficientemente clara para que el equipo no optimice localmente
- definir qué importa, qué no, qué trade-offs se aceptan
- transformar estrategia en criterios que guían decisiones diarias
Esto es “intent engineering” en el sentido de Nate: codificar propósito, jerarquías de trade-offs y límites de decisión para que la ejecución no se desvíe.
2. Especificación y definición de “done”
Cuando la ejecución es rápida, la ambigüedad se vuelve cara. Los equipos no fallan por falta de capacidad de construir; fallan por falta de claridad sobre qué construir y qué significa que esté bien.
Nate empuja esta idea con fuerza: la especificación (SPEC.md, acceptance criteria, decomposition) define el “techo de calidad” cuando delegas trabajo a agentes.
Jenny lo expresa desde el rol: “al final alguien tiene que decidir qué se construye y qué importa; alguien tiene que ser accountable”.
3. Arquitectura de restricciones y guardrails
En un entorno donde cualquiera puede prototipar “algo que funciona”, la coherencia depende de restricciones explícitas:
- design system vivido en código
- principios, patrones y anti-patrones
- “must / must-not” para evitar resultados técnicamente correctos pero conceptualmente errados
Nate lo llama constraint architecture: el documento que previene el fallo “smart-but-wrong” cuando delegas.
Jenny lo aterriza cuando habla de equipar a ingenieros con principios y con el design system en code (ella es de Anthropic, pero piensa en Codex o equivalentes), porque Claude no siempre toma el DS.
4. Evaluación y loops de calidad
Esto es el corazón del cambio.
Ignasi sugiere que la noción de fidelidad cambia porque no hay “versión más real” que la que corre o se ejecuta.
Si eso es cierto, entonces la calidad no se protege con “fidelidad” sino con evaluación:
- evaluar en condiciones reales (usuarios, datos, modelos reales)
- aceptar lanzamientos tempranos con promesa explícita de iteración (trust through speed)
- sostener feedback loops visibles para que la marca no se degrade
Jenny lo plantea directo: lanzar temprano no destruye confianza si iteras y respondes. Lo que destruye confianza es lanzar y que “nada pase”: no responder al feedback y convertir el MVP en estado final.
Nate lo vuelve método: construir un eval harness, test cases, criterios, y revisitar tras updates de modelos.
5. Orquestación de flujos (el skill que une todos los demás)
Este punto es el que yo veo como el verdadero salto builder:
Antes, “escribir”, por ejemplo, podía ser una tarea. Hoy, escribir bien en serio es un flujo: borrador → edición → estilo/voz → SEO (si aplica) → adaptación por canal → evaluación final con criterios definidos desde el inicio.
Ese patrón se generaliza:
- diseño de producto: framing → dirección → constraints → build → QA UX → medición → iteración
- research en AI: hipótesis → experimentos con modelos reales → observación → ajustes rápidos
- design systems: tokens/variables → componentes → linting/guardrails → gobernanza
Esto es, en esencia, pasar de un rol que produce entregables a un rol que diseña y gobierna un pipeline.
Un marco para entender la transición sin caricaturas
Jenny hace una distinción que me parece muy útil: el trabajo se estratifica en dos tipos. Yo lo describiría así para el contexto builder:
- Trabajo de ejecución y cohesión: pairing con ingeniería, “last mile” de craft, evitar drift y conectar piezas, mantener consistencia mientras se construye rápido.
- Trabajo de dirección y sentido: visión de corto plazo (3–6 meses), prototipos orientadores, decisión sobre qué importa y qué se construye.
Esto ayuda a evitar dos errores comunes:
- Pensar que “discovery murió”. Sólo cambia de forma y timing.
- Pensar que “diseño ahora es code”. El núcleo sigue siendo operar intención y calidad; el código es un medio que se vuelve más accesible y lo hace posible.
El diseño que queda es el que sostiene decisiones
Si tuviera que resumir esta narrativa en una frase personal, sería esta:
Durante años pensaba en las capacidades estratégicas como un diferenciador. Hoy se están volviendo el requisito mínimo para seguir siendo relevante cuando el producto se construye a velocidad builder. Las Builder Skills para Diseñadores.
En este contexto, “diseñar” es:
- decidir qué importa
- codificar intención en criterios operables
- construir restricciones que preserven coherencia
- diseñar evaluación que sostenga calidad y confianza
- orquestar flujos completos (humanos + agentes + herramientas)
La pregunta para quienes estamos en diseño no es “¿qué herramienta uso?”. Es:
- ¿qué parte del sistema de producción de valor estoy diseñando?
- ¿qué criterios estoy poniendo para que el sistema no se rompa cuando acelera?
- ¿qué evaluación voy a usar para saber si estamos mejorando, y no sólo haciendo delivery?
Y si esto suena exigente, lo es. Pero también es una buena noticia: en un mundo donde construir es cada vez más fácil, el rol se desplaza hacia lo que siempre ha sido más difícil: juicio, dirección y responsabilidad por decisiones.
Estas son algunas de las reflexiones sobre capacidades del diseñador con IA que trabajamos en el curso de IA para Diseñadores: cómo traducir intención en criterios operables, cómo reducir retrabajo con guardrails y cómo sostener calidad mientras el equipo acelera.
Si quieres trabajar estas capacidades aplicadas a tu propio contexto —con ejercicios, frameworks y casos reales ¡inscríbete!
