En 1974, Holanda inventó el fútbol total. Cada jugador de campo podía ocupar cualquier posición. Cuando alguien avanzaba, el resto cubría su espacio. No había laterales fijos ni mediocampistas atados a una zona. El sistema era tan fluido que en la final del Mundial, Johan Neeskens anotó antes de que ningún jugador alemán tocara el balón. Sesenta segundos. Penalti perfecto. Holanda arriba 1-0.

Perdieron 2-1 contra Alemania Federal.

El sistema más revolucionario que ha visto el fútbol no ganó el torneo donde se presentó ante el mundo. Y ese detalle importa mucho cuando alguien te dice que tu equipo de producto debería funcionar igual.

Lo que están haciendo Figma y OpenAI

Aakash Gupta describió hace unos días cómo operan los equipos de producto de Figma y OpenAI. La analogía que usó fue exactamente esa: fútbol total. Diseñadores que escriben código. PMs que prototipan en producción. Ingenieros que jalan diseños a Figma con un comando de MCP.

Ed Bayes, diseñador de producto en OpenAI, dijo en la conversación que entre el 70% y el 80% de su tiempo como diseñador lo pasa codeando. Una diseñadora de contenido en su equipo — cuyo cargo sigue siendo “UX copy” — hace pull requests directamente a producción.

Gui Seiz, director de diseño de IA en Figma, describe a sus equipos como personas con picos de especialización pero sin territorios fijos. Cada quien tiene algo en lo que es profundo. Pero las fronteras se cruzan en minutos, no en sprints.

Y los datos respaldan que esto no es anecdótico. El reporte Shifting Roles 2025 de Figma encontró que el 64% de los profesionales encuestados cruza fronteras de roles con regularidad. El 56% de los que no son diseñadores participa significativamente en tareas de diseño.

El organigrama no cambió. Diseñador, ingeniero, PM. Lo que cambió es el workflow real. Y eso se parece mucho a lo que pasó con el colapso del ciclo de desarrollo de software: las fases colapsaron, pero los cargos formales se mantuvieron.

Las herramientas que hacen posible el cruce

Esto no está pasando por voluntad ni por moda. Está pasando porque las herramientas borraron la barrera técnica del cruce.

Figma MCP hace que el flujo entre diseño y código sea bidireccional. Un ingeniero jala un diseño de Figma — con sus variables, tokens, componentes y reglas de layout — y lo convierte en código funcional sin interpretar un screenshot. Un diseñador empuja un prototipo tan avanzado técnicamente que hace seis meses habría necesitado un sprint completo de ingeniería.

Los design systems funcionan como coeficiente de productividad dentro de ese flujo. Las reglas del sistema de diseño viajan con los componentes. El agente de IA no adivina los estilos: los lee directamente del archivo.

Del lado de OpenAI, Codex ya se integra con Linear y Slack. Puedes asignarle issues directamente desde el project board. No es un asistente que te sugiere código. Es un integrante del equipo que recibe tareas.

Aakash lo resume en una frase que vale la pena repetir: “Tres personas con capacidad superpuesta y criterio diferente.” No es que todos hagan todo. Es que cuando uno necesita cruzar al territorio del otro, el cruce tarda minutos en vez de semanas.

Eso es el multiplicador real. No un modelo más grande. No un framework nuevo. La fricción del handoff cayó a cero.

Por qué Holanda perdió la final

Y aquí es donde la analogía se pone incómoda para los que solo se quedaron con la parte bonita.

Holanda perdió la final del Mundial del 74 contra una Alemania Federal que jugaba con roles mucho más definidos. El fútbol total de Holanda había destruido a todos en el camino al final — 4-0 a Argentina, 2-0 a Brasil, el campeón defensor. Pero en el partido que importaba, perdió.

¿Por qué? Porque el fútbol total requiere dos cosas que rara vez se mencionan juntas: talento extraordinario en cada posición y coordinación clara de quién cubre a quién cuando alguien se mueve. Sin las dos, lo que parece fluidez es desorden con camiseta elegante.

Cuando alguien dice “aquí todos pueden hacer todo” en tu equipo de producto, olvida la misma pregunta clave: ¿quién decide cuando hay desacuerdo? Si el diseñador prototipa en producción y el ingeniero edita en Figma, ¿quién tiene la última palabra sobre la experiencia de usuario? ¿Quién es responsable si un cambio de diseño rompe la arquitectura? ¿Quién prioriza cuando la velocidad del PM conflicta con la deuda técnica del ingeniero?

El organigrama existe por una razón que va más allá de la burocracia. Es un sistema para resolver conflictos entre personas que quieren cosas distintas. Lo escribí cuando analicé por qué tu directorio de agentes de IA no es un organigrama: la estructura no desaparece porque las herramientas sean mejores. Se adapta.

Los equipos que funcionan no eliminaron los roles. Eliminaron las paredes entre ellos. Son cosas muy distintas.

Fluidez de rol, no eliminación de rol

El patrón que funciona se parece más al del empleado 100x: una persona con capacidad multidisciplinaria que opera en toda la superficie del problema, pero que tiene una responsabilidad principal clara.

Aunque el diseñador escriba código, su misión principal sigue siendo defender al usuario. Lo mismo con el PM, que no pierde el control del roadmap por armar prototipos. Y el ingeniero que ahora ajusta cosas en Figma sigue siendo quien recibe la llamada a las tres de la mañana cuando el sistema se cae.

La verdadera fluidez exige saber cuándo cruzar la línea y, más importante, tener claro quién toma la decisión final en cada tipo de llamada.

El muro de Jira — esa pared donde un ticket cruza de diseño a ingeniería y se detiene tres días porque alguien tiene otra prioridad — no es un problema de proceso. Es un problema de capacidad. Cuando cruzar de un lado al otro tarda semanas, construyes paredes. Cuando tarda minutos, las paredes se disuelven solas.

La receta que describe Gui Seiz: contrata por picos (profundidad real en un área), habilita el cruce (herramientas + cultura), y preserva los límites de criterio. Nadie le dice al diseñador que deje de defender al usuario. Le dan las herramientas para que su defensa llegue a producción sin esperar en una cola.

Lo que falta para jugar fútbol total sin perder la final

El fútbol total en equipos de producto no es un problema de herramientas. Es un problema de diseño organizacional.

Para que funcione sin repetir el resultado de Holanda, necesitas que las herramientas realmente habiliten el cruce. MCP, Codex, agentes de IA que conecten disciplinas. Si tu diseñador todavía necesita pedirle a un ingeniero que “traduzca” su prototipo a código, no estás jugando fútbol total. Estás pasando tickets con otro nombre.

Pero las herramientas solas no resuelven nada si el equipo no define de antemano quién tiene la última palabra. Que los roles sean flexibles no significa que las decisiones se tomen por consenso difuso. Si nadie es dueño claro de la UX, de la arquitectura o del roadmap de producto, el proyecto termina siendo un Frankenstein donde todo se construye a medias.

Y necesitas una capa de orquestación. En el 74, eso era Rinus Michels, el director técnico. En tu equipo puede ser un rol, un proceso, o un sistema de coordinación diseñado para eso. Pero alguien tiene que ver todo el campo y saber cuándo cubrir. Sin eso, la fluidez se vuelve improvisación.

Instalar Figma MCP no te convierte en equipo de fútbol total. Quitar el tablero de Jira tampoco. Los equipos que realmente dan vueltas alrededor de los demás tienen las dos cosas: la capacidad fluida y los límites de criterio claros.

En IQ Source diseñamos esta capa intermedia. Analizamos si la fluidez de tu equipo genera velocidad real o solo deuda oculta de decisiones que nadie tomó, y estructuramos las herramientas y responsabilidades para que cruzar fronteras no signifique perder el control. Si tu equipo ya tiene las herramientas pero la velocidad no cambió, el cuello de botella no es técnico. Es organizacional. Conversemos.