Вайб-кодинг мозгами и руками продакт-менеджера, новая порция наблюдений и советов, Часть 2 (часть 1):
– Кто-бы мог подумать, но изначально правильно выбранный стэк технологий – залог стабильного ИИ/кода, времени, нервов и токенов.
Нет, я знал это ещё с древних времен, но не знал, что в 2026 ИИ столкнётся с той же самой проблемой и vanilla.js (хаха) окажется всё той же самой ванилой по сравнению с тем же React. Теперь я понял всю глубину этого мема разрабов. Ну не знал я про ванилу, не смейтесь! ))
Поэтому переписать проект с нуля на React/другом фреймворке вместо рефакторинга ИИндийского ванилакода – отличная идея! Ошибок меньше, а если и есть, то находятся и фиксятся в разы быстрее за счёт рамок фреймворка.
– Особенно помогает просить написать ИИ новое тех. задание с учётом всех ранее найденных механик багов, но не используя какой-то один язык программирования, а оставаясь на уровне юзкейсов и общей архитектуры и связей. Далее, это тз можно применять к разных фрейморкам и языкам не переживая, что ИИ затащит в новое какую-то специфичную реализацию из старого языка.
– Разделяй всё. Не только на уровне модулей, но и на уровне написания кода в разрезе механик UX/UI (хотя, возможно, это об одном и том же).
Условный тулбар с переключением разделов, уведомлениями и настройками это 3 разных направления кодинга, несмотря на то, что они в 1 визуальном блоке.
Ты можешь попросить сверстать, ок, но если просишь ИИ скодить бэк и синкать фронт под это сразу, то она тупит из-за обилия зависимостей и связей и начинает костылять и глючить, поэтому иди по шагам по каждой механике/разделу/фиче, тестируй и фикси всё поэтапно и поштучно, а не проси всё сверстать и скодить за один промпт, иначе потом закопаешь себя и ИИ в фиксах всего и сразу. Да и в один промпт-прогон не влезет.
– Аналогично это и про приоритизацию последовательности кодинга для ИИ.
Образно для понимания: неправильно сначала делать условные уведомления, а потом пилить сущности под них. Это не-ло-гич-но и непоследовательно. Сначала детальная проработка и кодинг верхнеуровневых объектов, сущностей, зависимостей/связей, и только потом окружение и обвесы под и вокруг них.
– Объединяй всё, что нужно/можно. Образно, если у тебя форма комментов и форма создания записи и их use flow един (почему нет?), то тебе нужен единый и один редактор-скрипт-вызов (хз как правильно сказать, яжнеразраб) текста внутри них. 2+ разных функции и вот у ИИ уже 2+ потенциальных места для багов/рассинхрона/конфликтов и провалов памяти.
– Вырезай всё, что неважно. Безжалостно и без мыслей "нууу, ИИ всё равно же, что кодить, пусть пишет". Ей-то всё равно и она напишет, вопрос лишь в качестве ИИ-кода и багов, влияющих на корфичи и количестве тех. долга по ним.
– Даже если ты попросил о чём-то ИИ, то эта дрянь всё равно рано или поздно забывает и начнёт торопиться, выдавая тебе свои мысли и советы о том, как бы она всё это уже сделала и реализовала, забивая и размывая себе память и прожигая токены вариантами и догадками. У меня она, походу, чухнула мою профессию, и уже начала гипотезы выдвигать вместо уточнений. Серьёзно, так и пишет: "Гипотеза №1 в том, что это может быть...".
Тормози её! И допом к переспрашиванию её понимания баги/фикса/задачи, проси её написать по ней.... полноценный use case/story.
Так ты увидишь насколько правильно машина видит и понимает весь use flow процесса/продукта, твою задачу, что ограничит и сузит её гадания и, заодно, ты и сам в голове прокрутишь всё это ещё раз.
– Тоже самое про тебя – не ленись читать аннотации и размышления ИИ о том, что она там пилит для тебя. Всё довольно понятно и у тебя у самого в голове структурируется продукт, его сущности и механики. Не всё же на дизайн-системы медитировать.
– Кстати, с дизайн-системами под вайб-кодинг новый приятный трип в виде организации в Figma компонентов, variables, стэйтов и всего прочего, чтобы скормить это потом Claude Code. Новая форма релаксации мозгов. Каеф.
– И, да – я перешёл на эту дрянь.
🥭 Залипать, родная, не рановато, уже
– Кто-бы мог подумать, но изначально правильно выбранный стэк технологий – залог стабильного ИИ/кода, времени, нервов и токенов.
Нет, я знал это ещё с древних времен, но не знал, что в 2026 ИИ столкнётся с той же самой проблемой и vanilla.js (хаха) окажется всё той же самой ванилой по сравнению с тем же React. Теперь я понял всю глубину этого мема разрабов. Ну не знал я про ванилу, не смейтесь! ))
Поэтому переписать проект с нуля на React/другом фреймворке вместо рефакторинга ИИндийского ванилакода – отличная идея! Ошибок меньше, а если и есть, то находятся и фиксятся в разы быстрее за счёт рамок фреймворка.
– Особенно помогает просить написать ИИ новое тех. задание с учётом всех ранее найденных механик багов, но не используя какой-то один язык программирования, а оставаясь на уровне юзкейсов и общей архитектуры и связей. Далее, это тз можно применять к разных фрейморкам и языкам не переживая, что ИИ затащит в новое какую-то специфичную реализацию из старого языка.
– Разделяй всё. Не только на уровне модулей, но и на уровне написания кода в разрезе механик UX/UI (хотя, возможно, это об одном и том же).
Условный тулбар с переключением разделов, уведомлениями и настройками это 3 разных направления кодинга, несмотря на то, что они в 1 визуальном блоке.
Ты можешь попросить сверстать, ок, но если просишь ИИ скодить бэк и синкать фронт под это сразу, то она тупит из-за обилия зависимостей и связей и начинает костылять и глючить, поэтому иди по шагам по каждой механике/разделу/фиче, тестируй и фикси всё поэтапно и поштучно, а не проси всё сверстать и скодить за один промпт, иначе потом закопаешь себя и ИИ в фиксах всего и сразу. Да и в один промпт-прогон не влезет.
– Аналогично это и про приоритизацию последовательности кодинга для ИИ.
Образно для понимания: неправильно сначала делать условные уведомления, а потом пилить сущности под них. Это не-ло-гич-но и непоследовательно. Сначала детальная проработка и кодинг верхнеуровневых объектов, сущностей, зависимостей/связей, и только потом окружение и обвесы под и вокруг них.
– Объединяй всё, что нужно/можно. Образно, если у тебя форма комментов и форма создания записи и их use flow един (почему нет?), то тебе нужен единый и один редактор-скрипт-вызов (хз как правильно сказать, яжнеразраб) текста внутри них. 2+ разных функции и вот у ИИ уже 2+ потенциальных места для багов/рассинхрона/конфликтов и провалов памяти.
– Вырезай всё, что неважно. Безжалостно и без мыслей "нууу, ИИ всё равно же, что кодить, пусть пишет". Ей-то всё равно и она напишет, вопрос лишь в качестве ИИ-кода и багов, влияющих на корфичи и количестве тех. долга по ним.
– Даже если ты попросил о чём-то ИИ, то эта дрянь всё равно рано или поздно забывает и начнёт торопиться, выдавая тебе свои мысли и советы о том, как бы она всё это уже сделала и реализовала, забивая и размывая себе память и прожигая токены вариантами и догадками. У меня она, походу, чухнула мою профессию, и уже начала гипотезы выдвигать вместо уточнений. Серьёзно, так и пишет: "Гипотеза №1 в том, что это может быть...".
Тормози её! И допом к переспрашиванию её понимания баги/фикса/задачи, проси её написать по ней.... полноценный use case/story.
Так ты увидишь насколько правильно машина видит и понимает весь use flow процесса/продукта, твою задачу, что ограничит и сузит её гадания и, заодно, ты и сам в голове прокрутишь всё это ещё раз.
– Тоже самое про тебя – не ленись читать аннотации и размышления ИИ о том, что она там пилит для тебя. Всё довольно понятно и у тебя у самого в голове структурируется продукт, его сущности и механики. Не всё же на дизайн-системы медитировать.
– Кстати, с дизайн-системами под вайб-кодинг новый приятный трип в виде организации в Figma компонентов, variables, стэйтов и всего прочего, чтобы скормить это потом Claude Code. Новая форма релаксации мозгов. Каеф.
– И, да – я перешёл на эту дрянь.
🥭 Залипать, родная, не рановато, уже