É assim que me sinto em relação à programação por vibrações. Qualquer projeto que eu tente que tenha algum tipo de complicação tem esse impulso imediato de progresso. As coisas são incríveis e parece que é um superpoder. Então... à medida que adiciono mais complexidade, as coisas param de funcionar. Os únicos projetos que acho que posso criar são aqueles que se encaixam nesta "zona de vibração". Protótipos, UIs, produtos—qualquer coisa que seja simples e tenha baixa complexidade se encaixa bem nessa zona. Provas de conceito, interações, coisas assim. As ferramentas conseguem fazer coisas que se encaixam nesse espaço. Mas. Tudo desmorona à medida que essa curva de complexidade aumenta. E o problema é que qualquer bom processo de design de produto tem complexidade crescente. Um protótipo básico se transforma em um bom protótipo assim que tem interações em camadas, transições, boas affordances, estados de hover, 1000 pequenos detalhes que fazem algo parecer correto e real. O benefício da programação por vibrações deveria ser que você se move rápido e consegue produzir coisas—deixando a IA fazer todo o trabalho por você. O problema é que perde força assim que a complexidade necessária é adicionada. Ele continua se refazendo, reescrevendo código, afetando coisas que não estão relacionadas e, em seguida, causando outros problemas. Mas se você adicionar essa complexidade, cada sessão de programação por vibrações rapidamente se transforma em uma sessão de caça a bugs estilo whack-a-mole. Não tenho certeza da solução para isso. Com o protótipo tradicional, a solução é duplicar, adicionar mais complexidade, criar mais quadros/cenas, ajustar, bifurcar, etc. No entanto, com a programação por vibrações, um pequeno comando pode destruir literalmente tudo. Há um estágio em que acabo andando em cascas de ovos de comandos—tentando não dar muito ou pouco contexto para que não fique fora de controle e quebre tudo. Há apenas algumas exceções a isso. @cursor e @framer. Consigo fazer grandes progressos com o Cursor, dar um contexto restrito, e tenho que aprovar as edições que ele faz. Isso parece um fluxo de trabalho correto. O problema é que não consigo ver a coisa que ele está criando porque é um IDE, não um ambiente visual. Sim, posso criar builds locais e atualizar meu navegador e todo esse tipo de coisa. Mas o aspecto visual está totalmente perdido na experiência de codificação. É uma ferramenta para desenvolvedores. O Framer acerta nisso porque só permite atualizações restritas dentro de um único componente na página. Sim, é limitante porque só pode fazer uma única coisa de cada vez, mas pelo menos não está tentando criar a página inteira do zero e gerenciá-la toda através de uma interface de comandos. Esses parecem ser a abordagem certa. @Cursor: Permita que a IA edite qualquer coisa, mas permita que o usuário aprove essas edições e as veja em contexto. @Framer: Permita que a IA edite apenas um único arquivo ou componente de forma restrita para manter a complexidade ao mínimo e reduzir edições catastróficas. Estou otimista de que ferramentas como @Figma, @Lovable, @Bolt e @V0 possam fazer protótipos legais, mas continuo esbarrando em barreiras quando se trata de fazer algo mais do que apenas um protótipo de interação básico. Elas precisam fazer menos, na minha opinião. Espero que essas ferramentas adicionem mais controles que estejam na mesma linha do Cursor e do Framer. Também acrescentarei que isso é semelhante a como fazemos com a geração de gráficos do @Basedash também. Mas não somos uma ferramenta de vibração no sentido normal, então os paralelos são um pouco mais difíceis de traçar.