Así es como me siento acerca de la codificación de vibraciones. Cualquier proyecto que intente 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. Entonces... a medida que agrego más complejidad, las cosas se detienen. Los únicos proyectos que creo que puedo crear son los que caen en esta "zona de vibración". Prototipos, interfaces de usuario, productos: cualquier cosa que sea simple y tenga poca complejidad encaja perfectamente en esa zona. Prueba de conceptos, 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 cada vez mayor. Un prototipo básico se convierte en un buen prototipo tan pronto como tiene interacciones en capas, transiciones, buenas posibilidades, estados de desplazamiento, 1000 pequeños detalles que hacen que algo se sienta correcto y real. Se supone que el beneficio de la codificación de vibración es que te mueves rápido y puedes sacar las cosas, dejando que la IA haga todo el trabajo por ti. El problema es que pierde fuerza tan pronto como se agrega la complejidad necesaria. Sigue rehaciéndose a sí mismo, reescribiendo código, afectando cosas que no están relacionadas y luego causando otros problemas. Pero si agrega esa complejidad, cada sesión de codificación de vibraciones se convierte rápidamente en una sesión de ataque de errores. No estoy seguro de la solución a esto. Con la creación de prototipos tradicionales, la solución es duplicar, agregar más complejidad, crear más cuadros/escenas, ajustar, bifurcar, etc. Sin embargo, con la codificación de vibraciones, un pequeño aviso puede destruir literalmente todo. Hay una etapa en la que termino caminando sobre cáscaras de huevo rápidas, tratando de no darle demasiado o muy poco contexto para que no se vuelva rebelde y rompa todo. Solo hay unas pocas excepciones a esto. @cursor y @framer. Puedo hacer un gran progreso 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 lo que está haciendo porque es un IDE, no un entorno visual. Sí, puedo crear compilaciones locales y actualizar mi navegador y todo ese tipo de cosas. Pero el aspecto visual se pierde por completo de la experiencia de codificación. Es una herramienta para desarrolladores. Framer lo hace bien porque solo permite actualizaciones limitadas dentro de un solo componente de 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 administrarla a través de una interfaz rápida. Estos parecen ser el enfoque correcto. @Cursor: Permita que la IA edite cualquier cosa, pero permita que el usuario apruebe esas ediciones y las vea en contexto. @Framer: Permita que la IA edite solo un archivo o componente de forma limitada para mantener la complejidad al mínimo y reducir las ediciones catastróficas. Soy optimista de que herramientas como @Figma, @Lovable, @Bolt y @V0 pueden hacer prototipos geniales, pero sigo tropezando con paredes cuando se trata de hacer algo más que un prototipo de interacción básico. Necesitan hacer menos en mi opinión. Espero que esas herramientas agreguen más controles que estén en la misma línea que Cursor y Framer. También agregaré que esto es similar a cómo lo hacemos con @Basedash generación de gráficos. Pero no somos una herramienta de vibración en el sentido normal, por lo que los paralelismos son un poco más difíciles de trazar.