La beta de Figma Code Layers lleva la exploración compartida a los prototipos funcionales
Figma afirma que la beta de code layers ya llega al 100 % de los usuarios, incorporando prototipos funcionales directamente al lienzo donde los equipos ya revisan diseños. Code layers, prototipos interactivos respaldados por código en ejecución, ofrecen a los diseñadores un espacio compartido para comparar el comportamiento junto con la apariencia. El cambio presiona un flujo de trabajo conocido: crear un experimento en otro lugar y luego traer un enlace para que todos lo evalúen.
El anuncio trata de una disponibilidad más amplia, no de un lanzamiento completamente nuevo. La publicación de Figma sobre flujos de trabajo del 4 de noviembre describe el despliegue completo, mientras que su documentación sitúa la beta abierta inicial el 15 de octubre de 2026. Esa distinción importa porque la pregunta inmediata ha pasado del acceso a la utilidad. Los equipos ahora pueden evaluar si un lienzo compartido mejora las decisiones lo suficiente como para justificar otra vía entre diseño e implementación.
Framer ya ofrece componentes de código en su lienzo, por lo que ejecutar código dentro de un espacio de trabajo visual no es en sí una novedad. La propuesta de Figma se centra en la exploración colaborativa: conservar alternativas, editar su apariencia y combinar ideas antes de comprometerse con la implementación. La tensión central está entre facilitar la discusión de un prototipo y preparar sus cambios subyacentes para el lanzamiento.
La beta de Figma Code Layers amplía la superficie de revisión compartida
El cambio significativo es que un experimento funcional puede pasar a formar parte del mismo espacio de revisión que los diseños que lo rodean.
En su flujo de trabajo de code layers, Figma describe importar código, generar alternativas, refinar diseños extraídos y combinar exploraciones. Figma agent, su asistente conversacional de IA dentro de los archivos de diseño, ayuda a realizar esos cambios. La publicación presenta un marketplace ficticio llamado Pickup, en el que un diseñador explora la selección de direcciones de entrega junto a una experiencia de mapas existente.
Un ejemplo ficticio puede ilustrar un flujo de trabajo sin demostrar sus resultados. Pickup resulta útil para comprender la secuencia prevista por Figma, pero no debe confundirse con una implementación medida de forma independiente. El anuncio no proporciona fundamentos para concluir que todos los equipos reducirán los ciclos de desarrollo o crearán mejores interfaces.
Aun así, la ubicación del experimento cambia aquello que los revisores pueden discutir. Una captura de pantalla refleja la apariencia en un momento concreto. Un prototipo funcional permite probar una interacción, volver a los diseños circundantes y comparar otra dirección sin perder el contexto visual general.
Pensemos en una revisión donde el desacuerdo se refiere a un selector de direcciones. Un diseño atractivo podría ocultar una transición incómoda después de que alguien elige una ubicación. Por el contrario, una alternativa visualmente sencilla podría aclarar la tarea. Situar el comportamiento junto a la apariencia aporta pruebas más directas a la discusión.
Esto no hace que los comentarios sean automáticamente más precisos. Los revisores siguen necesitando identificar qué probaron y explicar por qué importa una diferencia. Un lienzo lleno de alternativas funcionales puede resultar tan confuso como una carpeta llena de enlaces a prototipos cuando nadie etiqueta su propósito.
La oportunidad consiste en mantener visible la pregunta junto al experimento. Una variación podría probar si las personas entienden el punto de entrada. Otra podría probar cuánta información debe aparecer antes de la confirmación. Son preguntas de producto diferentes, aunque ambos prototipos contengan pantallas similares.
Esa distinción también ayuda a evitar que el resultado generado se convierta en la decisión misma. Un agente puede ofrecer alternativas plausibles sin establecer cuál sirve mejor a los usuarios. El equipo sigue siendo responsable de elegir los criterios de evaluación e identificar las pruebas que faltan.
Por tanto, para quienes evalúan el despliegue, la disponibilidad es el punto de partida. La cuestión más importante es si la superficie compartida facilita resolver los desacuerdos. Si todos pueden ver las alternativas pero nadie puede explicar la selección, el flujo de trabajo se ha desplazado sin ganar responsabilidad.
La beta de Figma Code Layers hace práctica esa pregunta para una audiencia más amplia. Los equipos pueden evaluar directamente el modelo de colaboración, mientras tratan la demostración de flujo de trabajo de la empresa como una propuesta que debe probarse.
Diseñadores y desarrolladores afrontan una decisión de alineación más temprana
Los prototipos compartidos adelantan algunas conversaciones de implementación, cuando cambiar de dirección todavía debería ser relativamente poco costoso.
La documentación de code layers de Figma describe cómo empezar a partir de diseños, prompts, páginas web o código conectado. También permite extraer capas de diseño editables y devolver sus cambios a una capa de código. La documentación advierte que code layers no funciona con todos los repositorios.
Esa última salvedad ayuda a definir quién afronta la presión. Los diseñadores obtienen otra manera de concretar una interacción, pero los desarrolladores deben determinar hasta qué punto el experimento refleja el producto real. Los responsables de producto deben distinguir una demostración convincente de un alcance de implementación acordado.
La participación temprana de los desarrolladores resulta valiosa cuando revela una dependencia oculta. Un prototipo podría sugerir una respuesta inmediata después de una acción del usuario. El producto en producción podría necesitar esperar a un servicio, comprobar permisos o gestionar información que no está disponible localmente.
Se trata de consideraciones de ingeniería ilustrativas, no de fallos documentados de la función de Figma. Explican por qué una interfaz funcional no puede responder a todas las preguntas de implementación. El prototipo establece lo que alguien puede experimentar dentro del experimento, mientras que la revisión de producción establece lo que la organización puede respaldar de manera fiable.
La presión también alcanza al propio proceso de revisión. Si un diseñador puede llevar una alternativa funcional a una reunión, resulta más difícil mantener una petición vaga de mayor claridad. Los participantes pueden señalar la interacción y explicar qué parte genera incertidumbre.
Mientras tanto, los desarrolladores pueden usar la misma conversación para separar las decisiones visuales de las arquitectónicas. Una etiqueta de botón podría estar lista para adoptarse de inmediato. Una nueva secuencia de solicitudes podría requerir un cambio técnico más amplio. Mantener esos juicios separados puede evitar que una interfaz prometedora adquiera un compromiso de entrega poco realista.
Por tanto, la creación de prototipos con Figma agent cambia más el momento de la colaboración que la responsabilidad. Los diseñadores siguen siendo responsables de los criterios de diseño. Los ingenieros siguen evaluando la implementación. Los líderes de producto siguen decidiendo si la experiencia propuesta resuelve un problema valioso.
También existe una cuestión de participación. Un espacio de trabajo compartido aporta poco valor si solo la persona que genera los prototipos entiende cómo evaluarlos. Los revisores necesitan suficiente contexto para explorar el comportamiento relevante sin requerir una visita guiada narrada cada vez.
Para las organizaciones, la señal útil de adopción es una decisión más clara después de la revisión. Una sesión satisfactoria debería identificar la dirección preferida, las suposiciones no resueltas y el trabajo necesario antes del lanzamiento. Producir más alternativas solo resulta útil cuando esas alternativas mejoran esa decisión.
El flujo de trabajo existente afronta presión porque separa la experimentación de la evaluación colectiva. El enfoque de Figma acerca esas actividades. Que esa proximidad reduzca el retrabajo sigue siendo algo que cada equipo debe establecer mediante sus propios proyectos.
El agente conecta la exploración visual con el comportamiento en ejecución
La parte más sólida de la propuesta de Figma es la capacidad de alternar entre el comportamiento y el detalle visual sin abandonar la conversación circundante.
En términos analíticos, se trata de un ciclo de retroalimentación. Un equipo prueba una interacción, detecta un problema de diseño, revisa la apariencia pertinente y evalúa el comportamiento actualizado. El objetivo es mantener cada revisión vinculada a la pregunta que la motivó.
La distinción importa porque la calidad de una interfaz implica tanto detalles locales como secuencias más amplias. El espaciado puede afectar a si una acción parece disponible. La redacción puede cambiar lo que alguien espera tras seleccionarla. Una transición puede revelar que una pantalla visualmente equilibrada solicita información en el momento equivocado.
El paso entre estas cuestiones suele ser donde la revisión pierde precisión. Una conversación comienza con un problema observable y luego se convierte en una preferencia general sobre el estilo. Mantener la experiencia funcional cerca de la exploración visual da a los participantes una forma de volver a las pruebas originales.
El material de clientes de Figma ofrece cierto respaldo a esa interpretación. Sus ejemplos de prototipos de clientes describen cómo el diseñador de Checkout.com Kris Murphy extrae pantallas para inspeccionarlas conjuntamente y luego devuelve ediciones visuales al prototipo. La misma recopilación describe cómo Leonardo Rica, de Superside, aporta medidas precisas y detalles de movimiento al explorar un concepto de tarjeta interactiva.
Se trata de testimonios de clientes identificados publicados por Figma, no de comparaciones independientes. Ilustran cómo las personas utilizan la función, pero no establecen resultados típicos. Su hilo conductor útil es la especificidad: el flujo de trabajo se vuelve más significativo cuando alguien sabe qué necesita inspección o corrección.
Por ejemplo, un equipo que evalúa una interacción de pago podría separar la incertidumbre sobre la redacción de la incertidumbre sobre la navegación. Revisar ambas simultáneamente hace más difícil entender por qué el resultado parece mejor. Conservar una comparación puede ayudar a mantener la conversación centrada en la decisión que se está probando.
Ese es un beneficio analítico de la comparación, no una afirmación de que Figma realice automáticamente un experimento controlado. El equipo aún debe mantener las condiciones lo suficientemente coherentes. Un contenido de muestra diferente o estados ausentes pueden hacer que una alternativa parezca más sólida por razones no relacionadas.
La misma cautela se aplica al combinar exploraciones. Reunir características atractivas no garantiza que el resultado siga siendo coherente. Elecciones individualmente sensatas pueden entrar en conflicto cuando comparten navegación, terminología o expectativas sobre lo que ocurre después.
En consecuencia, un prototipo combinado necesita otra revisión propia. Debe evaluarse como una experiencia completa, en lugar de aceptarse porque sus ingredientes recibieron aprobación anteriormente. Aquí es donde el criterio de diseño sigue siendo fundamental pese a una generación más rápida.
La creación de prototipos con Figma agent resulta más útil cuando el agente respalda una investigación concreta. Una solicitud para explorar una interacción específica deja al equipo con algo evaluable. Una solicitud de una experiencia generalmente mejor deja demasiado de la evaluación sin expresar.
La implicación práctica es que la exploración en un lienzo compartido depende de una intención clara. El código en ejecución pone el comportamiento a disposición de la inspección. No decide qué comportamiento merece mantenerse.
El código en el lienzo ya es una categoría competitiva
El argumento competitivo de Figma se basa en la continuidad de la revisión en equipo, ya que el código basado en lienzo ya existe en otros lugares.
Los componentes de código de Framer son componentes de React, elementos de interfaz reutilizables escritos en una biblioteca de JavaScript, que se renderizan en su lienzo, en vistas previas y en sitios publicados. Su documentación también describe controles visuales de propiedades y el uso compartido de componentes.
Eso establece una referencia histórica pertinente sin hacer que los productos sean intercambiables. Un componente que amplía un creador de sitios web y un prototipo explorado dentro de un archivo de diseño de producto tienen propósitos que se solapan, pero son distintos. Su valor depende de lo que el equipo intenta entregar.
Un equipo que desarrolla un sitio web publicado podría priorizar la relación entre la edición visual y el sitio final. Un equipo de producto que explora un cambio en una aplicación podría priorizar las alternativas, las pantallas circundantes y la conversación que explica la dirección seleccionada.
Ninguno de los requisitos es intrínsecamente más avanzado. Representan resultados finales diferentes. Comparar herramientas únicamente por su capacidad para generar código pasa por alto el trabajo que sigue a la generación y a las personas que necesitan participar.
Esto sitúa el posicionamiento de Figma en términos más claros. Su oportunidad consiste en convertir el archivo de diseño compartido en un lugar útil para revisar ideas funcionales. La cuestión es si esa ubicación conserva suficiente contexto como para compensar el esfuerzo de llevar código allí.
Un entorno de programación independiente también puede ser un lugar eficaz para explorar una interfaz. Los ingenieros pueden preferir experimentar donde ya existen las convenciones del proyecto y las comprobaciones de desarrollo. Los diseñadores pueden preferir la visión visual más amplia disponible en su espacio de trabajo de diseño.
Esas preferencias no deberían convertirse en una competencia artificial entre herramientas visuales y herramientas de código. La cuestión operativa es dónde puede tomarse con claridad una decisión determinada. Distintas etapas de un mismo proyecto pueden utilizar razonablemente entornos diferentes.
El principal adversario sigue siendo la exploración fragmentada. Esa fragmentación aparece cuando el prototipo, los diseños circundantes, los comentarios y la justificación se vuelven difíciles de conectar. Cambiar de aplicación es solo un síntoma. Una sola aplicación también puede contener trabajo desconectado.
Por eso, contar los cambios de herramienta eliminados sería una evaluación incompleta. Un equipo podría moverse con menos frecuencia y, aun así, dedicar más tiempo a identificar la versión actual. Otro equipo podría conservar herramientas separadas, pero mantener vínculos claros entre la evidencia y las decisiones.
Las capas de código explicadas por los ejemplos de Figma ofrecen una respuesta espacial: colocar juntas las alternativas y la conversación. La proximidad espacial es útil cuando las relaciones son visibles. Es menos útil cuando un lienzo en expansión hace ambiguas esas relaciones.
Por tanto, la presión competitiva afecta tanto a la calidad de la revisión como a la generación. Figma necesita demostrar que su entorno colaborativo existente se vuelve más útil cuando los prototipos pueden ejecutarse dentro de él. Los enfoques rivales siguen siendo creíbles allí donde ofrecen a los equipos un camino más claro desde una idea hasta una decisión de implementación justificada.
Un prototipo funcional aún necesita revisión de código y acceso
Un prototipo que se ejecuta dentro de un archivo compartido crea obligaciones de revisión tanto sobre su implementación como sobre su visibilidad.
La documentación de integración con Git de Figma describe la clonación de repositorios, las ramas y las solicitudes de extracción, cambios propuestos que se envían para revisión antes de fusionarse. También explica que los lectores de archivos pueden ver la vista previa de una capa de código y el código fuente de la vista previa. Los editores de archivos pueden acceder al código subyacente del repositorio incluso sin los permisos correspondientes de GitHub.
Ese modelo de visibilidad merece atención antes de importar un proyecto privado. La audiencia relevante es el grupo que tiene acceso al archivo de diseño. Los equipos deberían evaluar si esa audiencia coincide con la audiencia prevista para el código que se introduce.
Se trata de una característica de acceso documentada, no de evidencia de un incidente de seguridad. Su importancia práctica depende del repositorio y de la configuración de uso compartido. Una organización que trabaja con código propietario debe entender esa configuración antes de tratar la importación como una operación de diseño rutinaria.
Existe un límite de implementación independiente. Figma documenta una ruta de vuelta a la revisión del repositorio, pero la existencia de esa ruta no demuestra que los cambios generados sean correctos. Un cambio propuesto aún necesita evaluación frente a los requisitos del proyecto.
Para una función de selección de direcciones, los revisores podrían preguntar cómo se gestionan las ubicaciones no disponibles o si la confirmación sigue siendo clara después de una solicitud fallida. Son preguntas de revisión ilustrativas. Su propósito es distinguir un comportamiento convincente en un experimento de un comportamiento fiable en condiciones reales.
La accesibilidad exige la misma distinción. Una interfaz puede parecer convincente y, aun así, seguir siendo difícil de usar sin un puntero. El comportamiento del teclado, el orden del foco y los comentarios comprensibles necesitan una evaluación directa, en lugar de inferirse de la calidad visual.
También importa la relación entre el código del prototipo y las convenciones existentes del proyecto. Un cambio localizado puede parecer razonable mientras introduce un patrón difícil de mantener en otras partes. Revisar el cambio en contexto sigue siendo necesario incluso cuando el prototipo hace evidente el comportamiento previsto.
Por tanto, el argumento escéptico es concreto: una demostración más sencilla puede fomentar una confianza prematura. Las partes interesadas podrían interpretar una pantalla funcional como prueba de que el trabajo restante es menor. Esa interpretación debe cuestionarse siempre que el experimento deje sin resolver dependencias importantes.
Una revisión útil debería identificar qué comportamiento está implementado, cuál está simulado y qué supuestos siguen sin probarse. Esto mantiene el valor del prototipo sin permitir que se convierta en una promesa accidental.
Los registros de decisiones ayudan a preservar esa distinción después de la reunión. Los equipos que comparan alternativas pueden conservar su justificación en una base de conocimientos con búsqueda, junto con documentos técnicos relacionados. La información relevante es por qué cambió la dirección y qué queda por verificar.
En consecuencia, la beta de capas de código de Figma debería juzgarse por la calidad del cambio propuesto que llega a la revisión de ingeniería. Un prototipo más comprensible es útil. Un prototipo acompañado de supuestos explícitos y una implementación revisable es un resultado más sólido.
Observar la adopción, la fidelidad de las revisiones y la economía de la exploración
La próxima evidencia debería mostrar si los equipos toman decisiones más claras, conservan los cambios previstos y sostienen el flujo de trabajo tras la experimentación inicial.
La primera señal es el uso colaborativo repetido en proyectos reales. En los próximos meses, una evidencia más sólida incluiría casos en los que los compañeros comparen alternativas y lleven una dirección elegida a la revisión de implementación. El uso repetido respaldaría el argumento de Figma de que el lienzo resuelve un problema continuo de coordinación.
Una colección de demostraciones impresionantes ofrecería un respaldo más débil. Las demostraciones establecen que un flujo de trabajo puede producir un resultado atractivo. Revelan menos sobre si un equipo vuelve a ese flujo cuando las limitaciones del proyecto se vuelven inconvenientes.
La distinción debería orientar a los compradores que evalúan historias de adopción. Pregunte qué decisión se volvió más clara, quién participó y qué ocurrió después de la revisión del prototipo. Esos detalles son más útiles que una afirmación general de que la experimentación resultó más rápida.
La segunda señal es la fidelidad de las revisiones: si los cambios conservan su apariencia y comportamiento previstos a medida que el trabajo pasa entre la edición visual y el código. Este es un criterio de evaluación propuesto, no un referente publicado por Figma. Aborda el mecanismo central detrás de la promesa del producto.
La evidencia de un trabajo correctivo limitado reforzaría esa promesa. Los informes repetidos de cambios no relacionados, detalles perdidos o conciliación difícil la debilitarían. Cualquiera de los resultados necesita contexto sobre la complejidad del proyecto y los cambios que se intentan realizar.
La tercera señal es la exploración sostenida bajo el consumo real de créditos. Las reglas de créditos de IA de Figma indican que las solicitudes de capas de código consumen créditos variables. La empresa también afirma que no puede predecir el consumo exacto antes de que se ejecute una tarea de IA.
Eso convierte al ciclo completo de revisión en la unidad de evaluación pertinente. Generar una alternativa, refinarla y corregirla forman parte de llegar a una decisión utilizable. Juzgar solo el primer resultado deja invisible el resto de ese esfuerzo.
El uso continuado sugeriría que los equipos consideran que el resultado justifica los recursos necesarios. Un patrón de abandono de comparaciones después de las pruebas iniciales plantearía dudas sobre la repetibilidad. Ninguna de las dos conclusiones puede establecerse únicamente a partir del anuncio del lanzamiento.
Estas señales mantienen el pronóstico ligado a resultados observables. Figma ha puesto la exploración funcional a disposición dentro de su entorno de diseño compartido. La cuestión restante es si el proceso circundante se vuelve lo bastante claro como para que los equipos sigan utilizándolo.
Para su próxima revisión, elija una interacción que ya genere desacuerdo y mantenga explícita la pregunta de evaluación. Compare las alternativas frente a la misma tarea de usuario, conserve el razonamiento detrás de la dirección seleccionada e identifique los supuestos que ingeniería debe verificar. Pregunte a los revisores si la comparación funcional cambió su criterio o simplemente hizo la presentación más atractiva. Después, siga el cambio propuesto durante la revisión de implementación y registre las correcciones necesarias en el proceso. Considere la beta de capas de código de Figma como una oportunidad para examinar cómo toma decisiones su equipo. Mantenga el flujo de trabajo cuando ayude a los participantes a comprender las compensaciones y deje a los desarrolladores una propuesta más clara y revisable.
