É assim que me sinto sobre a codificação de vibração. Qualquer projeto que eu tente que tenha qualquer tipo de complicação tem essa explosão imediata de progresso. As coisas são incríveis e parece um superpoder. Então... à medida que adiciono mais complexidade, as coisas param. Os únicos projetos que acho que posso criar são aqueles que se enquadram nessa "zona de vibração". Protótipos, interfaces de usuário, produtos - qualquer coisa que seja simples e tenha baixa complexidade se encaixa perfeitamente nessa zona. Prova de conceitos, interações, coisas assim. As ferramentas são capazes de fazer coisas que se encaixam nesse slot. Mas. Tudo desmorona à medida que a 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 foco, 1000 pequenos detalhes que fazem algo parecer correto e real. O benefício da codificação de vibração deve ser que você se move rápido e pode sacar as coisas - deixando a IA fazer todo o trabalho para você. O problema é que ele 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 causando outros problemas. Mas se você adicionar essa complexidade, cada sessão de codificação de vibração rapidamente se transforma em uma sessão de ataque a bugs. Não tenho certeza da solução para isso. Com a prototipagem tradicional, a solução é duplicar, adicionar mais complexidade, criar mais quadros/cenas, ajustar, bifurcar, etc. No entanto, com a codificação de vibração, um pequeno prompt pode destruir literalmente tudo. Há um estágio em que acabo pisando em ovos imediatos - tentando não dar muito ou pouco contexto para que não se torne desonesto e quebre tudo. Existem apenas algumas exceções a isso. @cursor e @framer. Posso fazer um grande progresso com o Cursor, dar-lhe um contexto estreito e tenho que aprovar as edições que ele faz. Isso parece um fluxo de trabalho correto. O problema é que não consigo ver o que está fazendo porque é um IDE, não um ambiente visual. Sim, posso criar compilações locais e atualizar meu navegador e todo esse tipo de coisa. Mas o aspecto visual é totalmente perdido com a experiência de codificação. É uma ferramenta de desenvolvedor. O Framer acerta porque só permite atualizações restritas em um único componente da página. Sim, é limitante porque só pode fazer uma única coisa de uma vez, mas pelo menos não está tentando criar a página inteira do zero e gerenciá-la por meio de uma interface de prompt. Esta parece 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 no contexto. @Framer: Permita que a IA edite apenas um único arquivo ou componente para manter a complexidade no mínimo e reduzir edições catastróficas. Estou otimista de que ferramentas como @Figma, @Lovable, @Bolt e @V0 podem fazer protótipos legais, mas continuo batendo em paredes quando se trata de fazer algo mais do que apenas um protótipo básico de interação. Eles precisam fazer menos IMO. Espero que essas ferramentas adicionem mais controles que estão na mesma linha que Cursor e Framer. Também acrescentarei que isso é semelhante a como fazemos com @Basedash geração de gráficos. 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.