Добрый день. Давайте немного добавим ясности. Возможно, материал написан не достаточно подробно.
Код как раз модель пишет максимально простой.
Модель может писать максимально простой код, но только как результат очень жёстких ограничений с вашей стороны и при определении этих ограничений через большое количество первичных итераций по которым вы будете выводить правила по которым модель должна работать. Используя правила иных разработчиков вы используете подход "общий" который не включает отдельных особенностей вашей архитектуры. В противном или "общем" случае вы столкнётесь с кодом, где модель «оптимизировала» что-то в 4 уровня вложенных абстракций. Для анализа, попробуйте сгенерировать нетривиальный алгоритм без явного требования «держи код линейным, избегай глубокой вложенности» — и вы увидите ту самую простоту, которая быстро превращается в лабиринт и даже сеть паука с множеством связей.
Другой вопрос, что она не сохранит тёплый ламповый мирок, а будет использовать названия и подходы как ей вздумается.
Вы сами признаёте проблему непредсказуемости имён и подходов. Статья как раз об этом: из-за вероятностной природы модель не обязана придерживаться ваших конвенций (она по сути их не знает), если вы их не зафиксировали явно и повторяемо (например, в каждом запросе).
Ну, и код, когда пользуешь LLM вместо себя, естественно, ещё и незнаком.
Как раз в этом случае и ведётся призыв бороться с этим «естественным» положением дел. Это и будет отличать вайбкодинг от инженерного подхода к модели как к инструменту. Необходимо снижать незнакомость через линейность, простоту и атомарность запросов. Хороший инженер не мирится с тем, что инструмент выдаёт непонятный код, а либо настраивает инструмент (затачивает), либо меняет подход.
Касательно фреймворка неправда. Если есть описание его API, он прописан в агентах и скилах, то вполне себе пользует.
Даже если вы дадите описание API, модель, генерируя код, будет «соскальзывать» в привычные библиотеки и конструкции. Это экспериментально проверяемый факт. Посмотрите исследования о статистическом предпочтении моделей.
Ваше «прописан в агентах и скилах» — это вы передаёте описание в контекст. Но эффект «потерянного в середине»: в длинном описании API правила начинают игнорироваться. Кроме того, модель не просто смотрит на текущий промпт — её веса зафиксированы. Если вы скажете «используй мой фреймворк X», а в обучающей выборке X встречается 0.001% раз, а типовой паттерн — 80%, то результат будет предсказуем. Модель либо проигнорирует ваш фреймворк, либо сгенерирует его неправильно. Именно по совокупности указанных причин я рекомендую, но не настаиваю применять типовые решения, а именно те на которых модель обучена. Это инженерный прагматизм: не тратить силы на борьбу со статистической природой модели, а плыть по течению типовых паттернов. Скорее всего при работе, вы просто не замечаете, как часто модель «забывает» о вашем API и подставляет (сейчас говорим условно) std::vector вместо вашего MyVector, или request.get вместо вашего custom_fetch Я вижу, что у вас неплохо с английским, поэтому на данный счёт могу посоветовать вам ознакомиться с парой статей, одна за 2025 год (https://arxiv.org/pdf/2605.12382) и другая за 2026 (https://arxiv.org/pdf/2503.17181). Статья 2025 года хорошо показывают проблему "соскальзывания" моделей, а статья от 8 апреля 2026 года показывают ещё один очень интересный момент, в частности для модели Qwen-2.5-Coder подсказки, по направлению работы через промпт, создавали дополнительную неопределённость ответа. Это влечёт к обратному эффекту от того, что вы ожидаете при работе с моделью задавая ей какие-то рамки и жёстко её регулируя.
Добрый день. Для внутренних тестов мы использовали текстовые модели способные уместиться на одной RTX5090 или двух RTX A6000 (с последним вариантом размещенеия нейронок на железе свои нюансы). Модели были разные, с разной квантизацией, заточенные на код, так и общего назначения. В рамках тестов использовали: Qwen2.5-Coder-32B, Qwen3-30B-A3B-Instruct-2507-GGUF, gpt-oss-120b-GGUF, Phi-4-multimodal-instruct. Список не полный, но это те модели, которые показали удовлетворительные результаты в ходе работы с кодом. И обращаю внимание модели за выпуском Unsloth, так как именно их контейнеры на момент тестирования нами, запускались и работали наиболее стабильно. Последняя модель от Microsoft использовалась для общих тестов и (скажем так - "Пощупать, что это такое") оценки работоспособности в мультимодальном режиме.
Добрый день. Давайте немного добавим ясности. Возможно, материал написан не достаточно подробно.
Модель может писать максимально простой код, но только как результат очень жёстких ограничений с вашей стороны и при определении этих ограничений через большое количество первичных итераций по которым вы будете выводить правила по которым модель должна работать. Используя правила иных разработчиков вы используете подход "общий" который не включает отдельных особенностей вашей архитектуры.
В противном или "общем" случае вы столкнётесь с кодом, где модель «оптимизировала» что-то в 4 уровня вложенных абстракций. Для анализа, попробуйте сгенерировать нетривиальный алгоритм без явного требования «держи код линейным, избегай глубокой вложенности» — и вы увидите ту самую простоту, которая быстро превращается в лабиринт и даже сеть паука с множеством связей.
Вы сами признаёте проблему непредсказуемости имён и подходов. Статья как раз об этом: из-за вероятностной природы модель не обязана придерживаться ваших конвенций (она по сути их не знает), если вы их не зафиксировали явно и повторяемо (например, в каждом запросе).
Как раз в этом случае и ведётся призыв бороться с этим «естественным» положением дел. Это и будет отличать вайбкодинг от инженерного подхода к модели как к инструменту. Необходимо снижать незнакомость через линейность, простоту и атомарность запросов. Хороший инженер не мирится с тем, что инструмент выдаёт непонятный код, а либо настраивает инструмент (затачивает), либо меняет подход.
Даже если вы дадите описание API, модель, генерируя код, будет «соскальзывать» в привычные библиотеки и конструкции. Это экспериментально проверяемый факт. Посмотрите исследования о статистическом предпочтении моделей.
Ваше «прописан в агентах и скилах» — это вы передаёте описание в контекст. Но эффект «потерянного в середине»: в длинном описании API правила начинают игнорироваться. Кроме того, модель не просто смотрит на текущий промпт — её веса зафиксированы. Если вы скажете «используй мой фреймворк X», а в обучающей выборке X встречается 0.001% раз, а типовой паттерн — 80%, то результат будет предсказуем. Модель либо проигнорирует ваш фреймворк, либо сгенерирует его неправильно.
Именно по совокупности указанных причин я рекомендую, но не настаиваю применять типовые решения, а именно те на которых модель обучена. Это инженерный прагматизм: не тратить силы на борьбу со статистической природой модели, а плыть по течению типовых паттернов.
Скорее всего при работе, вы просто не замечаете, как часто модель «забывает» о вашем API и подставляет (сейчас говорим условно) std::vector вместо вашего MyVector, или request.get вместо вашего custom_fetch
Я вижу, что у вас неплохо с английским, поэтому на данный счёт могу посоветовать вам ознакомиться с парой статей, одна за 2025 год (https://arxiv.org/pdf/2605.12382) и другая за 2026 (https://arxiv.org/pdf/2503.17181). Статья 2025 года хорошо показывают проблему "соскальзывания" моделей, а статья от 8 апреля 2026 года показывают ещё один очень интересный момент, в частности для модели Qwen-2.5-Coder подсказки, по направлению работы через промпт, создавали дополнительную неопределённость ответа. Это влечёт к обратному эффекту от того, что вы ожидаете при работе с моделью задавая ей какие-то рамки и жёстко её регулируя.
Добрый день.
Для внутренних тестов мы использовали текстовые модели способные уместиться на одной RTX5090 или двух RTX A6000 (с последним вариантом размещенеия нейронок на железе свои нюансы). Модели были разные, с разной квантизацией, заточенные на код, так и общего назначения. В рамках тестов использовали: Qwen2.5-Coder-32B, Qwen3-30B-A3B-Instruct-2507-GGUF, gpt-oss-120b-GGUF, Phi-4-multimodal-instruct. Список не полный, но это те модели, которые показали удовлетворительные результаты в ходе работы с кодом. И обращаю внимание модели за выпуском Unsloth, так как именно их контейнеры на момент тестирования нами, запускались и работали наиболее стабильно.
Последняя модель от Microsoft использовалась для общих тестов и (скажем так - "Пощупать, что это такое") оценки работоспособности в мультимодальном режиме.