Вот как я отношусь к кодированию по настроению. Любой проект, который я пытаюсь реализовать и который имеет хоть какую-то сложность, сразу же демонстрирует всплеск прогресса. Всё потрясающе, и это ощущается как суперсила. Затем... по мере добавления сложности всё останавливается. Единственные проекты, которые, как мне кажется, я могу создать, это те, которые попадают в эту "зону настроения". Прототипы, пользовательские интерфейсы, продукты — всё, что простое и имеет низкую сложность, идеально вписывается в эту зону. Доказательства концепций, взаимодействия, что-то в этом роде. Инструменты способны создавать вещи, которые подходят под это определение. Но. Всё разваливается, как только эта кривая сложности начинает расти. И проблема в том, что любой хороший процесс проектирования продукта имеет возрастающую сложность. Базовый прототип превращается в хороший прототип, как только он получает многослойные взаимодействия, переходы, хорошие возможности, состояния наведения, 1000 мелких деталей, которые делают что-то правильным и реальным. Преимущество кодирования по настроению должно заключаться в том, что вы движетесь быстро и можете создавать вещи — позволяя ИИ делать всю работу за вас. Проблема в том, что оно теряет динамику, как только добавляется необходимая сложность. Оно продолжает переделывать себя, переписывать код, затрагивать несвязанные вещи и затем вызывать другие проблемы. Но если вы добавляете эту сложность, каждая сессия кодирования по настроению быстро превращается в сессию по борьбе с ошибками. Я не уверен, в чем решение этой проблемы. В традиционном прототипировании решение заключается в дублировании, добавлении большей сложности, создании большего количества фреймов/сцен, настройке, форке и т.д. Однако в кодировании по настроению один маленький запрос может разрушить буквально всё. Есть этап, когда я оказываюсь на "яйцах" запросов — стараясь не дать слишком много или слишком мало контекста, чтобы оно не вышло из-под контроля и не сломало всё. Есть лишь несколько исключений из этого. @cursor и @framer. Я могу добиться отличного прогресса с Cursor, дав ему узкий контекст, и мне нужно одобрять изменения, которые оно вносит. Это кажется правильным рабочим процессом. Проблема в том, что я не вижу то, что оно создает, потому что это IDE, а не визуальная среда. Да, я могу создавать локальные сборки и обновлять свой браузер и всё такое. Но визуальный аспект полностью теряется в процессе кодирования. Это инструмент для разработчиков. Framer делает это правильно, потому что он позволяет только узкие обновления в пределах одного компонента на странице. Да, это ограничивает, потому что он может делать только одно дело за раз, но, по крайней мере, он не пытается создать всю страницу с нуля и управлять ею через интерфейс запросов. Это кажется правильным подходом. @Cursor: Позвольте ИИ редактировать что угодно, но позвольте пользователю одобрять эти изменения и видеть их в контексте. @Framer: Позвольте ИИ редактировать только узкий файл или компонент, чтобы минимизировать сложность и уменьшить катастрофические изменения. Я оптимистично настроен, что такие инструменты, как @Figma, @Lovable, @Bolt и @V0, могут создавать классные прототипы, но я постоянно сталкиваюсь с препятствиями, когда дело доходит до чего-то большего, чем просто базовый прототип взаимодействия. Они должны делать меньше, на мой взгляд. Надеюсь, что эти инструменты добавят больше контролей, которые будут в том же духе, что и Cursor и Framer. Также добавлю, что это похоже на то, как мы делаем это с генерацией графиков @Basedash. Но мы не инструмент по настроению в обычном смысле, поэтому провести параллели немного сложнее.