Așa simt eu despre codarea vibrației. Orice proiect pe care îl încerc și care are orice fel de complicație are această explozie imediată de progres. Lucrurile sunt uimitoare și se simte ca o superputere. Apoi... pe măsură ce adaug mai multă complexitate, lucrurile se opresc. Singurele proiecte pe care cred că le pot crea sunt cele care se încadrează în această "zonă de vibrație". Prototipuri, interfețe de utilizare, produse - orice este simplu și are o complexitate redusă se potrivește perfect în acea zonă. Dovada conceptelor, interacțiuni, chestii de genul ăsta. Uneltele sunt capabile să facă lucruri care se potrivesc în acel slot. Dar. Totul se prăbușește pe măsură ce curba de complexitate crește. Iar problema este că orice proces bun de proiectare a produsului are o complexitate din ce în ce mai mare. Un prototip de bază se transformă într-un prototip bun de îndată ce are interacțiuni stratificate, tranziții, posibilități bune, stări de plutire, 1000 de mici detalii care fac ceva să pară corect și real. Avantajul codării vibe ar trebui să fie că te miști rapid și poți scoate lucrurile la bun sfârșit, lăsând AI să facă toată treaba pentru tine. Problema este că își pierde avântul de îndată ce se adaugă complexitatea necesară. Continuă să se refacă, să rescrie codul, să afecteze lucruri care nu au legătură și apoi să provoace alte probleme. Dar dacă adăugați această complexitate, fiecare sesiune de codare se transformă rapid într-o sesiune de lovire a cârtiței. Nu sunt sigur soluția la asta. Cu prototiparea tradițională, soluția este de a duplica, de a adăuga mai multă complexitate, de a crea mai multe cadre/scene, de a modifica, de a bifurca etc. Cu toate acestea, cu codarea vibe, un mic prompt poate distruge literalmente totul. Există o etapă în care ajung să merg pe coji de ouă prompte - încercând să nu-i dau prea mult sau prea puțin context, astfel încât să nu devină necinstit și să spargă totul. Există doar câteva excepții de la asta. @cursor și @framer. Pot face progrese mari cu Cursor, îi pot oferi un context restrâns și trebuie să aprob modificările pe care le face. Acesta pare un flux de lucru corect. Problema este că nu pot vedea lucrul pe care îl face pentru că este un IDE, nu un mediu vizual. Da, pot crea versiuni locale și îmi pot reîmprospăta browserul și tot felul de chestii de genul acesta. Dar aspectul vizual este total pierdut din experiența de codare. Este un instrument pentru dezvoltatori. Framer face acest lucru corect, deoarece permite doar actualizări înguste într-o singură componentă a paginii. Da, este limitativ pentru că poate face un singur lucru simultan, dar cel puțin nu încearcă să creeze întreaga pagină de la zero și să o gestioneze printr-o interfață promptă. Acestea par a fi abordarea corectă. @Cursor: Permiteți AI să editeze orice, dar permiteți utilizatorului să aprobe acele modificări și să le vadă în context. @Framer: Permiteți AI să editeze doar un singur fișier sau componentă pentru a menține complexitatea la minimum și pentru a reduce editările catastrofale. Sunt optimist că instrumente precum @Figma, @Lovable, @Bolt și @V0 pot face prototipuri interesante, dar mă lovesc de pereți când vine vorba de a face ceva mai mult decât un prototip de interacțiune de bază. Trebuie să facă mai puțin, IMO. Sper că aceste instrumente adaugă mai multe controale care sunt în aceeași linie cu Cursor și Framer. Voi adăuga, de asemenea, că acest lucru este similar cu modul în care o facem și cu generarea @Basedash grafice. Dar nu suntem un instrument de vibrație în sensul normal, așa că paralelele sunt puțin mai greu de trasat.