Google Stitch Quiere Acabar con la Entrega de Diseño

La entrega de diseño ha estado rota durante décadas. Los diseñadores producen maquetas perfectas al píxel en Figma. Los ingenieros las reconstruyen desde cero en código — ligeramente incorrectas, siempre ligeramente incorrectas. Redlines, capas de anotaciones, acceso al modo desarrollador, suscripciones a Zeplin, componentes en Storybook: toda la industria ha construido herramientas multimillonarias para parchear una brecha que, en teoría, no debería existir.

Google cree tener una respuesta diferente. Se llama Stitch.

Qué Es Stitch en Realidad

Stitch es la nueva herramienta de generación de UI impulsada por IA de Google, anunciada esta semana, que toma prompts de texto y capturas de pantalla como entrada y genera código de UI listo para producción. Apúntala a un boceto rough o a una pantalla existente. Describe lo que quieres. Obtén el código del componente.

Ese enfoque — prompt como entrada, código de UI como salida — suena familiar porque lo es. Hemos visto variaciones de v0 (Vercel), Locofy, Anima y media docena más. Pero los detalles del enfoque de Google importan aquí. Stitch está construido sobre Gemini, está profundamente integrado en las ambiciones de flujo de trabajo de diseño a código de Google, y está posicionado explícitamente como una herramienta para que tanto diseñadores como ingenieros la usen en el mismo punto del proceso. No de forma secuencial — simultáneamente.

Ahí está el radicalismo silencioso enterrado en el anuncio. La premisa no es "ayudaremos a los ingenieros a implementar diseños más rápido". Es "haremos que la entrega misma quede obsoleta".

La Entrega Siempre Ha Sido una Cuestión de Confianza

Esto es lo que la gente pasa por alto cuando habla de herramientas para la entrega de diseño: el problema nunca fue realmente sobre formatos de archivo o precisión de redlines. Es sobre confianza y autoridad.

Cuando un diseñador entrega especificaciones a un ingeniero, hay una negociación implícita ocurriendo. El diseñador está diciendo: así es como debería verse. El ingeniero está diciendo: esto es lo que realmente puedo construir. El documento de entrega es un contrato — imperfecto, frecuentemente disputado, constantemente renegociado a medida que emergen restricciones durante la implementación.

Herramientas como el modo desarrollador de Figma intentaron honrar ese contrato haciendo las especificaciones más legibles. Stitch intenta disolver el contrato por completo al colapsar los dos roles en un único artefacto: código en ejecución.

La pregunta que nadie está respondiendo del todo todavía es si eso es mejor o simplemente diferente. Código generado que se ve bien pero no tiene estructura semántica, brechas de accesibilidad incorporadas a nivel del modelo, o arquitectura de componentes que choca con tu sistema de diseño existente — eso no es una victoria. Es una nueva categoría de error.

Dónde Falla Realmente el Código de UI Generado

Las demos siempre son convincentes. La realidad en producción suele ser más complicada. Algunos modos de fallo persistentes que vale la pena vigilar:

Coherencia del sistema de diseño. La UI generada tiende a producir estilos únicos — colores hardcodeados, tamaños inline, componentes que no heredan de tu sistema de tokens. Integrar la salida generada en un sistema de diseño maduro requiere ya sea un posprocesamiento sustancial o aceptar la divergencia. Ninguna de las dos opciones es gratis.

Accesibilidad. Las UIs generadas por IA son consistentemente malas con los roles ARIA, la gestión del foco y el HTML semántico. Un botón que parece un botón pero está implementado como un div con un onClick es una regresión, no un progreso. La cobertura continua de Smashing Magazine sobre la toma de decisiones de UX apunta exactamente a este tipo de decisión estructural que las herramientas rara vez toman correctamente de forma automática.

Estado y comportamiento. La generación de UI estática es un problema más o menos resuelto. En el momento en que introduces estado de formulario, estados de carga, condiciones de error y renderizado condicional, la salida generada se vuelve escasa. La mayoría de las herramientas siguen tratando la UI como un artefacto visual en lugar de un contrato de comportamiento.

Complejidad responsive. Generar un componente que funcione en un viewport es más fácil que generar uno que funcione en todos los viewports con los breakpoints adecuados y los cambios de layout. El artículo de Smashing Magazine sobre dropdowns en contenedores desplazables es un buen recordatorio de que incluso los ingenieros experimentados se equivocan en esto — y los modos de fallo no son evidentes hasta que aparecen usuarios reales.

La Apuesta Real que Está Haciendo Google

Que Google construya Stitch no es principalmente una jugada de productividad para desarrolladores. Es una jugada de retención de plataforma.

El flujo de trabajo de diseño a código es un entorno de alto costo de cambio. Los equipos que estandarizan en Figma, con plugins, sistemas de diseño, integraciones del modo desarrollador y bibliotecas compartidas, no cambian fácilmente. Google ha tenido dificultades para establecerse aquí — Google Slides no es Figma, y sus esfuerzos anteriores en herramientas de diseño no han perdurado.

Stitch es el intento de Google de entrar en la conversación en el momento de mayor valor: cuando las decisiones de diseño se convierten en decisiones de ingeniería. Si Stitch logra integrarse en ese flujo de trabajo — especialmente a través de integraciones con la API de Gemini sobre las que otras herramientas puedan construir — Google obtiene un gancho persistente en una de las partes más adhesivas del ciclo de vida del desarrollo de producto.

Por eso el reciente post del GitHub Blog sobre generación de código con IA para accesibilidad es un contexto interesante aquí: las guerras de plataformas en torno al desarrollo asistido por IA se están librando exactamente en estas junturas entre diseño e ingeniería, entre generación de código y calidad de código.

Qué Deberían Hacer los Ingenieros con Esto Ahora Mismo

Sáltate el ciclo del hype y trata Stitch como cualquier otra herramienta de generación de código: útil para scaffolding, peligrosa si se trata como salida terminada.

Específicamente:

• Úsala para prototipos desechables. Para herramientas internas, pantallas de prueba de concepto, o demos para clientes donde la calidad del código no es el objetivo — Stitch (y herramientas similares) son genuinamente rápidas. Entrega el concepto, desecha el código.
• No conectes la UI generada directamente a tu sistema de diseño. Pasa la salida generada por tu linter, tu verificador de accesibilidad y tu suite de regresión visual antes de hacer merge. Trátala como código de un junior entusiasta que aún no conoce tus convenciones.
• Vigila la capa de tokens. Si los componentes generados están hardcodeando #1A73E8 en lugar de var(--color-primary), tienes un problema de coherencia del sistema de diseño que se multiplicará rápido a escala.
• Audita el HTML semántico. Antes de publicar cualquier UI generada por IA, ejecútala a través de un inspector del árbol de accesibilidad. Lo que visualmente parece correcto frecuentemente es estructuralmente incorrecto.

La comunidad de CSS-Tricks ha estado documentando exactamente este tipo de brechas estructurales en el código frontend generado durante el último año — la brecha entre "se ve bien en una captura de pantalla" y "funciona correctamente bajo condiciones reales" sigue siendo amplia.

La Entrega No Ha Muerto. Solo Se Está Moviendo.

Stitch no acabará con la entrega de diseño. Lo que podría hacer es mover el lugar donde ocurre la negociación — antes en el proceso, a nivel del prompt en lugar de a nivel del redline.

Eso no es obviamente mejor. Las decisiones a nivel de prompt son más difusas y más difíciles de auditar que las especificaciones anotadas de Figma. "Que se vea moderno" no es una especificación. Pero los prompts son más rápidos de iterar, más fáciles de compartir entre disciplinas, y más legibles para las partes interesadas que nunca aprendieron a leer los comentarios de Figma.

La historia real aquí no es sobre Google o Stitch específicamente. Es sobre dónde vive la autoridad de diseño en un mundo donde generar una UI plausible se está volviendo casi gratuito. Si cualquiera puede generar una pantalla desde un prompt, la habilidad escasa no es "hacer que se vea bien" — es saber por qué las decisiones detrás de ella son correctas, y qué atajos generados van a romper a usuarios reales seis meses después.

Ese juicio no viene del modelo. Sigue viniendo de las personas.