Ось як я ставлюся до вайб-кодування. Будь-який проект, за який я беруся, який має будь-які ускладнення, має цей миттєвий сплеск прогресу. Речі дивовижні, і це відчувається як суперсила. То... У міру того, як я додаю більше складності, все зупиняється. Єдині проекти, які, на мою думку, я можу створити, це ті, які потрапляють у цю «зону вайбу». Прототипи, інтерфейси користувача, продукти — все, що є простим і має низьку складність, вписується саме в цю зону. Доведення концепцій, взаємодій тощо. Інструменти здатні робити речі, які поміщаються в цей слот. Але. Все розвалюється на шматки в міру того, як ця крива складності збільшується. І проблема полягає в тому, що будь-який хороший процес проектування продукту має все більшу складність. Базовий прототип перетворюється на хороший прототип, як тільки в ньому є багатошарові взаємодії, переходи, хороші можливості, стани наведення, 1000 крихітних деталей, які змушують щось відчувати себе правильним і реальним. Перевага вайб-кодування полягає в тому, що ви рухаєтеся швидко і можете досягти успіху, дозволяючи штучному інтелекту зробити всю роботу за вас. Проблема в тому, що він втрачає пару, як тільки додається необхідна складність. Він продовжує переробляти себе, переписувати код, впливаючи на речі, які не пов'язані між собою, а потім викликаючи інші проблеми. Але якщо ви додасте цю складність, кожен сеанс кодування вайбра швидко перетворюється на сеанс боротьби з помилками. Я не впевнений, як це вирішити. З традиційним прототипуванням рішення полягає в дублюванні, додаванні більшої складності, створенні більшої кількості кадрів/сцен, налаштуванні, розгалуженні тощо. Однак при кодуванні вайбу одна маленька підказка може знищити буквально все. Є етап, коли я закінчую ходити по швидкій яєчній шкаралупі – намагаюся не давати їй занадто багато або занадто мало контексту, щоб це не пішло не в глухий кут і не зламало все. Є лише кілька винятків. @cursor і @framer. Я можу досягти значного прогресу з Cursor, надати йому вузький контекст, і я повинен схвалювати редагування, які він вносить. Це здається правильним робочим процесом. Проблема в тому, що я не бачу того, що він робить, тому що це IDE, а не візуальне середовище. Так, я можу створювати локальні збірки, оновлювати браузер і все таке інше. Але візуальний аспект повністю втрачається від досвіду кодування. Це інструмент для розробників. Framer отримує це право, оскільки дозволяє лише вузькі оновлення в межах одного компонента на сторінці. Так, це обмежує, тому що він може робити лише одну дію одразу, але принаймні він не намагається створити всю сторінку з нуля та керувати нею всім через інтерфейс швидкого доступу. Це здається правильним підходом. @Cursor: Дозвольте штучному інтелекту редагувати що завгодно, але дозвольте користувачеві схвалювати ці редагування та бачити їх у контексті. @Framer. Дозвольте штучному інтелекту редагувати лише вузько один файл або компонент, щоб звести складність до мінімуму та зменшити катастрофічні редагування. Я оптимістично дивлюся на те, що такі інструменти, як @Figma, @Lovable, @Bolt та @V0 можуть створювати круті прототипи, але я просто продовжую стикатися зі стінами, коли справа доходить до створення чогось більшого, ніж просто прототип базової взаємодії. Їм потрібно робити менше IMO. Сподіваюся, що ці інструменти додадуть більше елементів керування, які знаходяться в тому ж рядку, що й Курсор і Фреймер. Також додам, що це схоже на те, як ми це робимо з генерацією @Basedash графіків. Але ми не є інструментом вайбу в звичайному розумінні, тому провести паралелі трохи складніше.