Вайбкодинг продукта продактом be like
Продолжаю кодить создавать некий-довольно-объемный по продуктовым и техническим меркам продукт с Claude, поделюсь наблюдениями:
– Не парь себе и ИИ мозги, не пиши на вайбе продукт с нуля, юзай опенсорс/CMS с уже: а) продуманной; б) раздельной архитектурой.
Мой случай – Wordpress, в котором есть ядро и есть отдельно /plugins и /themes. Ядро постоянно, стабильно и ИИ его не трогает, вся работа по разработке продукта ведётся через плагины (бэк) и темы (фронт). Всё ограничено, порционно, версионно и контролируемо. Сэкономишь ИИ мозги и себе токены и не будешь тратить 80% времени/нервов/токенов на ненужную проверку и переписывание одного и того же места (ядра) ради мелких фиксов по сто раз.
– Смотри в сторону Single Page Application с раздельными .js под каждую фичу/"страницу". Это снова про ограниченность, версионность и контроль работы для тебя и ИИ. Плюс, так снова правильно для архитектуры, когда приложения общаются между собой раздельно, а не один .js управляет всем и сразу (создавая конфликты и глюки сразу во всём).
– 1 фича-апдейт = 1 чат в рамках 1 проекта и не будет никаких галлюцинаций. Апгрейдишь фичу – в первом промпте прикладывай архив с исходником последней stable версии фичи с прода (или коннекть GitHub). Апгрейднул – CHANGELOG - чат закончен.
Иначе уже спустя 2 часа чата машина начинает путаться в данных/коде и любая попытка разрулить лишь закапывает её и тебя в галлюцинации и баги ещё больше.
– Фиксы/баги можно объединять в одном чате, ИИ лучше видит контекст и находит связи между ними, но лучше тоже не копить и делить по stable версиям.
– Объясняй всё для ИИ наглядным языком, уточняй контекст, расшифровывай механики, стейты и позиционирование объектов на странице c их идентификацией.
Помогает: а) единый словарь терминов и понятий для фич/механик в твоём продукте (определимся с терминами и понятиями, классика, 2018 год); б) через Console смотреть на название их css-стилей. Потому что даже одна оговорка или размытое понятие может быть непонятно для ИИ и она начнёт додумывать его за тебя, что приведет её к галлюцинации.
Твой промпт = тех. задание, "нет ТЗ = результат ХЗ", ещё одна классика середины нулевых передаёт привет из прошлого.
– Прикладывай к промптам скрины с выделенными ошибками, поясняя текстом что на скринах. Несколько раз Claude сама нашла на скрине места с дублирующейся багой, которые я проглядел, поняла их и это помогло ей пофиксить 2+ баги разом.
– Не торопи ИИ с кодом и не давай ей с ним торопиться, всегда проси подтверждений понимания твоих задач и уточнения со стороны ИИ и ты снова сэкономишь токены, нервы и время.
– Для сложных фич/механик вначале проси у ИИ описание двух вариантов возможных решений, потом проси третий вариант, потом проси придумать оптимальное и подходящее решение на основе этих трёх. У меня во всех случаях ИИ выбирала третий вариант и с первой итерации писала его без серьёзных ошибок, имея на руках полный контекст что ей делать и что не делать.
– CHANGELOG MD – ключ и мост между релизами. После каждого успешного апдейта (чата) проси ИИ писать: а) интро проекта с точки зрения обновлённого кода/архитектуры; б) выжимку по изменениям и включай их в него, прикладывая в новом чате и прося читать все изменения для понимания контекста.
Потому что ИЗМЕНЕНИЯ = КОНТЕКСТ. Веди его ручками, чтобы не жечь лишний раз каждым апдейтом токены на разрастающийся док (старую инфу можно нужно подчищать).
– Скиллы и прочие "ты в роли" зашей в CHANGELOG один раз, а не в системный промпт/скилс, чтобы не вызывать их скрыто в каждом промпте, прожигая твои токены (ты же не Ланнистер).
– Слышал, что рефакторить код лучше через разные модели, устраивать оркестрации, подключать тулзы и прочее. Я до этого ещё не дошел, Claude отлично справляется со всем своим добром сама прямо через окно чата и обмен файлами контекстом.
В общем, как-то так. Впервые столкнулся с тем, что код и прод убегают вперёд дизайна. Думаю скоро подрубить github, а там и до VS Code + copilot не за горами.
Я знал, что рано или поздно мы перейдем и на эту дрянь.
Продолжаю кодить создавать некий-довольно-объемный по продуктовым и техническим меркам продукт с Claude, поделюсь наблюдениями:
– Не парь себе и ИИ мозги, не пиши на вайбе продукт с нуля, юзай опенсорс/CMS с уже: а) продуманной; б) раздельной архитектурой.
Мой случай – Wordpress, в котором есть ядро и есть отдельно /plugins и /themes. Ядро постоянно, стабильно и ИИ его не трогает, вся работа по разработке продукта ведётся через плагины (бэк) и темы (фронт). Всё ограничено, порционно, версионно и контролируемо. Сэкономишь ИИ мозги и себе токены и не будешь тратить 80% времени/нервов/токенов на ненужную проверку и переписывание одного и того же места (ядра) ради мелких фиксов по сто раз.
– Смотри в сторону Single Page Application с раздельными .js под каждую фичу/"страницу". Это снова про ограниченность, версионность и контроль работы для тебя и ИИ. Плюс, так снова правильно для архитектуры, когда приложения общаются между собой раздельно, а не один .js управляет всем и сразу (создавая конфликты и глюки сразу во всём).
– 1 фича-апдейт = 1 чат в рамках 1 проекта и не будет никаких галлюцинаций. Апгрейдишь фичу – в первом промпте прикладывай архив с исходником последней stable версии фичи с прода (или коннекть GitHub). Апгрейднул – CHANGELOG - чат закончен.
Иначе уже спустя 2 часа чата машина начинает путаться в данных/коде и любая попытка разрулить лишь закапывает её и тебя в галлюцинации и баги ещё больше.
– Фиксы/баги можно объединять в одном чате, ИИ лучше видит контекст и находит связи между ними, но лучше тоже не копить и делить по stable версиям.
– Объясняй всё для ИИ наглядным языком, уточняй контекст, расшифровывай механики, стейты и позиционирование объектов на странице c их идентификацией.
Помогает: а) единый словарь терминов и понятий для фич/механик в твоём продукте (определимся с терминами и понятиями, классика, 2018 год); б) через Console смотреть на название их css-стилей. Потому что даже одна оговорка или размытое понятие может быть непонятно для ИИ и она начнёт додумывать его за тебя, что приведет её к галлюцинации.
Твой промпт = тех. задание, "нет ТЗ = результат ХЗ", ещё одна классика середины нулевых передаёт привет из прошлого.
– Прикладывай к промптам скрины с выделенными ошибками, поясняя текстом что на скринах. Несколько раз Claude сама нашла на скрине места с дублирующейся багой, которые я проглядел, поняла их и это помогло ей пофиксить 2+ баги разом.
– Не торопи ИИ с кодом и не давай ей с ним торопиться, всегда проси подтверждений понимания твоих задач и уточнения со стороны ИИ и ты снова сэкономишь токены, нервы и время.
– Для сложных фич/механик вначале проси у ИИ описание двух вариантов возможных решений, потом проси третий вариант, потом проси придумать оптимальное и подходящее решение на основе этих трёх. У меня во всех случаях ИИ выбирала третий вариант и с первой итерации писала его без серьёзных ошибок, имея на руках полный контекст что ей делать и что не делать.
– CHANGELOG MD – ключ и мост между релизами. После каждого успешного апдейта (чата) проси ИИ писать: а) интро проекта с точки зрения обновлённого кода/архитектуры; б) выжимку по изменениям и включай их в него, прикладывая в новом чате и прося читать все изменения для понимания контекста.
Потому что ИЗМЕНЕНИЯ = КОНТЕКСТ. Веди его ручками, чтобы не жечь лишний раз каждым апдейтом токены на разрастающийся док (старую инфу можно нужно подчищать).
– Скиллы и прочие "ты в роли" зашей в CHANGELOG один раз, а не в системный промпт/скилс, чтобы не вызывать их скрыто в каждом промпте, прожигая твои токены (ты же не Ланнистер).
– Слышал, что рефакторить код лучше через разные модели, устраивать оркестрации, подключать тулзы и прочее. Я до этого ещё не дошел, Claude отлично справляется со всем своим добром сама прямо через окно чата и обмен файлами контекстом.
В общем, как-то так. Впервые столкнулся с тем, что код и прод убегают вперёд дизайна. Думаю скоро подрубить github, а там и до VS Code + copilot не за горами.
Я знал, что рано или поздно мы перейдем и на эту дрянь.