Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 70
Закреплённые комментарии
я и не начинал вайбкодить
Грамотно.
Но это водопад. А надо или итерациями с усложнением или доказывать корректность ADR через прототипы и постоянно сомневаться в корректности задачи /контрактов. Постоянно "а что если" мы тут сделаем лучше, но придется тогда изменить контракт и вон тот код понадобится изменить. Особенно для легаси.
Учту ваш фидбэк
Итерациями с постоянным нарастанием функционала / усложнения это спиральная модель.
Прототипированием - можете назвать Spike-driven Waterfall. Бизнес-требования и этапы фиксированы, но каждый архитектурный или технический риск перед чистовой реализацией пробивается дешевым (с LLM) throwaway прототипом для оценки сложности реализации, определения зависимостей и влияния на другие части системы.
Можно поискать концепцию tracer bullet из Pragmatic Programmer.
Да, вспомнил!
Ещё демо для быстрой обратной связи от заинтересованных лиц. А для массового ПО - проверка a/b гипотез
Хорошо на LLM: быстро, дёшево, главное не забыть переписать на чистовик
Самый рабочий фильтр против «вайбкодинга» у нас оказался простым: PR без тестов и короткого ADR даже не смотрим.
Возьму на вооружение
А как это от вайбкодинга помогает? В промпте что нельзя тесты попросить написать или адрку?
не совсем понял, как это помогает. Вайбкодинг подразумевает генерацию тестов (как полезных, так и не очень), но факт в том что тесты и ADR слопятся в целом без проблем. Взять тот же OpenSpec
С подходом согласен, сам в какой-то момент к нему пришел. Спасибо за статью!
Если не я один пришел к такому подходу, значит схема рабочая :)
На мой взгляд, когда за рулем опытный разработчик, такие хорошо структурированные подходы сами собой появляются) Я помимо похожего подхода еще держу memory bank, и получается вполне качественно :)
Поясните пожалуйста про memory bank
В этой статье о SDD можно есть про memory bank:
https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
Согласен )
Не факт что рабочая, но точно самая логичная) заметил, что чем подробнее пишешь план и следишь за его исполнением, тем быстрее идет разработка. Спасибо за статью
Термин и движение «вайбкодинг», по-видимому, принесли больше вреда, чем пользы, раз появляются такие статьи. Но хорошо, что в итоге приходит осознание. Из статьи не увидел никакой конкретики.
Качество: - Соблюдай единый стиль проекта и best practices выбранного стека. - Не дублируй код: предпочитай переиспользование и понятные абстракции. - Не оставляй заглушек/“TODO”, если это не оговорено отдельным пунктом. - Пиши тесты там, где это критично для поведения/контрактов. - Если не уверен — перечисли варианты, но не делай скрытых допущений.
В проектах с большой кодовой базой такие промпты превращаются в практически ничто без конкретных спецификаций.
4) Предложи минимальный набор диаграмм/ADR, которые стоит зафиксировать.
Это особенно порадовало. Стоит зафиксировать по решению кого?
Покажите как нужно?
Может, и показал бы, да боюсь, что это будет очередной «рецепт пирожков моей бабушки, она готовит так», вроде этой статьи (да и то как-то бессвязно получалось, когда думал об этом). Я же не говорю, что тут что-то бесполезное. Очень интересно было бы посмотреть это все в деле. Я про то, что от подобных материалов хотелось бы больше конкретики на примерах, так сказать, а не сухой набор каких-то предписаний. Вообще с этим беда какая-то, много историй успешного успеха, а по фактам или это, или просто всякий шлак от ai коучей.
Тут вы правы)
Но в наш то век... можно и самому поставить эксперимент или разобраться.
Примеры промптов я предоставил в конце статьи
Я говорил не про примеры промптов. Примеров тонны, и почти все голословные, потому в общей массе не особо полезные. Я говорил про proof-of-concept - было-стало, делали так (а, б, в), ввели это, стало так (А, Б, В). Конкретно. Такие-то достижения, такие-то ограничения. Такой инфы на самом деле мало, и она была бы куба ценней очередной сухой выжимки.
Термин и движение «вайбкодинг», по-видимому, принесли больше вреда, чем пользы, раз появляются такие статьи.
AI, в частности LLM для кодинга - довольно молодая технология, и те кто ее используют, по сути пионеры в этой области. Ошибки - естественный и неотъемлемый процесс обучения.
Это особенно порадовало. Стоит зафиксировать по решению кого?
По решению разработчика ес-но, он решает какие ADR применять и фиксировать в проекте
Занимаюсь изучением и экспериментами с интерпретацией и формализацией аргументов систем кодирования совместно с llm. Могу сказать, что не надо заставлять их столько писать. Они не могут уместить в свое внимание такой пласт информации, даже если он вам говорит, что все понятно, то это не всегда так. Любая функция должна быть формализована, это сейчас передовое направление в науке llm кодирования. То есть модель идет лесом, если ее формализация кода не прошла авто проверку. Текстом он может расписать инструкцию, но чаще они вообще не понимают об уровне знаний пользователя, даже если сказать, что ты хлебушек или чайник). В ближайшие годы мы избавимся от ручного кодинга и перейдем на текстово формульный. Но только хз что будем с самими языками делать, как улучшать, чтобы увеличить эффективный контекст для llm. Статья полезна как альтернативный взгляд по укрощению llm. И AI был еще 50 лет назад, просто не такой развитой как сейчас, это он так аккумулировал и стрельнул.
Согласен, мы сейчас переживаем эпоху перехода от ручного кодинга к машинному. Полагаю, в скором будущем нас ждут обкатанные детерминированные системы для машинного кодинга. Скорее всего мы избавимся от привычного промпт-кодирования, и будем инженер будет иметь больше контроля над структурой и качеством кода
Я думаю, что промпт на английском языке для детерменированной кодогенерации будет очень похож на код на современном языке программирования ;)
Инженеры потому и могут работать с LLM, потому что понимают, как оно всё устроено и без LLM, способны формулировать задачу (с ограничениями!) и контролировать результат. Если же к LLM массово придёт молодёжь, которая не умеет ничего из перечисленного, то будет больно.
Какой ИИ был 50 назад ?
Использую плюс-минус тот же принцип. Единственное отличие, у меня отдельный чат на QA и тесты, он же обновляет план по части сделано/долги.
И, если честно, я начинаю подумывать на тему "каждому агенту свой файл хранения контекста". Уж больно часто начинеают спотыкаться друг об друга.
А еще завёл проект "для души" - только руками, только хардкор! ::)
А вам такое удается на тарифе Pro или это только Max "потянет"? Я ради интереса попробовал через API, так мне Sonnet на довольно простом проекте скушал 5 баксов, а подход у меня был в разы проще.
@yermolaevтоже интересно про затраты
Pro не хватало, перешел на Max
Согласен, плюс-минус делаю также, плюс стараюсь идти через tdd, но тут уже на вкус и цвет...
А ещё, в моем пайплайне, я стараюсь задачу оформлять как Эпик, а этапы - как child issues, просто чтобы можно было сразу послать агента посмотреть задачу в целом и понять, на каком этапе находимся сейчас...
Ну а дальше - у каждого issue свой чат/документация/план/архитектура/шаги. Если issue получается объемный и тоже разбит по шагам, то на каждый шаг пишется отчёт (если в процессе пошли отклонения от первоначального плана - это будет учтено в дальнейшем), со ссылкой на коммиты которыми он закрыт
Вобщем, схема примерно рабочая, главное не отвлекаться, никогда не верить агенту и всегда за ним приглядывать хотя бы вполглаза, чтобы отлавливать те моменты, в которые он хочет завернуть не туда.
Правда, я называю такое "агентское программирование", а не "вайбкодинг"
Я просто руками сделал 1 домен на бекенде, объявил его эталоном.
Далее попросил сгенерировать pre_flight.md, в котором прописана и архитектура и правила работы.
Весь обмен данными на бекенде только через DTO, обязательные тесты на каждый домен.
Обмен между фронтами и бекендом через SDK + TS + ZOD - и все это генерируется из OpenAPI одной командой.
Результат - я скармливаю инструкцию агенту, и задаю любую задачу. Галлюцинации начинаются минимум через час самостоятельной работы.
Я соло-разработчик, тоже использую похожий подход. Пришел к нему сам, опытным путем. Единственное, что могу добавить - для разработки архитектуры и деления на этапы использую более "сильную" модель - Opus 4.6, а для выполнения этапов - более быструю и простую Gemini Flash. Получается очень эффективно в плане расхода токенов.
Еще в корне проекта всегда держу спеку и readme, чтобы модель лучше понимала контекст.
Я вот думаю, для Claude pro действительно необходим чистый Гугл аккаунт с платным ВПН на одну страну и карту с симкой той страны? Или не обязательно так заморачиваться? Для кодинга ещё обхожусь и так, но хочу наладить синтетическое обучение своей локальной модели с помощью api Claude со специализацией на своем круге задач, поэтому без pro наверное не уедешь далеко, с другой стороны пишут что велик риск блокировки если ip подозрительный выпадет и тп
дублирование логики - ну и что?
разъезд стиля и подходов - а в чём проблема?
"заглушки” вместо полноценной реализации - непонятно у вас программа работает или нет?
дорогая отладка: больше времени уходит не на разработку, а на распутывание несогласованностей - а кто вас заставляет их распутывать какая бизнес необходимость?
У такого подхода уже есть и название (Spec-Driven Development) и готовые реализации, напр. от GitHub: https://github.com/github/spec-kit.
Спасибо что поделились, пожалуй, дополню статью с линком на SDD.
Нашел исчерпывающую статью https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
Не знаю упоминался ли здесь BMAD, но решение его напомнило. Только самописное и с граблями
Собственно, использовать чаты ии для кодинга это в прошлом.
Скачайте zed.dev или cline.bot или opencode.ai или расширение для любимого редактора.
Почитайте мануал, где ии агент хранят роли
например в корне проекта в папке .rules или .clinerules и тд.
Напишите в первом файле самое главное и ссылки на другие роли
и в каких случаях их использовать.
Таким образом получите куда более эффективные результаты.
Можно посмотреть как это выглядит в моём проекте на гитхаб.
поглядел ваш гитхаб, папку .clinerules - там правила вперемешку на русском и английском - модель не путает язык общения во время работы? если у вас есть опыт с локальными моделями 7b-13b - поделитесь пожалуйста (ну или другие локальные модели которые что-то могут) - даже неудачный опыт интересен
не, не путает, ей по сути вообще без разницы, так как она не знает что такое языки)
Последние тесты в бенчмарках как то даже показали результаты лучше при использовании не английского языка, а других в том числе русский был выше английского.
Из локальных попробуйте интересные варианты для карт с 12GB VRAM
https://huggingface.co/TeichAI/Qwen3-14B-Claude-4.5-Opus-High-Reasoning-Distill-GGUF
https://huggingface.co/ByteDance-Seed/Seed-Coder-8B-Reasoning
Ну и другие удобно использовать и скачивать с помощью https://lmstudio.ai
Так же использовать как провайдер чтобы дать доступ в редакторе кода.
Мануал: https://freeloadsoft.ru/2025/07/22/kak-podklyuchit-lokalnogo-koding-assistenta-v-visual-studio-code/
спасибо за развернутый ответ, буду пробовать эти модели. (оличный мануал, подробный - я помучался в свое время пока настроил) на моей видеокарте 4 Г всего, "спасает" 32 Г оперативки. если бы вы брали видеокарту сегодня, то была бы новая rtx 5060ti 16g, trx 3090 24g или rx7900xtx 24g?
Напишите в первом файле самое главное и ссылки на другие роли в каких случаях их использовать.
не нашел этого у вас в репозитории - расскажите подробнее про то как вы используете роли (если я правильно понял это архитектр, разработчик и ревьювер?). вы используете разные модели для разных ролей? я слышал что reasoning модели лучше подходят для архитекторов и ревьюверов, но не для написания кода - можете привести общие рекомендации по выбору моделей?
Попробуйте SpecKit.
Благодарю всех тех, кто оставил фидбэк к этой статье! Открыл для себя некоторые существующие методики, что очень полезно :)
Я в своих проектах стараюсь придерживаться изначально такого же подхода, планирование, поэтапная реализация и т. д., но в итоге неизбежно скатываюсь в то, что мелочи не запланировали и их приходится доделывать или переделывать в процессе. И я не пойму, как их правильно оформлять? Типа работаю над фичей, понимаю, что здесь надо бы по-другому. После этого идем в планирование и все меняем поэтапно?
Всем привет! Автору огромное спасибо за статью.
Я только столкнулся с таким понятием как вайб-коддинг, совершенно не обладаю знаниями программирования. Решил сделать инструмент, который избавит от заполнения файла в Excel и вынес это все в веб-интерфейс. У меня получился один файл (около 10к строк) и на первый взгляд (без массового теста), все работает как нужно.
Какие можете дать советы на воплощения будущих проектов? Например, чат с архитектурой мне непонятно, что давать на вход, ведь я и не знаю, на каком языке задать написание того или иного. Реализовываю большим количеством итераций, подробного ФТТ не формирую, да и все возможные варианты достаточно сразу сложно прописать.
Спасибо, что потратите время на объяснение, буду рад услышать каждого.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я перестал «вайбкодить» с LLM и собрал процесс разработки, который не разваливает проект