More code ≠ better code: Claude Haiku 4.5 wrote 62% more code but scored 16% lower (WebSocket refactoring analysis)
Posted by CodeLensAI@reddit | programming | View on Reddit | 21 comments
GregBahm@reddit
This used ChatGPT to judge the code and the judge decided that the best code was ChatGPT?
I feel like even the AI itself would tell you this is a dumb methodology.
netherlandsftw@reddit
https://www.reddit.com/r/MemeRestoration/s/WCl3AENTBp
SweetMonk4749@reddit
Sure more code, question is: did it work and did it take less time and token costs? That would matter more (to vibe engineers and managers at least) than how how many lines, quality, and maintainablity of code.
grauenwolf@reddit
The first thing my new boss said regarding AI to me,
SnugglyCoderGuy@reddit
More code isnt necessarily better, less code isnt necessarily better.
The right amount of code is the right amount of code. It's tautological, but there is no way easy nor good way to know the right amount of code. Sometimes adding more makes it better, sometimes taking some away makes it better. It is a case by case judgment call
grauenwolf@reddit
In the vast majority of cases, less code is better.
Not I'm not advocating crazy stuff like ripping out parameter checks. But if you have two programs with the same black box behavior, chances are the one with less code will be easier to maintain and less likely to contain subtle bugs.
pickyaxe@reddit
right, but I argue that less code is typically better while more code is typically worse.
__forsho__@reddit
Meh - would've been better if we saw the code. It also says the output was judged by gpt-5. Who knows how accurate that is.
CodeLensAI@reddit (OP)
https://codelens.ai/app/results/c1b275ea-dfa9-494f-b9bc-bfb08f33410c
Judge is dynamic (always current leaderboard leader).
modernkennnern@reddit
I would say that, in general, it's the opposite
drakythe@reddit
We’ve known this for ages. Or we should have, anyway. LoC is a terrible stand alone metric for productivity or skill. I once spent an entire 8 hour day tracking down an issue and resolving a client’s problem and all I ended up adding was three lines of code. As a metric the only thing LoC might tell you is how complicated a codebase is.
femio@reddit
It’s absurd just how…maximalist (is that a word?) LLMs are. I can’t use them for writing code and I don’t know how anyone does, it triggers me too much.
Why are you writing a 20 line function with multiple 50-character long regex patterns to see if one string is a subset of another? Why are you adding half a dozen nonsensical fallback cases? Why why why
1668553684@reddit
For me, it seems that it always wants to add parameters. It is so scared of being opinionated that it will add a new parameter for every little thing ever. If I let it design my API, the result will be the end user having to implement their own version of my library via a billion microparameters.
some_crazy@reddit
I think it’s a decent measure for the amount of change happening in a codebase. Not good or bad, just change. That can indicate riskiness of a release or scope of features, at times. It’s not productivity or skill, but it’s not useless either.
1668553684@reddit
Not even that. I've made documentation changes that affect thousands of lines. Not a single functional change in the code was made.
drakythe@reddit
That’s not an unreasonable use for it, to the measure of change.
1668553684@reddit
I usually assume more LoC = worse code, assuming the smaller code sample passes the same tests and behaves similarly. Of course it's still not a good metric, but if it has to be a metric I think it should be a negative one.
RonaldoNazario@reddit
One of the worst bugs I’ve seen was caused by a single line that literally set a single bit wrong…
LegitBullfrog@reddit
Things as simple as < vs <= have caused a lot of difficult to find off by one errors.
StarkAndRobotic@reddit
Sadly, this is how managers in some major tech companies think reflect productivity. One managers metrics of evaluating an employees “productivity”:
The manager didn’t write code, or have much of a technical background. He couldn’t tell the difference between something intelligent or stupid - his background was in accounting, and needed some way to demonstrate to his superiors that he had accomplished something.
My team spent a lot of time designing and code reviewing, so whatever we checked in was really good. We found bugs during specing or code reviews and fixed them right there. Nobody in any team could find bugs in our code. We checked in code less often, and there was less total code, but it did what it was supposed to do. But for that the managers would be really upset, because they claimed bugs have to exist, and we are not checking in enough code.
The stupid thing was, we built what they asked us to build, to spec. There was really nothing more for us to do or get right. The problem in many companies is managers who don’t have experience and are trying to game the system than make meaningful contributions to the product or company.
Shogobg@reddit
Failing upwards.