Bloated C++ Code

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.

website uses cookies https://pvs-studio.com/en/privacy-policy/ to enhance your browsing experience. There'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. One 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 VibeTensor: System Software for Deep Learning, Fully Generated by AI Agents I 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. Turns 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. Don'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. That 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. In 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. Scroll 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 : Like I mentioned in my article C++: Write, shorten, optimize , this exact block of code shows up nine times across different tests: js 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; } But 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: 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 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 can't be zero at that point. The code simplifies down to: 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 ; In other spots, you can't call the bloat minor anymore. Right there, PVS-Studio fires off whole groups of warnings at once: The 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. 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; At the very least, that manual loop for building the output string can be swapped out right away for: return std::format "tensor {} ", parts | std::views::join with ", "sv ; If you take a closer look, you can actually cut all this bloated mess down to a third of its size: 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; Here'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. But 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. Bottom 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. Sure, 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. And 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. A few things bloated code actually costs: By "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 actually 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. js 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" ; } .... } And 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. So what do you actually do? I don't have a ready-made fix. But at least knowing about it puts you ahead. I'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. This 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. Additional links: