Есть такая старая программистская байка, что нельзя платить программистам за строки кода, так как тогда они будут писать длинный бестолковый код и любить метод 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.
Автор: Andrey2008
