Нейросеть — не второй программист. Как правильно разделить работу. Помощь для начинающих

[Granulex]

"Lost in the middle" работает и в обратную сторону: когда модель сама пишет длинный блок, она теряет нить своих же решений ровно с той же скоростью.

[ENick]

"опыт использования моделей, локально запускаемых на ПК" ценность статьи многократно возрастёт, если укажите модели и ПК

[Rentgenman]

Добрый день.
Для внутренних тестов мы использовали текстовые модели способные уместиться на одной RTX5090 или двух RTX A6000 (с последним вариантом размещенеия нейронок на железе свои нюансы). Модели были разные, с разной квантизацией, заточенные на код, так и общего назначения. В рамках тестов использовали: Qwen2.5-Coder-32B, Qwen3-30B-A3B-Instruct-2507-GGUF, gpt-oss-120b-GGUF, Phi-4-multimodal-instruct. Список не полный, но это те модели, которые показали удовлетворительные результаты в ходе работы с кодом. И обращаю внимание модели за выпуском Unsloth, так как именно их контейнеры на момент тестирования нами, запускались и работали наиболее стабильно.
Последняя модель от Microsoft использовалась для общих тестов и (скажем так - "Пощупать, что это такое") оценки работоспособности в мультимодальном режиме.

[Gromilo]

Хорошо что о нейронках стали говорить те, кто их использует, а не только продаёт.

Менеджемент очарован нейронками, наслушались продавцов токеном и всё кажется, что она само.

[Dmitriy_Volkov]

Статья скорее про вайбкодинг. Аджентик потеряется позже, но в целом посыл сохраняется.

Код как раз модель пишет максимально простой. Другой вопрос, что она не сохранит тёплый ламповый мирок, а будет использовать названия и подходы как ей вздумается. Ну, и код, когда пользуешь LLM вместо себя, естественно, ещё и незнаком. Ещё другая проблема, что она изучит минимально достаточный код и пофиксит костылём, возможно те самые упомянутые в статье горизонтальные связи. Тоже можно бороться, явно описывая ей назначение модулей, архитектуру и т.п. И ревьювить само собой. Касательно фреймворка неправда. Если есть описание его API, он прописан в агентах и скилах, то вполне себе пользует.

[Rentgenman]

Добрый день. Давайте немного добавим ясности. Возможно, материал написан не достаточно подробно.

Код как раз модель пишет максимально простой. 

Модель может писать максимально простой код, но только как результат очень жёстких ограничений с вашей стороны и при определении этих ограничений через большое количество первичных итераций по которым вы будете выводить правила по которым модель должна работать. Используя правила иных разработчиков вы используете подход "общий" который не включает отдельных особенностей вашей архитектуры.
В противном или "общем" случае вы столкнётесь с кодом, где модель «оптимизировала» что-то в 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 подсказки, по направлению работы через промпт, создавали дополнительную неопределённость ответа. Это влечёт к обратному эффекту от того, что вы ожидаете при работе с моделью задавая ей какие-то рамки и жёстко её регулируя.