Introducción

Últimamente tengo la sensación de que, como diseñadores, nos estamos yendo hacia la sobreingeniería con la IA.

Gran parte de la conversación gira en torno a terminal, scripts, Claude, MCP o Code Connect. Todo parece pasar por montar pipelines, automatizar fuera de la herramienta o construir capas adicionales encima del flujo de trabajo.

Y no digo que eso no tenga valor. Lo tiene. Pero cada vez veo más una especie de reflejo automático: aparece una fricción en el proceso y la respuesta inmediata es buscar una capa técnica para resolverla.

Mientras tanto, estamos ignorando algo bastante evidente.

El punto ciego

Seguimos tratando el archivo de Figma como si fuera inevitablemente manual, frágil y tedioso de mantener.

Todavía asumimos que trabajar con variables, nombres, modos o colecciones implica esfuerzo repetitivo, desorden y mucha disciplina manual.

Y claro, cuando eso pasa, la reacción habitual es bastante predecible:

• crear scripts
• montar pipelines
• conectar APIs
• externalizar lógica

El problema no es hacer eso. El problema es hacerlo demasiado pronto.

Porque lo curioso es que Figma ya está integrando IA directamente en el propio archivo para resolver buena parte de estas tareas. No como una capa externa, sino como parte del sistema.

Lo que ya puedes hacer dentro de Figma

Aquí es donde creo que la conversación se queda corta.

Hoy ya puedes hacer cosas que hace no tanto requerían trabajo manual, plugins o directamente scripts:

• seleccionar un frame y pedir que genere variables
• crear modos sin estructurarlo todo a mano
• aplicar cambios en bloque con más contexto
• reorganizar parte del sistema desde el propio archivo

Y esto cambia algo importante.

La coherencia deja de depender solo de procesos externos y empieza a construirse dentro del propio sistema de diseño.

Eso, para mí, es un cambio de enfoque mucho más interesante que cualquier pipeline.

Porque significa que el archivo deja de ser solo un contenedor visual. Empieza a comportarse más como una estructura viva, con reglas, relaciones y cierta inteligencia operativa.

El cambio real no es técnico

Creo que parte de la incomodidad viene de ahí.

Cuando automatizas fuera, muchas veces sientes que estás ganando control. Pero cuando la propia herramienta empieza a resolver partes del sistema, lo que cambia no es solo el flujo: cambia tu rol.

Antes, la consistencia dependía mucho de insistencia, disciplina y mantenimiento manual. Ahora, cada vez depende más de cómo has pensado el sistema desde el principio.

Y eso desplaza la conversación.

Ya no se trata solo de “cómo hago esto más rápido”, sino de “cómo está estructurado esto para que tenga sentido”.

Dicho de otra forma: la IA no elimina la necesidad de criterio. La hace más visible.

Entonces, ¿dónde empieza la sobreingeniería?

Para mí, empieza en el momento en que convertimos demasiado rápido un problema de diseño en un problema técnico.

En lugar de preguntarnos:

“¿Cómo debería estructurarse este sistema?”

nos preguntamos:

“¿Cómo automatizo esto con scripts?”

Y ahí cambia todo.

Porque la primera pregunta obliga a pensar en arquitectura, consistencia y decisiones de diseño. La segunda muchas veces solo intenta parchear una estructura débil.

No siempre, claro. Hay flujos donde scripts, MCPs o integraciones externas tienen muchísimo sentido. Pero no todo merece esa complejidad desde el minuto uno.

El riesgo de añadir capas antes de tiempo

El riesgo no es solo “hacer algo más complejo”.

Es algo más sutil:

• externalizamos decisiones de diseño
• añadimos dependencia técnica donde quizá no hacía falta
• perdemos visibilidad sobre el sistema base
• acabamos diseñando procesos que solo funcionan si todo el pipeline aguanta

Y eso, en equipos pequeños o medianos, se nota mucho.

A veces parece que estamos mejorando el workflow, cuando en realidad estamos construyendo alrededor de una base que sigue sin estar bien resuelta.

Volver al craft

Para mí, aquí vuelve algo clave: el craft.

Hay una parte del trabajo que no debería delegarse tan rápido a una capa externa: nombrar bien, estructurar bien, decidir bien.

No porque haya que romantizar lo manual. Sino porque muchas veces el verdadero salto de calidad no está en automatizar más, sino en pensar mejor la base sobre la que construyes.

El valor no está en tener el pipeline más sofisticado. Está en construir sistemas que ya funcionen bien antes de necesitarlo.

Quizá la pregunta no es qué más añadir

Quizá la pregunta útil ahora no es:

“¿Qué stack de IA debería montar?”

Sino algo más simple:

“¿Estoy aprovechando de verdad lo que ya me ofrece la herramienta?”

Porque si la respuesta es no, quizá no necesitamos más complejidad. Quizá necesitamos más criterio.

Cierre

La IA es una herramienta brutal. Pero no siempre significa añadir más capas.

A veces significa justo lo contrario:

simplificar, estructurar mejor y aprovechar lo que ya tienes.

Y quizá ahí está una diferencia importante entre usar IA por inercia… y diseñar con ella de verdad.