Así es como me siento acerca de la codificación de vibra. Cualquier proyecto que intento que tenga algún tipo de complicación tiene este estallido inmediato de progreso. Las cosas son increíbles y se siente como un superpoder. Luego... a medida que añado más complejidad, las cosas se detienen por completo. Los únicos proyectos que creo que puedo crear son aquellos que caen en esta "zona de vibra". Prototipos, interfaces de usuario, productos—cualquier cosa que sea simple y tenga baja complejidad encaja perfectamente en esa zona. Pruebas de concepto, interacciones, cosas así. Las herramientas pueden hacer cosas que encajan en ese espacio. Pero. Todo se desmorona a medida que aumenta esa curva de complejidad. Y el problema es que cualquier buen proceso de diseño de productos tiene una complejidad creciente. Un prototipo básico se convierte en un buen prototipo tan pronto como tiene interacciones en capas, transiciones, buenas affordances, estados de hover, 1000 pequeños detalles que hacen que algo se sienta correcto y real. El beneficio de la codificación de vibra se supone que es que te mueves rápido y puedes sacar cosas—dejando que la IA haga todo el trabajo por ti. El problema es que pierde impulso tan pronto como se añade la complejidad necesaria. Sigue rehaciendo, reescribiendo código, afectando cosas que no están relacionadas y luego causando otros problemas. Pero si añades esa complejidad, cada sesión de codificación de vibra rápidamente se convierte en una sesión de aplastar errores como en un juego de whack-a-mole. No estoy seguro de la solución a esto. Con el prototipado tradicional, la solución es duplicar, añadir más complejidad, crear más marcos/escenas, ajustar, bifurcar, etc. Sin embargo, con la codificación de vibra, un pequeño aviso puede destruir literalmente todo. Hay una etapa en la que termino caminando sobre cáscaras de huevo de aviso—tratando de no darle demasiado o muy poco contexto para que no se vuelva rebelde y rompa todo. Hay solo unas pocas excepciones a esto. @cursor y @framer. Puedo hacer grandes progresos con Cursor, darle un contexto estrecho, y tengo que aprobar las ediciones que hace. Esto se siente como un flujo de trabajo correcto. El problema es que no puedo ver la cosa que está creando porque es un IDE, no un entorno visual. Sí, puedo crear compilaciones locales y refrescar mi navegador y todo ese tipo de cosas. Pero el aspecto visual se pierde totalmente de la experiencia de codificación. Es una herramienta para desarrolladores. Framer lo hace bien porque solo permite actualizaciones estrechas dentro de un solo componente en la página. Sí, es limitante porque solo puede hacer una sola cosa a la vez, pero al menos no está tratando de crear toda la página desde cero y gestionarlo todo a través de una interfaz de aviso. Estos parecen ser el enfoque correcto. @Cursor: Permitir que la IA edite cualquier cosa pero permitir que el usuario apruebe esas ediciones y las vea en contexto. @Framer: Permitir que la IA solo edite estrechamente un solo archivo o componente para mantener la complejidad al mínimo y reducir ediciones catastróficas. Soy optimista de que herramientas como @Figma, @Lovable, @Bolt y @V0 pueden hacer prototipos geniales, pero sigo encontrando muros cuando se trata de hacer algo más que solo un prototipo de interacción básico. Necesitan hacer menos en mi opinión. Espero que esas herramientas añadan más controles que estén en la misma línea que Cursor y Framer. También añadiré que esto es similar a cómo lo hacemos con la generación de gráficos de @Basedash también. Pero no somos una herramienta de vibra en el sentido normal, así que los paralelismos son un poco más difíciles de trazar.