Mar 23, 2026

AI, Productivity
Durante años, en el sector digital uno de los momentos clave para obtener un producto óptimo era perfeccionar el handoff (ese paso crítico de entregar los diseños a desarrollo).
Pero la explosión de la Inteligencia Artificial nos ha hecho replantearnos todo. Hoy, creo que el concepto tradicional de handoff se está quedando obsoleto, y la verdadera prioridad es otra: mantener una única fuente de la verdad en flujos de trabajo que ahora son continuos.
Un buen "handoff" era la clave de todo. Hoy la IA lo ha cambiado para siempre.
Estamos viviendo tiempos tan emocionantes como caóticos con la IA. Los workflows están cambiando a una velocidad de vértigo, y con ello, empiezan a surgir nuevas dicotomías y fricciones en la colaboración entre diseño y código (design <-> code).
Por tanto nos queda descubrir cuál es el workflow óptimo para nuestros equipos sin perder el control en el camino.
La gran dicotomía: Figma Make vs. Entorno Local
Como decía, con la llegada de herramientas integradas de IA, el debate está servido. Por un lado, tenemos ecosistemas orientados al diseño visual que intentan absorber el código como Figma Make. Por otro, trabajar en el Entorno Local, donde el control técnico, la flexibilidad y los repositorios mandan (usando IDEs como Antigravity).
He escogido esta comparativa porque es la que yo personalmente estoy viviendo debido a mi herencia de Product Designer, donde Figma ha sido (y es) mi centro neurálgico, pero que poco a poco está virando hacia otra forma de trabajar.

Para entender dónde están las carencias y las fortalezas de cada enfoque, he preparado esta radiografía de cómo se comportan en el día a día esta dualidad que yo mismo estoy "sufriendo":
Aspecto | Figma Make | Entorno Local |
Setup & Onboarding | Instantáneo — sin instalación, funciona desde el navegador. | Requiere configuración inicial (herramientas de diseño, IDEs, dependencias). Ej: Antigravity. |
Colaboración | En tiempo real, edición multijugador, comentarios ágiles. | A través de Git, asíncrona, requiere coordinación técnica. |
Control de versiones | Historial de versiones integrado, fácil de explorar/restaurar. | Control total vía Git (branches, commits, PRs), pero más complejo. |
Integración GitHub | Permite hacer push, pero no se puede clonar. | Nativa — push, pull, clone, branch directamente. |
Clonación de proyectos | No es posible clonar un repositorio Git directamente. | Clonación completa de repositorios con historial y estructura. |
Workflow de diseño | El mejor en UI/UX, prototipado y sistemas de diseño (DS). Enlace directo con el DS. | Requiere crear directrices de diseño previamente. |
Handoff (Design–Dev) | Muy fuerte — cambios directos en UI. Permite copiar diseños a Figma para crear flujos o iterar rápido. | Manual. Es "ciego" para otros hasta que se hace un git push. |
Edición de código | Mediante chat de IA, directo en la UI o editando código. Es directo, pero limitado. | Capacidades completas de programación, en cualquier lenguaje o framework. |
Habilidades (Skills) | A través de guidelines en | Creación, coordinación y lectura directa de habilidades técnicas específicas y roles definidos. |
Flexibilidad | Limitado al ecosistema de Figma. | Totalmente flexible — cualquier stack, herramienta o automatización. |
Rendimiento | Depende del navegador y la conexión a internet. | Depende de tu máquina local (suele ser más rápido para trabajos pesados). |
Trabajo offline | No soportado. | Totalmente soportado. |
Gestión de assets | Centralizada, distribución muy sencilla. | Requiere estructura de carpetas, disciplina y un sistema de staging. |
Prototipado | Prototipos interactivos avanzados ya integrados. Muy fácil de compartir. | Necesita ejecutar comandos (ej: |
Escalabilidad técnica | No es adecuado para bases de código (codebases) grandes. | Construido específicamente para escalar sistemas y productos. |
Control de versiones | Fácil de recuperar versiones anteriores con un click. | A través de branches. |
Automatización (CI/CD) | Manual. | Pipelines completos, CI/CD, automatización de testing. |
Seguridad / Control | Gestionado por Figma (menor control de tus datos). | Control absoluto sobre el entorno y los datos. |
Pagos e Integración IA | Pago por tokens. Pudiendo producirse doble pago si la empresa ya paga modelos por otro lado. | Completamente conectable y gestionable con varios modelos o cuentas de empresa |
¿Dónde está la fricción real?
Si analizamos la tabla, la tensión se hace evidente. Figma Make te da una velocidad de iteración brutal y elimina de un plumazo las barreras técnicas. Me encanta el poder seleccionar los elementos directamente en la UI para iterarlos. Sin embargo, cuando el producto crece, inevitablemente te vas a chocar con el muro de la escalabilidad y la falta de un control de versiones puro. Así que, en mi opinión, Figma debe de ponerse las pilas aquí si quiere mantenerse en la carrera. Que no haya bidireccionalidad entre repos y que no se pueda conectar con modelos de empresa con Claude (u otros) es un buen bloqueo.

Y hablando de herramientas de moda, personalmente, la combinación de Figma MCP y Claude aún no me convence. Sí, es muy vistoso y ayuda a crear ipso facto el sistema de diseño o componentes ahorrándome ese momento repetitivo, pero a día de hoy, para mí, no tiene un impacto eficiente en el proceso. Es un añadido secundario que no me ayuda a construir mejor o más rápido. Además de generar más gasto de tokens o créditos. Y lo siento, Stitch, aunque posiblemente en la buena dirección, está aún lejos de ser el nuevo estándar. Reconozco que le he perdido la pista a Pencil.
Y al otro lado, encontramos que el Entorno Local te otorga libertad técnica y automatización absoluta. ¿El precio a pagar? Una curva de entrada mucho más alta y un cambio de mentalidad obligatorio.
Trabajar en local significa que ahora tienes que entender y pensar como un desarrollador para no romper su trabajo. Ya no basta con diseñar pantallas perfectas; hay que saber cómo se integran y se construyen. Su vocabulario. Esto nos lleva a una nueva realidad innegable: los equipos de producto, diseño y desarrollo deben colaborar más estrechamente que nunca. Ya no debe de existir silos sino pequeños grupos de trabajo o Makers, que sean los que cooperen y cocreen. Porque hay que pensar en escalabilidad y eso significa que las ramas (branches) pueden estar ahora localizadas en diferentes Entornos locales pero que todas deben de comunicarse de forma bidireccional con la fuente de la verdad, como por ejemplo, Github.
Y además, aquí viene otra realidad incómoda, con esta convergencia de mundos, surge un riesgo enorme. Uno de los más críticos, ya que todo el mundo debe de partir de la misma base de conocimiento pero a la vez, el desglose en diferentes ramificaciones, es lo que puede crear realidades inconsistentes. Por eso hay debe de existir una disciplina senior a la hora de gestionar y pushear los cambios.
Por todo ello, es imprescindible la figura de un moderador, o más bien, la transformación del Product Lead.

Este rol tiene que hacer de nexo entre el diseño visual y la ejecución técnica. Si no hay alguien liderando y moderando esta integración, es muy fácil que la famosa fuente de la verdad se difumine. Sin esa figura encarga de minimizar la fricción al máximo, en lugar de lograr orden y eficiencia, terminaremos generando más caos del que teníamos antes. Todo el mundo tiene ganas de sentirse creativo y probar, lo cuál es más que legítimo, pero es igual de peligroso ya que la deuda técnica puede crecer de forma exponencial.
Ya lo he mencionado en otras ocasiones, el criterio y las buenas práctica no deben de perderse. La IA nos debe ayudar a poner más y mejor orden y no más caos y falta de gobernanza.