La perspectiva de un ingeniero frontend sobre el nuevo flujo de trabajo entre diseño e ingeniería en la era de la IA
Un número que no debería tener sentido
12 días. Dos personas: una diseñadora de producto y un ingeniero frontend. Una reconstrucción completa de la plataforma.
No fue un prototipo. No fue un MVP. Fue el reemplazo total de una aplicación en producción, que culminó en un único PR que eliminó 26.000 líneas de código legacy. Cada página, cada ruta, cada interacción, reconstruida desde cero y desplegada para usuarios reales.
En cualquier flujo de trabajo tradicional de desarrollo de producto, este plazo es absurdo. Un proyecto de esta envergadura normalmente llevaría meses: semanas de exploración de diseño en Figma, rondas de revisión con stakeholders, una ceremonia de handoff, planificación de sprints y luego la lenta tarea de implementar pixel por pixel. Lo que ocurrió aquí fue fundamentalmente distinto. No porque trabajamos más duro, sino porque la forma en que colaboramos cambió.
Esta es la historia de cómo lanzamos la plataforma Zero en VM0, y lo que me enseñó sobre el futuro de la colaboración entre producto e ingeniería.
El viejo cuello de botella
Todo ingeniero frontend conoce el pipeline tradicional:
- El diseñador crea mockups en Figma
- Revisión del diseño, iteración, aprobación
- Especificaciones anotadas con espaciados, colores y breakpoints
- El ingeniero traduce las specs visuales a código
- Ida y vuelta: "¿Puedes mover esto 4px a la izquierda?"
- Finalmente, conectar la capa de API
- Pruebas de integración, más ida y vuelta
El cuello de botella nunca estuvo en un paso concreto. Estaba en los espacios entre los pasos: la espera, la pérdida en la traducción, el cambio de contexto. El modelo mental que un diseñador tiene de una interacción, una vez aplanado en un frame estático de Figma y anotado con redlines, llega al escritorio del ingeniero ya degradado. El ingeniero reconstruye una versión de lo que el diseñador imaginó, pero inevitablemente es una copia con pérdida.
Nos habíamos acostumbrado tanto a esa fricción que dejamos de verla. Simplemente era "cómo funcionan las cosas".
El experimento: ¿Y si la diseñadora hace deploy de código?
El 5 de marzo de 2026, Ming, nuestra diseñadora de producto, abrió el PR #3685: feat(platform): add zero app with shell, pages and polish. Añadió 4.146 líneas de código React funcional.
No fue un archivo de Figma. No fue una exportación de design tokens. Fue una aplicación en funcionamiento.
El PR contenía un app shell completo: navegación lateral, estructura de rutas, esqueletos de página para chat, schedule, actividad, gestión de equipos y configuración — todo estilizado con nuestro design system, todo renderizándose en el navegador. Los datos eran mocks, pero la UI era real. Podías ejecutar npm run dev y navegar por cada página.
Ming no escribió este código desde cero en el sentido tradicional. Usó herramientas de codificación con IA (primero Cursor, después Claude Code) para traducir su visión de diseño directamente a componentes React. La IA se encargó de la traducción mecánica (estructura JSX, propiedades CSS, composición de componentes), mientras Ming dirigía las decisiones visuales y de interacción que ninguna IA puede tomar: el ritmo del layout, la jerarquía de la información, la sensación de las transiciones.
Durante los cuatro días siguientes, se mergearon tres PRs más:
| Fecha | PR | Lo que Ming entregó |
|---|---|---|
| 5 Mar | #3685 | App shell, sidebar, todos los esqueletos de página (+4.146 líneas) |
| 6 Mar | #3825 | Páginas de schedule, pulido de UI (+2.650 líneas) |
| 9 Mar | #3993 | Flujo de onboarding, diálogo de configuración de Slack (+1.146 líneas) |
| 9 Mar | #4050 | Página About, tarjeta de navegación flotante |
Para el 9 de marzo, toda la superficie frontend de nuestra nueva plataforma existía como código funcional. Cada página que eventualmente verías en producción ya era navegable en un entorno de desarrollo. Simplemente no hacía nada real todavía.
Ahí es donde entré yo.
Mi nuevo trabajo: inyectar el alma
Cuando abrí el codebase el 9 de marzo, no enfrenté el desafío habitual de traducir un diseño plano a código. El código ya estaba ahí. Mi trabajo era reemplazar cada mock con realidad — conectar cada superficie bellamente diseñada con el backend vivo que había debajo.
Esto cambió mi trabajo de forma fundamental. En lugar de pensar en píxeles, pensaba en flujos de datos. En lugar de preguntar "¿esto coincide con el mockup?", preguntaba "¿qué llamada API necesita esta página y qué pasa cuando falla?"
Así fue mi primera semana:
Día 1 (9 de marzo): Auth y cambio de organización. Conecté el shell de Ming a la autenticación de Clerk, añadí redirecciones cross-domain e hice que el org switcher realmente cambiara de organización. Dos PRs, ambos mergeados el mismo día.
Día 2 (10 de marzo): Conectores y schedule. Reemplacé el grid de conectores mock con datos reales de la API, conecté la pestaña de schedule a cron jobs reales y vinculé el editor de instrucciones al backend. Cuatro PRs.
Día 3 (11 de marzo): El gran día de conexiones. La página de equipo recibió datos reales de subagentes (+3.271 líneas). La página de actividad recibió logs reales. Y la joya de la corona: la página de chat se conectó al pipeline real de ejecución del agente, reemplazando ~1.200 líneas de código demo con una interfaz de conversación con IA funcional. Ese mismo día, introduje FeatureSwitchKey.Zero, un feature flag que nos permitía ejecutar la plataforma vieja y la nueva en paralelo.
Días 4-5 (12-13 de marzo): Adjuntos de archivos, gestión de sesiones, chat multi-agente, persistencia de configuración. Cada página que Ming había construido ahora hacía trabajo real.
El ritmo era casi musical. Cada mañana tomaba una página del scaffold de Ming, estudiaba su estructura de componentes, identificaba qué datos esperaba, construía la integración con la API, manejaba los estados de error y hacía push. Por la tarde, otra página cobraba vida.
El Feature Switch: mundos paralelos
El feature flag FeatureSwitchKey.Zero merece su propia mención, porque es lo que hizo que esta migración fuera segura en lugar de temeraria.
Desde el 11 de marzo en adelante, nuestra app en producción ejecutaba dos UIs completas en paralelo. Los usuarios del sistema viejo veían las rutas antiguas. Los testers internos del sistema nuevo veían Zero. Cada página que yo conectaba podía probarse en contexto de producción sin arriesgar el flujo de trabajo de ningún usuario.
Esto no es revolucionario. Los feature flags son práctica estándar. Pero la combinación de feature flags con el flujo design-as-code creó algo especial: podíamos validar toda la UX de la nueva plataforma (porque Ming había construido una UI completa y navegable) mientras hacíamos funcional cada página de forma progresiva (porque yo las conectaba una por una). En cualquier momento, si algo salía mal, podíamos revertir el switch.
Nada salió mal.
Día 12: el gran cambio
El 17 de marzo, abrí el PR #5095: refactor: remove all non-zero platform pages and feature flag.
El diff: +456 líneas, -26.041 líneas.
Antes: la vieja plataforma VM0. Tablas, run IDs y datos crudos de sesión.
Después: el nuevo Zero. Un workspace de IA conversacional con agentes fijados y tarjetas de casos de uso.
En un solo merge, se eliminaron todas las rutas legacy. Se removió el feature flag. Zero ya no era una opción; era el único modo. Un PR de seguimiento (#5155) eliminó por completo el prefijo /zero en la URL: lo que había sido /zero/chat pasó a ser simplemente /chat.
¿Por qué me sentí seguro haciendo este corte? Porque:
- Cada página había estado funcionando bajo el feature flag durante al menos 5 días
- Cada integración de API había sido probada contra datos de producción
- Los sistemas viejo y nuevo compartían el mismo backend. Esto fue un cambio de frontend, no una migración de datos
- Tuvimos usuarios reales en el sistema nuevo dando feedback durante todo el proceso
Las 26.000 líneas no se eliminaron con ansiedad. Se eliminaron con alivio.
El patrón se repite
Lo que más me sorprendió no fue la migración en sí. Fue que el flujo de trabajo que habíamos descubierto se convirtió en nuestro modo por defecto para cada feature posterior. Ming construye el shell de la UI con asistencia de IA, yo conecto la lógica y extiendo la arquitectura. El mismo patrón design-as-code, a escala de feature:
Sistema de permisos (19 de marzo → 7 de abril)
Ming entregó el PR #5467, una UI de drawer de permisos con componentes Sheet y controles toggle. Tres commits, UI limpia.
Yo añadí 13 commits al mismo PR: migración de base de datos para firewall_access_requests, endpoints de API, tests de integración, correcciones de lint. Luego, durante las dos semanas siguientes, más de 10 PRs de seguimiento construyeron la capa completa de permisos: rediseño de tarjetas de aprobación, notificaciones de Slack para solicitudes de acceso, comandos doctor en el CLI para diagnosticar problemas de permisos, y finalmente renombrar todo el concepto de "firewall" a "permission" en todo el codebase.
El drawer de Ming fue la semilla. El sistema de permisos fue el árbol.
Sistema de schedule (23 de marzo → 13 de abril)
Ming diseñó la ruta de detalle de schedule y la UX del calendario (#6155). Tres commits de trabajo de UI limpio.
Yo añadí 14 commits: edición de descripciones con auto-generación, selección de canal de Slack para notificaciones, diálogos de confirmación de cambios sin guardar, unificación de vistas calendario/lista, y tests exhaustivos. Después, más de 15 PRs de seguimiento lo expandieron a un sistema completo de tareas recurrentes con historial de ejecuciones, manejo de zonas horarias y soporte para expresiones cron.
Integración de Telegram (27 de abril → 28 de abril)
Para este punto, el patrón estaba tan bien practicado que lanzamos una integración completa de plataforma en 48 horas. Ming construyó la UI de Settings (#11196) y el flujo de Onboarding (#11399). Yo construí la API multi-bot, envío/recepción de mensajes, subida/descarga de archivos, contexto enriquecido de mensajes, actualizaciones en tiempo real con Ably y tests E2E. Al día siguiente, estaba habilitado para todos los usuarios.
Dónde encaja la IA
Quiero ser preciso sobre el rol de la IA aquí, porque es fácil sobreestimarlo o subestimarlo.
La IA le permitió a la diseñadora programar. Ming es diseñadora de producto, no ingeniera de software. Piensa en layouts, jerarquías e interacciones — no en React hooks y genéricos de TypeScript. Las herramientas de IA (Cursor, luego Claude Code) cerraron esa brecha encargándose de la traducción mecánica desde la intención de diseño hasta código funcional. Ming dirigía; la IA escribía. El resultado fue código que una diseñadora creó pero sobre el cual un ingeniero podía construir.
La IA aceleró el ciclo de revisión. En PRs colaborativos, mi agente de IA revisaba el código de Ming, clasificaba los problemas por prioridad (P0/P1/P2) y enviaba commits de corrección directamente. El PR #5060 pasó por cinco rondas de revisión en 38 minutos. El PR #5467 completó tres rondas en 20 minutos. Esto no es "la IA reemplazando el code review". Yo seguía leyendo cada cambio. Pero el trabajo mecánico de identificar problemas de lint, tipos faltantes y brechas en los tests fue automatizado.
La IA no tomó las decisiones de diseño. La arquitectura de información de cada página, los patrones de interacción, la jerarquía visual — todo vino del instinto de producto de Ming, informado por investigación de usuarios y expertise del dominio. La IA puede generar una página de settings, pero no puede decidir qué debería ser un toggle versus un dropdown, o cuándo un diálogo de confirmación es necesario versus cuándo es fricción.
La IA no tomó las decisiones de arquitectura. La elección de usar un feature flag para el deploy en paralelo, la estrategia de separación de la capa de API, la decisión de conectar las páginas de forma incremental en lugar de todas a la vez — fueron decisiones de criterio ingenieril. La IA me ayudó a escribir código más rápido, pero la secuenciación y la gestión de riesgos fueron humanas.
El resumen honesto: la IA eliminó la capa de traducción entre diseño e ingeniería. No reemplazó ninguna de las dos disciplinas; eliminó la brecha entre ellas.
Qué cambió en mi rol
Después de vivir en este flujo de trabajo durante tres meses, veo mi rol como ingeniero frontend de manera diferente.
Ya no soy un traductor visual. Los días de recibir un archivo de Figma y pasar horas ajustando valores de espaciado se acabaron. No porque sea más rápido, sino porque ya no es mi trabajo. La intención del diseñador llega como código, no como una imagen de código.
Soy un extensor de arquitectura. Mi valor principal es tomar una superficie de UI funcional y construir la infraestructura invisible debajo: integraciones de API, validación de datos, manejo de errores, verificaciones de permisos, actualizaciones en tiempo real, tests. La proporción en la mayoría de los PRs colaborativos cuenta la historia: Ming contribuye 3 commits de UI, yo contribuyo 13 commits de todo lo demás.
Soy un guardián de calidad. Con ciclos de revisión asistidos por IA, puedo mantener la calidad del código en una superficie mucho más amplia que antes. La revisión automatizada detecta los problemas mecánicos; yo me enfoco en cuestiones arquitectónicas, casos extremos y asegurarme de que la feature realmente funcione de principio a fin.
Soy un estratega de entrega. Feature flags, conexión incremental, deploys en paralelo: la secuenciación de cómo una feature pasa de código a producción ahora es una parte central de mi trabajo, no algo secundario.
Los números
Tres meses. Dos personas. Con asistencia de IA en todo momento.
- 914 PRs mergeados (679 míos, 235 de Ming)
- 12 días desde el primer scaffold hasta el reemplazo total de la plataforma
- 48 horas para una integración completa de Telegram (nuestra feature más rápida)
- 26.000 líneas eliminadas en un solo merge con confianza
- 88% de mis PRs y 66% de los de Ming llevan co-autoría de IA
Estas no son métricas de esfuerzo bruto. Ninguno de los dos trabajó fines de semana ni trasnochó. La velocidad viene de eliminar el tiempo muerto: las reuniones de handoff, los malentendidos en las specs, el ida y vuelta de "¿puedes mover esto 4px?". Cuando la intención de diseño fluye directamente al código, y la ingeniería extiende ese código in-place, simplemente hay menos desperdicio.
Qué significa esto para los equipos
No estoy diciendo que todos los equipos deban trabajar así. Este flujo de trabajo surgió de nuestro contexto específico: un equipo pequeño, una oportunidad de reconstrucción greenfield y acceso temprano a herramientas de codificación con IA capaces. Los resultados pueden variar.
Pero sí creo que el cambio subyacente es universal: la frontera entre diseño e ingeniería se está disolviendo, y la IA es el disolvente. A medida que las herramientas de IA mejoran en traducir intención a código, más diseñadores harán deploy de código directamente. Cuando eso ocurra, los ingenieros dedicarán menos tiempo a la traducción y más a la arquitectura, la calidad y la entrega.
El trabajo del ingeniero frontend no va a desaparecer. Está cambiando de forma. Y siendo honesto, la nueva forma es más interesante.
Yuma es ingeniero frontend en VM0, donde construye la plataforma que impulsa a Zero, un sistema operativo de agentes de IA. Ha eliminado más código legacy del que le gustaría admitir.