Beginilah perasaan saya tentang pengkodean getaran. Setiap proyek yang saya coba yang memiliki komplikasi apa pun memiliki ledakan kemajuan langsung. Hal-hal itu luar biasa dan rasanya seperti kekuatan super. Kemudian... saat saya menambahkan lebih banyak kompleksitas, segalanya terhenti. Satu-satunya proyek yang saya pikir dapat saya buat adalah proyek yang termasuk dalam "zona getaran" ini. Prototipe, UI, produk—apa pun yang sederhana dan memiliki kompleksitas rendah cocok dengan zona itu. Bukti konsep, interaksi, hal-hal seperti itu. Alat-alat tersebut mampu membuat hal-hal yang sesuai dengan slot itu. Tapi. Semuanya hancur berkeping-keping saat kurva kompleksitas itu meningkat. Dan masalahnya adalah bahwa setiap proses desain produk yang baik memiliki kompleksitas yang meningkat. Prototipe dasar berubah menjadi prototipe yang baik segera setelah memiliki interaksi berlapis, transisi, kemampuan yang baik, status hover, 1000 detail kecil kecil yang membuat sesuatu terasa benar dan nyata. Manfaat pengkodean getaran seharusnya adalah Anda bergerak cepat dan Anda dapat menyelesaikan segalanya—membiarkan AI melakukan semua pekerjaan untuk Anda. Masalahnya adalah kehilangan tenaga segera setelah kompleksitas yang diperlukan ditambahkan. Itu terus mengulang dirinya sendiri, menulis ulang kode, memengaruhi hal-hal yang tidak terkait dan kemudian menyebabkan masalah lain. Tetapi jika Anda menambahkan kerumitan itu, setiap sesi pengkodean getaran dengan cepat berubah menjadi sesi penghancuran bug. Saya tidak yakin solusi untuk ini. Dengan pembuatan prototipe tradisional, solusinya adalah menduplikasi, menambah lebih banyak kompleksitas, membuat lebih banyak bingkai/adegan, mengubah, bergarpu, dll. Namun dengan pengkodean getaran, satu prompt kecil dapat menghancurkan segalanya. Ada tahap di mana saya akhirnya berjalan di atas kulit telur yang cepat -- mencoba untuk tidak memberikannya terlalu banyak atau terlalu sedikit konteks sehingga tidak menjadi nakal dan merusak segalanya. Hanya ada beberapa pengecualian untuk ini. @cursor dan @framer. Saya dapat membuat kemajuan besar dengan Cursor, memberinya konteks sempit, dan saya harus menyetujui suntingan yang dibuatnya. Ini terasa seperti alur kerja yang benar. Masalahnya adalah, saya tidak dapat melihat hal yang dibuatnya karena ini adalah IDE, bukan lingkungan visual. Ya, saya dapat membuat build lokal dan menyegarkan browser saya dan semua hal semacam itu. Tetapi aspek visualnya benar-benar hilang dari pengalaman pengkodean. Ini adalah alat pengembang. Framer melakukannya dengan benar karena hanya mengizinkan pembaruan sempit dalam satu komponen di halaman. Ya, itu membatasi karena hanya dapat melakukan satu hal sekaligus, tetapi setidaknya tidak mencoba membuat seluruh halaman dari awal dan mengelola semuanya melalui antarmuka yang cepat. Ini tampaknya seperti pendekatan yang tepat. @Cursor: Izinkan AI untuk mengedit apa pun tetapi izinkan pengguna untuk menyetujui pengeditan tersebut dan melihatnya dalam konteks. @Framer: Izinkan AI hanya mengedit satu file atau komponen secara sempit untuk meminimalkan kompleksitas dan mengurangi pengeditan bencana. Saya optimis bahwa alat seperti @Figma, @Lovable, @Bolt, dan @V0 dapat membuat prototipe yang keren, tetapi saya terus menabrak dinding ketika harus melakukan sesuatu yang lebih dari sekadar prototipe interaksi dasar. Mereka perlu melakukan lebih sedikit IMO. Semoga alat-alat tersebut menambahkan lebih banyak kontrol yang berada di baris yang sama dengan Kursor dan Framer. Saya juga akan menambahkan bahwa ini mirip dengan cara kita melakukannya dengan pembuatan grafik @Basedash juga. Tapi kami bukan alat getaran dalam arti normal sehingga paralelnya sedikit lebih sulit untuk ditarik.