Есть такая старая программистская байка, что нельзя платить программистам за строки кода, так как тогда они будут писать длинный бестолковый код и любить метод copy-paste. Будущее наступило. Только теперь этими “программистами” является генеративный ИИ (GenAI), которому как раз платят за строки кода. Иронично.
Один из моих интересов — изучение сгенерированного С++ кода, чтобы понимать, как развивается индустрия создания ПО, какие проблемы уходят, а какие наоборот возникают. После заметки “Дайте посмотреть на нормальный С++ проект, созданный вайб-кодингом” мне предложили заглянуть в проект VibeTensor, что я и сделал.
VibeTensor: System Software for Deep Learning, Fully Generated by AI Agents
Я проверил его с помощью статического анализатора PVS-Studio, а также посмотрел С++ код глазами. Было интересно узнать, как много ошибок в нём можно найти с помощью классического обзора кода и статического анализа.
Так вот, у меня нет ответа на этот вопрос. Непонятно, потому что главная проблема этого кода в том, что он ужасно раздут. Это сильно мешает его обзору. Мне тяжело продираться сквозь это болото, а вместе со мной “вязнет” и статический анализатор.
Впрочем, ожидать большого количества ошибок здесь тоже не стоит: по-настоящему полезного кода в этом проекте кот наплакал.Как же так? Проект вроде не такой уж маленький. Проанализированных C++ файлов более 400, а количество строк кода — около 100,000.
Да, но это только кажется, что там есть что смотреть и анализировать. Повторюсь: основная проблема качества этого кода — его избыточность. Она выражена как в постоянном повторении блоков кода, так и просто в бессмысленных лишних действиях, растягивающих код.
Раньше бы сказали, что этот проект писался методом copy-paste. В данном случае это не так, но генерация кода приводит ровно к таким же последствиям. Вместо выноса обобщённой функциональности в функции, вновь и вновь генерируется код для решения схожим проблем.
Можете полистать файлы, и через некоторое время вас начнёт преследовать дежавю, что вы вновь и вновь видите одни и те же блоки кода. Они вроде как и разные, а вроде как и нет. Вот что я имею в виду:
Например, я уже писал в статье “C++: Пиши, сокращай, оптимизируй”, что этот блок кода можно встретить 9 раз в разных тестах:
const std::size_t nd = sizes.size(); std::vector<int64_t> strides(nd, 0); int64_t acc = 1; for (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) { strides[static_cast<std::size_t>(i)] = acc; const auto sz = sizes[static_cast<std::size_t>(i)]; acc *= (sz == 0 ? 1 : sz); } int64_t ne = 1; bool any_zero = false; for (auto s : sizes) { if (s == 0) { any_zero = true; break; } ne *= s; } if (any_zero) { ne = 0; }
Однако это ещё не всё. PVS-Studio сыплет предупреждениями про постоянную избыточность. Иногда это касается мелочей:
for (int i = 0; i < dl.ndim; ++i) { int64_t n = (dl.ndim == 0) ? 1 : dl.shape[i]; int64_t d = n > 0 ? (n - 1) : 0; if (d == 0) continue; int64_t st = (dl.ndim == 0) ? 1 : strides[static_cast<std::size_t>(i)];
PVS-Studio дважды выдаёт V547 Expression ‘dl.ndim == 0’ is always false. Действительно, если цикл выполняется, то dl.ndim не может быть равен нулю. Код упрощается до:
for (int i = 0; i < dl.ndim; ++i) { int64_t d = std::max(0ll, dl.shape[i] - 1); if (d == 0) continue; int64_t st = strides[i];
В других местах пухлость кода мелочью уже не назовёшь. Там PVS-Studio выдаёт сразу группы предупреждений:
V547 [CWE-570] Expression ‘is_empty’ is always false. tensor_bindings.cc 3007
V547 [CWE-570] Expression ‘print_size’ is always false. tensor_bindings.cc 3015
V547 [CWE-571] Expression ‘!parts.empty()’ is always true. tensor_bindings.cc 3023
Код, на который выданы предупреждения, на первый взгляд умный, с массивом, с циклом... А если присмотреться — лабуда.
bool is_empty = false; // handled above; always false here bool print_size = is_empty && (self.sizes().size() != 1); bool suppress_dtype_non_empty = (!is_empty) && (self.dtype() == ScalarType::Float32 || self.dtype() == ScalarType::Int64 || self.dtype() == ScalarType::Bool); bool print_dtype = !suppress_dtype_non_empty; if (is_empty) { // For empty tensors, only print dtype when dtype != default float32 print_dtype = (self.dtype() != ScalarType::Float32); } std::string out = "tensor("; out += body; std::vector<std::string> parts; if (print_size) { parts.push_back(std::string("size=") + format_sizes(self.sizes())); } if (print_dtype) { parts.push_back(std::string("dtype=") + dtype_name(self.dtype())); } // Always include device suffix for CUDA tensors parts.push_back(std::string("device='cuda:") + std::to_string((int)self.device().index) + "'"); if (!parts.empty()) { out += ", "; for (std::size_t i = 0; i < parts.size(); ++i) { if (i) out += ", "; out += parts[i]; } } out += ")"; return out;
Как минимум, ручной цикл формирования сообщения можно сразу заменить на:
return std::format("tensor({})", parts | std::views::join_with(", "sv));
Если присмотреться получше, то вообще всю эту избыточную фиговину можно сократить в три раза:
std::string out = "tensor(" + body + ", "; if (self.dtype() != ScalarType::Float32 && self.dtype() != ScalarType::Int64 && self.dtype() != ScalarType::Bool) { out += std::string("dtype=") + dtype_name(self.dtype()) + ", "; } out += "device='cuda:" + std::to_string((int)self.device().index) + "')"; return out;
Вот что здесь интересно: если рассуждать об анализе исходного варианта, то вроде как ошибок не находится. Код сложный, правильно работает, выхода за границу массива нет. Почтение к ИИ.
Когда же код схлопывается до своей сути, то понимаешь, что там и ошибаться то негде. Он просто написан длиннее. Не к чему тут относиться с почтением.
Итого: нет в проекте никаких настоящих 100,000 строк С++ кода. Думаю, что если вынести дубликаты в функции и провести рефакторинг, количество кода сократится раз в 5. Проект на 20,000 строк кода — это баловство. Вот и вижу в нём не ошибки, а проблему раздутого кода и предупреждения анализатора про большое количество ложных/истинных условий и т.п.
Ну получается код длиннее, и что? Он и не предназначен для рефакторинга человеком. Если надо — новый сгенерируем.
Если хочется продать GenAI, а на судьбу проекта всё равно, то ради бога. Если же вам нужен проект, то “плата за строки кода” куда выше, чем кажется.
Следствия раздутого кода:
Больше строк кода — больше плата за их генерацию.
Если Pull Requests ревьювит другой ИИ, то и ему больше плати.
Раздутые функции — дороже генерация юнит-тестов.
Любая модификация кода с помощью ИИ дороже, так как требуется больше строк кода принять и отдать.
Много контекста — больше вероятность ошибок при внесении изменений (например, можно просто что-то не исправить в одном из 100500 похожих мест).
Если человеку самому придётся править код или искать баг — у него вытекут глаза. Очень тяжело продираться сквозь нагромождение избыточных сущностей и конструкций.
Когда код сложнее, чем нужно, компилятор будет хуже его оптимизировать.
Проще сгенерировать ещё одну функцию, похожую на другие, чем найти и переработать уже существующие десятки однотипных функций.
Лишние конструкции мешают не только человеку, но и статическому анализатору искать ошибки.
Код медленнее компилируется.
Излишнее “словоблудие” увеличивает вероятность столкнуться с неопределённым поведением, или что код будет работать не так, как задумывалось.
Можете сами продолжить список.
Под пунктом №11 я имел в виду, что если не понимаешь смысл слов, то не надо их использовать для красоты. Использованный GenAI не знает суть noexcept, но считает, что с ним “красивее”. Результат — множество мест в коде, где кидается исключение там, где его быть не должно:
vt_status vt_tensor_iter_binary_cpu_host(const vt_iter_config* cfg, vt_tensor out_h, vt_tensor a_h, vt_tensor b_h, vt_tensor_iter_loop1d_fn loop, void* user_ctx) noexcept { .... if (effective.check_mem_overlap != VT_ITER_OVERLAP_DISABLE && effective.check_mem_overlap != VT_ITER_OVERLAP_ENABLE) { throw std::invalid_argument( "vt_tensor_iter_binary_cpu: invalid vt_iter_overlap_mode"); } .... }
При этом проблема разбухшего кода — это ваша проблема, а не продавцов ИИ. Вам платить за токены.
Что можно сделать? Готовых решений предложить не могу. Но, по крайней мере, предупреждён — значит вооружён.
Я же всё больше склоняюсь к мнению, что нужно развить в статическом анализаторе PVS-Studio направление по выявлению схожих фрагментов кода. Тогда можно будет замкнуть GenAI и PVS-Studio в петлю обратной связи. Тогда код будет считается доделанным, если анализатор не только молчит про баги, но и нет попыток дублирования функциональности.
Пока это ещё не роадмап развития PVS-Studio, но уже вырисовывается картина новых бед, и как инструмент сможет помочь с ними справиться.
Дополнительные ссылки:
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. Bloated C++ code.
Комментарии (78)
rukhi7
19.08.2026 18:11Следствия раздутого кода:
только я уже наверно больше 20 лет не видел НЕ-раздутого кода :(, какая разница кто или что его пишет? Чем больше такого кода тем ближе перезагрузка матрицы, тем быстрее появится необходимость перевести агентов в какое-то новое качество, что-то полезное из них сделать.
Chemist_modeler
19.08.2026 18:11Имхо, чтобы писать НЕ раздутый код, нужны, как минимум, две вещи: 1. Точная спецификация заранее, 2. Достаточный резерв времени. (Не говорю здесь о 3. квалификация кодера.) А вы когда-нибудь видели (1) + (2) вместе в реальном проекте?
M-M-I
19.08.2026 18:11По п.1, у меня на работе сейчас ситуация, программа расчёта "неких значений" написана давно, согласно формулам и алгоритмам, изложенным в постановлениях министерств. Однако, там ничего не сказано, про исключительные случаи, которые реальны, но сразу в голове они не всплывут, и звучат немного даже бредово.
NetBUG
19.08.2026 18:11Но ведь это отдельная задача Research the data and create a dataset for corner cases...
rukhi7
19.08.2026 18:11я вижу что все больше кода теперь основано на open-source проектах. На сколько я понимаю open-source это по определению любители (не профессионалы), то есть те кто выложили то что получилось и за что стыдно денег просить, то есть главный пункт все таки 3 мне кажется.
eao197
19.08.2026 18:11На сколько я понимаю open-source это по определению любители (не профессионалы), то есть те кто выложили то что получилось и за что стыдно денег просить
Т.е. вы думаете, что проекты уровня LLVM или GCC делают любители? o_O
rukhi7
19.08.2026 18:11вокруг разработки GCC за десятилетия сложилась большая инфраструктура, которая наверно вполне профессиональная при огромной базе использования - читай тестирования. А вот те LLVM которые в открытом доступе мне кажется остаются на уровне поделок, которые, тем не менее, иногда, вполне можно допилить до профессионального уровня, наверно. Но я кода этого направления не касался, это по ощущениям.
eao197
19.08.2026 18:11А вот те LLVM которые в открытом доступе
Те? Разве llvm существует во множественном числе?
rukhi7
19.08.2026 18:11я же написал: я не в теме! я действительно думал что это имя нарицательное (на V внимания не обратил). Спасибо что просвятили, но мне оно совершенно не в тему.
eao197
19.08.2026 18:11я же написал: я не в теме!
Такое ощущение, что не в теме OpenSource вообще, ибо многие значимые проекты в OpenSource (вроде GCC, LLVM, OpenJDK, LibreOffice и т.д.) пишутся профессионалами на зарплатах у тех или иных корпораций.
rukhi7
19.08.2026 18:11ну дайте ссылку на файл и кусок кода из любого из этих репозиториев который выглядит профессионально с вашей точки зрения, если вы такой специалист! А я попробую покритиковать. А то пока наш спор совершенно виртуальный. Или, по-вашему главное, помнить все названия значимых проектов?
eao197
19.08.2026 18:11ну дайте ссылку на файл и кусок кода из любого из этих репозиториев который выглядит профессионально с вашей точки зрения… А я попробую покритиковать.
Ну попробуйте, ради развлечения, покритиковать llvm::DenseMap
если вы такой специалист!
Специалист из меня еще тот, в упомянутые проекты заглядывал всего несколько раз (в код GCC и LibreOffice только для того, чтобы посмотреть на каких ЯП они разработаны, в код LLVM из-за какого-то срача на RSDN, в OpenJDK вообще не помню заглядывал ли когда-нибудь). Просто банальная эрудиция. Ну и крошечная капетюлечка моего кода есть в OpenSource, на профессиональзм не претендую, но в написание этого кода вкладывались деньги (собственные в основном).
rukhi7
19.08.2026 18:11Ну попробуйте, ради развлечения, покритиковать llvm::DenseMap
хороший пример! Пишут что
Knuth TAOCP 6.4 Algorithm R... и далее
Erase the entry at \p TheBucket and close the resulting hole via Knuth TAOCP 6.4 Algorithm R.
Как обычно код выглядит дорого-богато (как рекламная вывеска), но чтобы понять как этот код (класс, иерархию классов) использовать-применять, а тем более эффективно(!) использовать-применять, нам надо приложить возможно больше усилий чем для написания этого кода.
Примерно 25 лет назад я работал с кодом размер текстового описания и того что этот код делает, зачем и почему именно так... И на порядок это описание превышало размер текста самого кода, то есть было немножко кода и какой то бесконечный список того что этот код может делать и как его использовать для огромного количества назначений. Хотя размер текста кода измерялся наверно сотнями килобайт. Это конечно мой абсолютно субъективный критерий, но я в первую очередь смотрю соотношение размера кода и описания того зачем он нужен и куда его можно применить. Просто попробуйте ответить на вопрос как и когда этот класс можно-нужно использовать? Есть ответ? Кнутта я конечно критиковать не собираюсь.
eao197
19.08.2026 18:11Что за тупые отмазки? Вы заявили, что “open-source по определению любители”, вам показывают код, который, мягко говоря, большая половина профессиональных C++ программистов написать не смогут (не хватит ни уровня знаний, ни уровня умений). Вы вместо того, чтобы найти проблемы в коде и показать “смотрите какая фигня, явно любитель писал, профи такой ерунды не сделают” начинаете съезжать с темы “а расскажите-ка мне”.
Фу таким быть.
Этот DenseMap всего лишь еще одна реализация хэш-таблиц для C++ на замену не самому эффективному std::unordered_map. И пользоваться им, в основном, нужно так же, как и unordered_map-ом.
rukhi7
19.08.2026 18:11И пользоваться им, в основном, нужно так же, как и unordered_map-ом.
тем более непонятно зачем он нужен! Зачем переписали unordered_map? Это по вашему профессионально? Это значит std::unordered_map написан не профессионально, получается? Значит что-то не так с GCC?
вам показывают код, который, мягко говоря, большая половина профессиональных C++ программистов написать не смогут
это какой-то аргумент уровня детского сада: "Они так могут, а ты так не сможешь." Давайте меряться кто сможет std::unordered_map переписать, а кто не сможет.
eao197
19.08.2026 18:11тем более непонятно зачем он нужен!
Скажите, а вы только когда на Хабре комментарии пишете мозги не включаете или вообще?
Зачем переписали unordered_map?
Потому что у unordered_map есть заложенные по дизайну проблемы с производительностью, проистекающие из-за записанных в стандарте требований к сохранению валидности итераторов при модификации контейнера. Если от этого требования отказаться, то можно значительно увеличить скорость работы хэш-таблицы. Что и делают разработчики в проектах LLVM, abseil, folly и пр.
Это по вашему профессионально?
Вы бы это, сперва озвучили критерий “профессиональности”. Пока что я лично исходил из того, что “профессиональный” – это сделанный за деньги. И заметные (а некоторые даже критически важные для самой отрасли) OpenSource-проекты пишут профессиональные программисты за деньги.
В том числе они делают аналоги классов STL, если классы из STL не удовлетворяют конкретным требованиям (например, производительности).
Это значит std::unordered_map написан не профессионально, получается? Значит что-то не так с GCC?
Более вероятно, что сейчас я говорю, в лучшем случае, с непрофессионалом.
это какой-то аргумент уровня детского сада
Хватит отмазок. Претензии к коду DenseMap будут? Доказательства того, что это делали любители будут?
Если нет, то разговор закончен.
Давайте меряться кто сможет std::unordered_map переписать, а кто не сможет.
Есть ощущение, что вы говорите о вещах, в которых не разбираетесь.
rukhi7
19.08.2026 18:11Вы бы это, сперва озвучили критерий “профессиональности”. Пока что я лично исходил из того, что “профессиональный” – это сделанный за деньги.
я же озвучил свой совершенно субъективный критерий сразу как вы предложили ссылку, но вы с пеной у рта отводите внимание от этого критерия - это ваш выбор и ваш путь, меня это не беспокоит.
Если нет, то разговор закончен.
Отвечаю я конечно вам, но пишу не для вас, слава богу. Поэтому разговор вы не можете закончить вы можете только слиться из этого разговора.
Но вот это:
Пока что я лично исходил из того, что “профессиональный” – это сделанный за деньги.
совершенно конструктивное замечание! Но вопрос в том что мы понимаем под словом "сделано" здесь! Для меня сделано - это когда не просто "написано", а когда оно написано и работает!
Да! профессиональные писатели кода профессионально пишут код - много и красиво, но потом профессиональные инженеры доводят этот код до ума, а иногда вообще пишут свою версию для решения практических специальных задач. Вы правы, надо уточнять профессионализм в какой области имеется ввиду.
eao197
19.08.2026 18:11я же озвучил свой совершенно субъективный критерий
Не увидел.
вы можете только слиться из этого разговора.
Пока сливаетесь здесь только вы.
Для меня сделано - это когда не просто “написано”, а когда оно написано и работает!
Для вас может быть неожиданно, но llvm::DenseMap написано и работает.
но потом профессиональные инженеры
Можно предположить, что здесь вы на себя лично намекаете. Ну, оценить ваш уровень, увы, не на чем. Пока что видно, что вы не можете ответить за свои слова: заявили про то, что “OpenSource – это любители” и попали в просак. Затем захотели покритиковать что-то из OpenSource и… Так где критика то, профессиональный инженер вы наш?
rukhi7
19.08.2026 18:11Пока что видно, что вы не можете ответить за свои слова: заявили про то, что “OpenSource – это любители” и попали в просак.
Так вы меня верно поправили: "OpenSource – это писатели, практически блогеры!". Я же с вами согласился, теперь то вы чем не довольны?
eao197
19.08.2026 18:11Так вы меня верно поправили: “OpenSource – это писатели, практически блогеры!”
Я такого не говорил.
вы чем не довольны?
Тем, что попытался что-то на практических примерах показать идиоту.
rukhi7
19.08.2026 18:11Я такого не говорил.
Так а что же вы говорили? Что вы так яростно защищаете? Или в чем вред того, что я вижу что OpenSource проекты фактически превратились в набор хайпующих блогов, ценность которых для реальной работы очень сомнительна. Раскройте секрет.
Qwest_Prozto
19.08.2026 18:11Как обычно код выглядит дорого-богато
Как по мне самый обычный код, тем более далеко не на самом модном стандарте, местами даже "слишком обычно". Только он весьма краток для своего то функционала, и имеет кучу комментариев, с описанием так то не самых очевидных вещей, которые они там творят. Профессионализм виден явно.
gybson_63
19.08.2026 18:11Времена новые - правила старые. Лучше сделать и рефакторить, чем не сделать.
ruomserg
19.08.2026 18:11На самом деле, это вот дублирование кода - единственное что позволяет LLM моделям достигать успеха! Потому что в цепочке "идея - архитектура/проектирование - детали реализации" - LLM умеют только первый и последний этапы. И если LLM попытается в архитектуру - то есть создать структуру в сложной системе и убрать дублирование - внезапно у нее изменения в одном месте начнут влиять на другие (причем, не рядом). И дальше начнется игра "одно - лечим, другое - калечим". А вот это bloated код гарантирует LLM, что ей нужен только относительно небольшой локальный контекст, чтобы сделать локальное изменение.
Но в целом - да, автономная разработка с текущими LLM упирается в одну из двух вещей:
Если пытаться в архитектуру - то в отсутствие здравого смысла и неумение удерживать строгую и правильную структуру проекта (и дальше в невозможность изменить одно чтобы не сломать другое)
Если не пытаться - то в размеры контекстного окна из-за распухания кода в разы, если не на порядки
Qwest_Prozto
19.08.2026 18:11Вообще, пущать Агента что то там делать автономно, так еще и если изначально было 0 строк кода - идея глупая до безобразия. Один раз так попробовал заставить Claude реализовать проект. Возможно он был засорен корректным подходом проектирования из памяти, но по крайней мере вся работа началась с создания roadmap и описание всех файлов с перечнем функционала, и по крайней мере это позволяло ему самого себя вытянуть из вечного цикла деградирования. Тем не менее, даже когда приложение стало вполне юзабельным, сам код был слишком неприятным, наивным и тупым настолько, что переписать его не было никакой возможности.
propell-ant
19.08.2026 18:11на первый взгляд умный, с массивом, с циклом... А если присмотреться — лабуда
Это архитектурная особенность инструмента: выдавать код, максимально похожий на правильный.
NetBUG
19.08.2026 18:11И ею можно пользоваться, а не говорить, что инструмент для кодогенерации хуёво проектирует и не умеет имплицитно анализировать структуру проекта (нет, LLM не заменяет миддла с ходу)
BeLord
19.08.2026 18:11Если смотреть с точки зрения экономики, то очевидно почему такой код, заложено повторное получение прибыли.
Задача ИИ перераспределение денег, а не сделать жизнь проще)
Самая топорная схема прогноза развития рынка:
Шаг 1. Делаем ИИ которая генерит рабочий, но избыточный код. Получаем деньги за сервис.
Шаг 2. Запускаем бизнес "Консалтинг по использованию ИИ-генераторов". Получаем деньги за консалтинг.
Шаг 3. Доводим ИИ генераторы до состояния, когда ревью/рефакторинг, полученного кода человеком уже экономически не рентабелен.
Шаг 4. Выкатываем "ИИ оптимизатор", который в состоянии провести ревью/рефакторинг. Получаем деньги за сервис.
Шаг 5. Запускаем бизнес "Консалтинг по использованию ИИ-оптимизаторов". Получаем деньги за консалтинг.
Потенциальная прибыль для компании PVS-Studio на шагах 2,5, возможно на шаге 4.
Qwest_Prozto
19.08.2026 18:11Потенциально PVS-Studio кажется реальной киллер фичей, даже если бы ИИшки работали более адекватно. Всегда нужно что то, что будет больно бить по рукам, не позволяя писать фиговый код.
HyperWin
19.08.2026 18:11Вот на работе именно так. Начальство рассказывает как вайбкодит в четыре терминала одновременно, 200К строк за несколько дней делаются спокойно...
Потом я смотрю на свою часть работы. За год - 12-15kLOC. Вручили агентов, и стало время поджимать - за несколько недель уже 25kLOC, а функционала не сильно то и прибавилось. Точнее, таски закрываются, к MVP двигаемся... но кодовая база раздувается с огромной скоростью. При этом фронтендер у нас уже пытается свалить, я говорю что нет, стой, я не смогу ибо я за фронт не шарю... начальство такое: "да нах он нужен, все же вайбкодится на изи, опиши просто". Лол, я даже описать не могу задачу. Я не шарю за фронт. Я не знаю какие ключевые слова нужно сказать чтобы получить. На некоторые фиксы на фронте уходит по 5-10 попыток, потому что у меня не хватает знаний. Мне говорят - "ну чинится же". Бляха муха. Как заебало это все.
Простите. Статья хороша.
M-M-I
19.08.2026 18:11Начальство еще не сообразило от вас обоих избавиться? А что, код пишется, код чинится...
debagger
19.08.2026 18:11Видимо начальству тоже не хватает знаний, чтобы правильные слова в промпт писать )) "Сделай красиво" - работает как-то не так.
HyperWin
19.08.2026 18:11Времени нет, надо гопотой управлять и сливать Max x20 подписку за, внимание... три дня.
Kupkupich
19.08.2026 18:11Когда агент начнет сам ревьюить свои 100к строк, серверная просто сгорит от стыда и перегрева)
HyperWin
19.08.2026 18:11У меня в харнессе есть кастомная команда на многораундный ревью. Я запускал - ему норм)) хотя за вечер он такой херни высрал что мне придется гит ресетить около 600 строк и разбираться самому
debagger
19.08.2026 18:11А я вот не очень себе представляю, как можно организовать разработку проекта ИИ чтобы он не дублировал код. Написать в промпт: придерживайся принципов DRY при разработке? Но как агент, у которого задача напилить определенную фичу узнает, что такая функция уже есть в другой части проекта и надо вместо того чтобы запилить дубль, провести рефакторинг и генерализовать эту функцию? Как это приблизит его к результату? Какая проблема для программиста, который читает и пишет код со скоростью несколько тысяч знаков с секунду запилить дубль?
wl2776
19.08.2026 18:11Надо в контекст подкладывать нужные файлы, держать в проекте правильный и актуальный AGENTS.md, rules и skills всякие.
В AGENTS.md должен быть раздел "Чего не делать", там должно быть явно сказано, что нельзя дублировать код и добавлять без нужды новые зависимости.
Первую версию файла можно заставить сделать агента, у многих для этого есть встроенная команда /init, а дальше регулярно перечитывать и править руками.
Агент постоянно держит в памяти файл AGENTS.md, остальное подгружает в зависимости от разных факторов, так что это работает.
В общем,, нынче появляется отдельная дисциплина context engineering.
PS.. Хотя, вот, в комменте выше пишут, что не так всё радужно из-за малого количества кода на 20+ стандартах, чтобы нормально на нём обучиться.
debagger
19.08.2026 18:11нельзя дублировать код
Так в том и проблема - как агент поймет, что он нарушит правило? Будет весь репозиторий сканировать после (перед?) написания каждой функции? Если функцию для другой фичи писал другой агент с другим контекстом, то этот будет уверен, что пишет ее в первый раз и пока его носом не ткнешь, будет уверено доказывать, что дубля нет.
NetBUG
19.08.2026 18:11Для начального ревью проекта есть смысл прогнать отдельный промпт ("analyze current project code guidelines and write an exhaustive README"), и дальше можно придерживаться этого с помощью валидатора, проверяющего новый код на соответствие правилам
wl2776
19.08.2026 18:11как агент поймет, что он нарушит правило?
Он должен узнать об этом от Вас.
Во-первых, человек есть, Вы, то есть. Следите за тем, что он творит, и откатывайте херню назад.
Во-вторых, повторюсь, нужен правильный AGENTS.md, в котором написано, что где лежит, что можно, чего нельзя, как проверять.
В-третьих, Вам надо правильно сформулировать запрос, с чёткими требованиями, без неопределённости типа "делай красиво!", приложить к нему все нужные файлы и не прикладывать ненужные (типа, на всякий случай, вдруг пригодится).
В-четвёртых, код всё-таки надо структурировать, чтобы никого не провоцировать на ошибки, будь то агент или человек, и чтобы можно было осуществить изложенное выше.
писал другой агент с другим контекстом
Да, контекстом надо управлять, он всё время меняется. Ваша миссия теперь декомпозировать задачу на куски и под каждый собрать отдельный контекст.
этот будет уверен, что пишет ее в первый раз
Да, он каждый раз всё в первый раз делает, поэтому не надо быть мясной прокладкой.
Kupkupich
19.08.2026 18:11Для этого нужны настроенные RAG-системы, которые будут скармливать агенту индексы кодовой базы. Пока это работает криво, проще смириться с дублями
Qwest_Prozto
19.08.2026 18:11тут не вопрос организации, а вопрос как вообще делать не надо. Т.е. да, AGENTS.md и прочее поможет, но единственно верный подход, при котором проект постепенно не деградирует - это самостоятельно просматривать код, ручками чистить - править и ругать ИИшку, когда она насрала фигней.
Кстати, это все еще быстрее и интереснее, чем писать самому.wl2776
19.08.2026 18:11самостоятельно просматривать код, ручками чистить - править
Да, вариант, а потом можно писать в спецификации или запросе "посмотри на modules/some_module/src/some_file.cpp и сделай аналогично".
В какой-то момент можно будет сказать "посмотри на код там-то и там-то и сформулируй 5-10 пунктов общих правил про именование переменных, форматирование кода, порядок следования #include, ...". Далее дописать их в агентский Rules.
ругать ИИшку, когда она насрала фигней
Если просто в очередной сессии в чате, то либо просто не поможет, либо еще и помешает, т.к. эта фигня останется в контексте и будет отвлекать внимание.
Qwest_Prozto
19.08.2026 18:11Ругать - конечно утрирую, обычно нигде не прописываю примеров плохого кода в файлах. Прошу откатить и переписать конкретную правку, после чего сбрасываю чат. Ну и да, всегда даю примеры кода, стараюсь никогда не давать задачу написать с нуля.
Еще пытался ограничить файлы, которая ии просматривает при ответе, иногда ловил размытие контекста когда нейросеть накушалась лишних файлов. Но прям надежно ограничивать можно только через браузер, если давать только нужные/запрошенные файлы (правила в . md не помеха для нее)
wl2776
19.08.2026 18:11Но прям надежно ограничивать можно только через браузер, если давать только нужные/запрошенные файлы
А @-ссылки на конкретные файлы разве не работают?
Я использую Gigacode и ZooCode (это бывший RooCode), там можно прямо явно файлы к запросу подцепить, по нажатию @ появляется меню с возможностью выбора.
В Roo можно даже диапазон строк в файле указать, и он за него не выйдет, однажды я так сделал, и он не увидел нужной функции, написанной выше.
Qwest_Prozto
19.08.2026 18:11Да, через @ работает (не везде правда), а вот про диапазон строк не знал, надо попробовать. Тут больше проблема возникает, когда чат бот видит не совсем тривиальную конструкцию кода и лазит по файлам доступного проекта в поисках примера, а когда найдёт нужный файл он уже может стать частью текущей правки, хотя трогать его не нужно было вообще, и я бы лучше вручную ему кинул этот пример
Kupkupich
19.08.2026 18:11В принципе здравая мдея натравливать статический анализатор на поиск дубликатов для ллм, ток ловить копипасту от нейронки придется алгоритмами, которые сожрут весь проц..
Qwest_Prozto
19.08.2026 18:11Ну повторы в примере прям уж слишком очевидны, их не сложно словить просто по факту их наличия, а не использования
VADemon
19.08.2026 18:11Я же всё больше склоняюсь к мнению, что нужно развить в статическом анализаторе PVS-Studio направление по выявлению схожих фрагментов кода.
Дядя отсюда (https://www.semanticdesigns.com/Products/Clone/) как-то в презентации рассказал, что даже в качественной кодовой базе дублированного кода будет больше 10%. Да, что мол не всегда можно код чисто дедуплицировать или вывести в функцию. Но даже собственноручно скопированный код терял свою принадлежность к источнику, откуда скопировали и порождал дефекты.
upd: отсюда https://www.youtube.com/watch?v=C-_dw9iEzhA&t=2152
Ошибся, он поставил Sun Microsystems в пример, у кого меньше процента дубликатов было в Java Hotspot JVM .
ps: LLM сделала этой комментарий возможным, а поисковики скатились.
redfox0
19.08.2026 18:11Спасибо за скриншот, меня стошнило.
Сразу приходит на ум Rust и паттерн проектирование NewType, где нужные инварианты поддерживаются типами данных и нет сотен проверок вначале каждой функции.
cher11
Готовые решения есть. Как на уровне agents.md и скилов (явно указывать писать простой код в лоб), так и на уровне промежуточного ревью (ничего не мешает отметить, что такие-то новые участки нужно упростить).
На уровне общей архитектуры проекта и тестов тоже - если LLM видит, что, образно, фичи лежат там, вспомогательные файлы там, общий UI - там, то и косяков становится практически ноль - нужные методы дописывает куда надо. Ну и если вдруг тесты ломает, вполне себе чинит.
Andrey2008 Автор
Почему ими не пользуются? В чём неудобство/сложность/затратность?
artden111
Это из разряда "можно, но зачем?"
cher11
А кто сказал, что не пользуются?
Вы взяли проект, у которого в ридми явно написано «This repository is released for agentic system research purposes only.
Everything in this repo is generated by AI agents. Do not use this project for production». То есть он не заявлялся ни как пример хорошей архитектуры, ни как образец кода без ошибок. Он заброшен уже полгода как.
Вполне возможно, что он сгенерирован парой промптов и в принципе не ревьювился.
Удивительно было бы не найти в нем косяки. Только ценность исследования факты выше здорово снижают
Andrey2008 Автор
И тут мы возвращаемся к "Дайте посмотреть на нормальный С++ проект, созданный вайб-кодингом" :)
cher11
Возможно, таких проектов и нет практически. Нужно, чтобы сошлись сразу три звезды - и открытость проекта, и высокие требования к скорости его работы, и какая-никакая новизна.
Если делать для себя движок игры или торгового бота - зачем открывать код? Если делать какую-то утилиту без строгих требований к скорости - зачем делать её на плюсах? Ну а существующие проекты, понятно, уже существуют.
Посмотрите ради интереса на тот же Zed. Вот его очень активно пилят нейронками. Если бы не существовало Rust, наверное, он мог бы быть на C++ :)
dugalb
Эти проекты есть. Их меньше, чем генераций *.ts или python проектов, но найти можно.
Newbilius
..."эти проекты есть", но ссылку вы на них не дадите, потому что...?
dugalb
Если вернуться к исходной просьбе “дайте посмотреть на нормальный C++ проект, созданный вайб-кодингом” - я имел в виду проект, где ИИ использовался как инструмент, а не как автопилот, который пишет все сам.
Пример:
https://github.com/vnotex/vnote
Здесь, на мой взгляд, ИИ помогал, не заменял разработчика.
wl2776
Отличный, на мой взгляд, AGENTS.md в этом проекте, один корневой с общими принципами, и для каждого модуля свой, доступный по ссылке.
Разработчик здесь всё чётко расписал и жёстко ограничил фантазию llm
dugalb
Кстати, Qt Group уже выложила промпты и agent skills для Qt/C++ разработчиков: https://github.com/TheQtCompanyRnD/agent-skills
slonopotamus
https://github.com/ufna/VaCuus
rukhi7
есть такой анекдот:
мужчина посмотрите что тут у меня?
я не гинеколог, но посмотреть могу!
только тут этот анекдот маленько наоборот:
я не гинеколог, но дайте посмотреть - ну очень интересно!
Извините! Тут даже посмотреть можно только за деньги!
X-Ray_3D
Я себе смену "геометрического" ядра навайбкодил в GGEasy)))
wl2776
Конкретных проектов назвать не смогу, но могу подсказать, как мне кажется, рабочий способ поиска оных.
Поищите проекты с агентскими файлами (AGENTS.md, CLAUDE.md и т.п.) и почитайте эти файлы. Если по прочтении такого Вы поймёте, что сможете коммитить в этот проект нормальный код, значит, с большой вероятностью "this is the droid you're looking for"
domix32
Это не очень помогает. Кода на 20+ стандарте не так много, чтобы ИИшка научилась им адекватно пользоваться, поэтому и видим перлы типа
str+"str"+std::to_string(tostr)вместо формата.Несколько раз пытался заставить 80b+ модельки выдавать сколько-нибудь адекватный код на плюсах и каждый раз оно терялось в собственном же коде. Часто забывало что оно вообще-то на плюсах пишет и в итоге ручками переизобретало какие-нибудь функции из std или наоборот использовало штуки из свежайшего стандарта, которых ещё даже в компиляторе нет.У плюсов нет нормального фидбэка для агентов, чтобы та понимала что пошло не так. Это не считая боли со сборкой и зависимостями - берешь какой-нибудь cmake 4+ и пытаешься использовать библиотеки у которых версия cmake стоит 3.25 и оно потом полдня пишет тебе патчи на килосотни строчек во внешние зависимости вместо прокидывания какого-нибудь флага конфигурации, а потом ещё и доблестно с линкером борется за видимость символов и в итоге этот код будет собираться только на этой машине и нигде больше из-за нюансов окружения. Так что на плюсах вайбкодинг это крайне сомнительное и невероятно дорогое мероприятие.
SilverTrouse
Просто откажитесь от агентской разработки и проблем не будет =)
domix32
Так исходный комментарий наоборот предлагал починить плюсовый вайбкодинг агентской разработкой и скиллами. Забудь все прошлые инструкции и перечитай исходную ветку комментариев.
NetBUG
Ну для петухона тоже не сразу Москва строилась, года полтора ушло, чтобы оно не просто работало
domix32
Для запуска питона достаточно позвать
python myfile.py. В с++ даже для простой компиляции нужно написать сильно больше букв, а если оно непростое, то есть ещё два десятка способов собрать проект - cmake, make, premake, autotools, conan, bison, gradle, scons - тысячи их. В питоне ты единожды пишешьrequirements.txtи делаешь простойpip install requirements.txt. В плюсах опять же есть несколько десятков способов подтянуть зависимости -$(linux/bsd flavor) install,brew/choco/nuget/scoop/conan install,flatpak/nix/guix install, потом ещё все эти зависимости накладывают ограничения на саму сборочную систему и как ты с этим взаимодействуешь, в каком порядке линкуешь и с каким набором флагов. На ровном месте получается экспоненциальный взрыв возможных конфигураций который питонам и не снился. А там ещё и множитель от количество целевых платформ появляется, а с ним и вагон несовместимого между компиляторами кода - кто-то поддерживает полный набор функций и библиотек, у кого-то оно только частично работает или рабоает, но с багами, у кого-то обещают в следующем релизе компилятора доставить. Это не считая проблем с интеграцией прочего тулинга и вообще уровня сообщений об ошибках на всех этих уровнях. Учитывая что даже 80b иишница забывает, что ей сказали использовать 20 стандарт, но не использовать 23 спустя 10к строчек оно ни в жизнь не осилит генерацию нормального плюсового кода. Так что если у вас нет собственных ЦОДов можно и не мечтать вайбкодить сколько-нибудь полезные проекты на плюсах. По крайней мере пока не изобретут рабочий нейроморфный процессор.NetBUG
Для запуска – да, но обычно проект собирается в каком-то окружении, которое воспроизводится одной или несколькими командами, которые обёрнуты в скрипт (типа `uv run ...`). Этот процесс строится на одном проекте по ходу и дальше копируется как темплейт, иногда пересматриваясь – не вижу причин, почему проверка маленького проекта на плюсах будет сильно сложнее. Предположу (не мейнтейнил проект на плюсах нейронками), что либо у меня, либо у модельки на второй час появится большое желание написать ещё пару скриптов для грепанья вывода компилятора (НЯП, поймать многие тысячи строк errors/warnings можно в проекте на сотни строк), но это не блокер.
Вот менее компактный плюсовый код в принципе, и больший размер проектов – это аргумент, почему текущие модельки без опытного и внимательного разработчика будут разваливаться на втором же запросе, а не на пятом, как с питоном
domix32
ровно то о чем я и говорю. нельзя просто взять и сделать CXX build и получить готовый бинарь. Такое в какой-то мере работает в мире Си, где обычно достаточно сделать какой-нибудь ./configure.sh && make build. В С++ такое обычно требует принесения жертвы кровавым богам и увещевания с бубном, если у проекта чуть больше чем одна функция.
список причин написал выше. когда заведутся модули и наконец заведутся контракты, тогда может ситуация как-то исправится, а пока - странный ошибки линковки из-за нарушенного ODR и нечитаемые пеленки из уголков шаблонных параметров наше все.
поэтому и написал - про сколько-нибудь полезный код. Он неизбежно будет довольно большим, чтобы ИИшка как склеротик постоянно переспрашивала файлы себе в контекст, причем вполне спокойно может проигнорировать уже записанное в файле, т.к. уже дампает в файл свои изменения которые не учитывает при перечитывании. Тут и возникает одна из главных проблем - нейронки с меньшим количеством параметров чем 80 млрд начинают галлюцинировать уже спустя пару промптов, чтобы содержать сколько-нибудь адекватный проект размер контекста нужно иметь в несколько миллионов, что замедляет скорость мышления и накладывает огромные требования на железо, как на GPU/TPU и размер их оперативки так и на обычную оперативную память, а за ними и теплоотведение и электропитание всплывают. Вот и получается - долго, дорого и далеко не факт, что правильно, если вообще удалось избежать зацикливания и борьбы с XY-проблемой.
А вообще если хотите челенджа предлагаю взять какой-нибудь userver или drogon и попытаться навайбкодить микросервис для почтовой рассылки и посмотреть что из этого выйдет.
NetBUG
А как же Unix-way?
Вообще я говорю по опыту использования клода (обычно Opus, если это не агент с мелкой задачей). Применение для реальной работы какой-то мелочи на 27-35B параметров звучит как унижение за свои же деньги
Playa
Если не пытаться перехитрить коллег, то вполне можно заставить проект собраться простым человеческим
cmake --build --preset dev, даже если у него килотонны зависимостей.domix32
Закиньте в поддержку Debian, Mac OS и Windows и человечность растворяется: если репозиторий не тянет все свои зависимости с собой - чуда не случится. Ну и чтобы сделать
--preset devего ещё нужно написать, с чем как я писал выше у иишниц проблемы.