{"slug": "bloated-c-code", "title": "Bloated C++ Code", "summary": "PVS-Studio's analysis of VibeTensor, a deep learning system software fully generated by AI agents from NVIDIA Labs, found the code bloated and repetitive, with over 400 C++ files and around 100,000 lines, yet containing few real errors. The static analyzer flagged redundant code, such as a loop condition always false, and the project's verbosity makes it unreadable and difficult to analyze.", "body_md": "[website uses cookies](https://pvs-studio.com/en/privacy-policy/)to enhance your browsing experience.\n\nThere's an old joke among programmers that you should never pay them by the line of code, because they'll end up writing long, pointless code and leaning hard on copy-paste. These days that joke writes itself, except now the \"programmer\" is GenAI, and it actually gets paid per line. Ironic.\n\nOne of my hobbies is picking apart generated C++ code, just to get a sense of how the software development industry is evolving: which problems are fading out, and which new ones are cropping up. After reading my post * Real-world C++ projects built with GenAI: do they exist?* someone suggested I check out the\n\nVibeTensor: System Software for Deep Learning, Fully Generated by AI Agents\n\nI checked it with the PVS-Studio static analyzer and also read through the C++ code with my own eyes. I was curious how many errors a classic code review versus static analysis would each turn up.\n\nTurns out I still can't answer that. The code is bloated to the point of being unreadable, and that bloat is the whole problem. Wading through it felt like slogging through a swamp, and the analyzer got just as bogged down as I did.\n\nDon't get your hopes up for a big error count either. There's barely any code in this project actually worth analyzing. And that's despite the project not being small at all, over 400 C++ files, around 100,000 lines total.\n\nThat size is deceptive though. Most of the project isn't really there to be looked at or analyzed. The core issue here is just verbosity. You see it in code snippets that repeat over and over, and in plain pointless busywork that bloats the code for no reason.\n\nIn the past, people would've called this [copy-paste](/en/blog/terms/0068/) coding. That's not quite what happened here, but code generation gets you to the same place. Instead of extracting shared logic into functions, new code just gets generated again and again to solve nearly identical problems.\n\nScroll through the files for a while and you'll start getting déjà vu, as the same blocks of code keep popping up. They're sort of different, sort of not. [Here's what I mean](https://github.com/NVlabs/vibetensor/blob/fe85461faca02ba95d7bf1f8289002ff8cf91652/src/vbt/dispatch/dispatcher.cc#L760-L853):\n\nLike I mentioned in my article * C++: Write, shorten, optimize*, this exact block of code shows up nine times across different tests:\n\n``` js\nconst std::size_t nd = sizes.size();\nstd::vector<int64_t> strides(nd, 0);\nint64_t acc = 1;\nfor (std::ptrdiff_t i = static_cast<std::ptrdiff_t>(nd) - 1; i >= 0; --i) {\n  strides[static_cast<std::size_t>(i)] = acc;\n  const auto sz = sizes[static_cast<std::size_t>(i)];\n  acc *= (sz == 0 ? 1 : sz);\n}\n\nint64_t ne = 1;\nbool any_zero = false;\nfor (auto s : sizes) {\n  if (s == 0) {\n    any_zero = true;\n    break;\n  }\n  ne *= s;\n}\nif (any_zero) {\n  ne = 0;\n}\n```\n\nBut that's just the tip of it. PVS-Studio keeps spitting out warnings about redundant code, one after another. Sometimes it's the small stuff:\n\n```\nfor (int i = 0; i < dl.ndim; ++i) {\n  int64_t n = (dl.ndim == 0) ? 1 : dl.shape[i];\n  int64_t d = n > 0 ? (n - 1) : 0;\n  if (d == 0) continue;\n  int64_t st = (dl.ndim == 0) ? 1 : strides[static_cast<std::size_t>(i)];\n```\n\nPVS-Studio issues the same warning twice: V547 Expression 'dl.ndim == 0' is always false. And it's right, if the loop runs at all, `dl.ndim`\n\ncan't be zero at that point. The code simplifies down to:\n\n```\nfor (int i = 0; i < dl.ndim; ++i) {\n  int64_t d = std::max(0ll, dl.shape[i] - 1);\n  if (d == 0) continue;\n  int64_t st = strides[i];\n```\n\nIn other spots, you can't call the bloat minor anymore. Right there, PVS-Studio fires off whole groups of warnings at once:\n\nThe code that triggered these warnings seems fairly slick on the surface: an array here, a loop there... Take a closer look, though, and it's garbage.\n\n```\nbool is_empty = false; // handled above; always false here\nbool print_size = is_empty && (self.sizes().size() != 1);\nbool suppress_dtype_non_empty = (!is_empty) &&\n  (self.dtype() == ScalarType::Float32 ||\n   self.dtype() == ScalarType::Int64 ||\n   self.dtype() == ScalarType::Bool);\nbool print_dtype = !suppress_dtype_non_empty;\nif (is_empty) {\n  // For empty tensors, only print dtype when dtype != default float32\n  print_dtype = (self.dtype() != ScalarType::Float32);\n}\n\nstd::string out = \"tensor(\";\nout += body;\nstd::vector<std::string> parts;\nif (print_size) {\n  parts.push_back(std::string(\"size=\") + format_sizes(self.sizes()));\n}\nif (print_dtype) {\n  parts.push_back(std::string(\"dtype=\") + dtype_name(self.dtype()));\n}\n// Always include device suffix for CUDA tensors\nparts.push_back(std::string(\"device='cuda:\") +\n                std::to_string((int)self.device().index) + \"'\");\nif (!parts.empty()) {\n  out += \", \";\n  for (std::size_t i = 0; i < parts.size(); ++i) {\n    if (i) out += \", \";\n    out += parts[i];\n  }\n}\nout += \")\";\nreturn out;\n```\n\nAt the very least, that manual loop for building the output string can be swapped out right away for:\n\n```\nreturn std::format(\"tensor({})\", parts | std::views::join_with(\", \"sv));\n```\n\nIf you take a closer look, you can actually cut all this bloated mess down to a third of its size:\n\n```\nstd::string out = \"tensor(\" + body + \", \";\n\nif (self.dtype() != ScalarType::Float32 &&\n    self.dtype() != ScalarType::Int64 &&\n    self.dtype() != ScalarType::Bool)\n{\n  out += std::string(\"dtype=\") + dtype_name(self.dtype()) + \", \";\n}\nout += \"device='cuda:\" + std::to_string((int)self.device().index) + \"')\";\nreturn out;\n```\n\nHere's the interesting part: look at the analyzer's output for the code as it stands, and it seems like there aren't any real errors. The code is complex, but it works correctly, no out-of-bounds array access. Credit where it's due, AI.\n\nBut once you look past the surface complexity to what the code is actually doing, you realize there's nowhere left for it to go wrong. It's all the same, just stretched out over more lines. Not much credit left after that.\n\nBottom line: there aren't really 100,000 lines of C++ code in this project. Move the duplicates into functions, refactor, and I'd guess the code shrinks by a factor of 5. A 20,000-line project isn't worth taking seriously. What you're looking at here isn't errors, just bloated code and analyzer warnings about a pile of always-true and always-false conditions.\n\nSure, the code is longer, so what? That's the thinking, anyway: it's not meant to be refactored by a person, if you need something different, you just generate a new version.\n\nAnd if your goal is selling GenAI and you don't actually care what happens to the project down the line, fine, that logic holds. But if you actually need this thing to be maintained as a real project, the actual \"cost per line of code\" runs a lot higher than it looks.\n\nA few things bloated code actually costs:\n\nBy \"verbosity\" I also mean using words you don't actually understand, because they sound nice. The GenAI behind this code clearly has no idea what `noexcept`\n\nactually means, it just throws it in because it thinks the code looks better that way. And that's exactly why exceptions end up firing in places they never should.\n\n``` js\nvt_status vt_tensor_iter_binary_cpu_host(const vt_iter_config* cfg,\n                                         vt_tensor out_h,\n                                         vt_tensor a_h,\n                                         vt_tensor b_h,\n                                         vt_tensor_iter_loop1d_fn loop,\n                                         void* user_ctx) noexcept {\n\n  ....\n  if (effective.check_mem_overlap != VT_ITER_OVERLAP_DISABLE &&\n      effective.check_mem_overlap != VT_ITER_OVERLAP_ENABLE) {\n    throw std::invalid_argument(\n        \"vt_tensor_iter_binary_cpu: invalid vt_iter_overlap_mode\");\n    }\n  ....\n}\n```\n\nAnd here's the thing: the bloated code problem falls on whoever's using the tool, not the AI vendor selling it. They're not the ones footing the token bill.\n\nSo what do you actually do? I don't have a ready-made fix. But at least knowing about it puts you ahead.\n\nI'm leaning more and more toward the idea that PVS-Studio's static analyzer needs to get better at spotting similar code fragments. Do that, and you could close the loop between GenAI and PVS-Studio. Code would only count as done once the analyzer stays quiet on bugs and finds no duplicated functionality either.\n\nThis isn't a PVS-Studio roadmap yet, but a picture is starting to take shape, one that shows the new problems out there and how the tool could help tackle them.\n\n**Additional links:**", "url": "https://wpnews.pro/news/bloated-c-code", "canonical_source": "https://pvs-studio.com/en/blog/posts/cpp/1402/", "published_at": "2026-08-28 05:48:19+00:00", "updated_at": "2026-08-28 06:18:11.572929+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools"], "entities": ["PVS-Studio", "VibeTensor", "NVIDIA Labs"], "alternates": {"html": "https://wpnews.pro/news/bloated-c-code", "markdown": "https://wpnews.pro/news/bloated-c-code.md", "text": "https://wpnews.pro/news/bloated-c-code.txt", "jsonld": "https://wpnews.pro/news/bloated-c-code.jsonld"}}