4 ms·

Yes, if it was made for human comprehension or maintenance. If it's entirely generated / consumed / edited by an LLM, arguably the most important metric is...

Yes, if it was made for human comprehension or maintenance. If it's entirely generated / consumed / edited by an LLM, arguably the most important metric is... test coverage, and that's it ?

konart 7mo ago
Can't we have generated / llm generated code to be more human maintainable?
grey-area 7mo ago
LLMs are so so far away from being able to independently work on a large codebase, and why would they not benefit from modularity and clarity too?
- olmo23 7mo ago
  I agree the functions in a file should probably be reasonably-sized. It's also interesting to note that due to the way round-tripping tool-calls work, splitting code up into multiple files is counter-productive. You're better off with a single large file.
  - AlexCoventry 7mo ago
    > due to the way round-tripping tool-calls work, splitting code up into multiple files is counter-productive. Can you expand on that?
- zer00eyz 7mo ago
  > independently work on a large codebase Im not sure that Humans are great at this either. Think about how we use frameworks and have complex supply chains... we sort of get "good enough" at what we need to do and pray a lot that everything else keeps working and that our tooling (things like artifactory) save us from supply chain attacks. Or we just run piles of old, outdated code because "it works". I cant tell you how many micro services I have seen that are "just fine" but no one in the current org has ever read a line of what's in them, and the people who wrote them left ages ago. > clarity too Yes, but define clarity! I recently had the pleasure of fixing a chunk of code that was part of a data pipeline. It was an If/elseif/elseif structure... where the final two states were fairly benign and would have been applicable in 99 percent of cases. Everything else was to deal with the edge cases! I had an idea of where the issue was, but I didn't understand how the code ended up in the state it was in... Blame -> find the commit message (references ticket) -> find the Jira ticket (references sales force) -> find the original customer issue in salesforce, read through the whole exchange there. A two line comment could have spared me all that work, to get to what amounted to a dead simple fix. The code was absolutely clear, but without the "why" portion of the context I likely would have created some sort of regression, that would have passed the good enough testing that was there. I re-wrote a portion of the code (expanding variable names) - that code is now less "scannable" and more "readable" (different types of clarity). Dropped in comments: a few sentences of explaining, and references to the tickets. Went and updated tests, with similar notes. Meanwhile, elsewhere (other code base, other company), that same chain is broken... the "bug tracking system" that is referenced in the commit messages there no longer exists. I have a friend who, every time he updates his dev env, he calls me to report that he "had to go update the wiki again!" Because someone made a change and told every one in a slack message. Here is yet another vast repository of degrading, unsearchable and unusable tribal knowledge embedded in so many organizations out there. Don't even get me started on the project descriptions/goals/tasks that amount to pantomime a post-it notes, absent of any sort of genuine description. Lack of clarity is very much also a lack of "context" in situ problem.
  - grey-area 7mo ago
    I think humans are pretty good at it with small teams and the right structure. There are definitely dysfunctional orgs as you describe where humans produce garbage code yes. I blame the org for that, not the humans. As to what defines clarity, yes of course, like the word quality this is very hard to define, but we can certainly recognise when it was not considered. I think it is a goal worth striving for though, and abandoning code standards because we now have AI helpers is stupid and self-defeating, even if we think they are very capable and will improve. The end of history has not in fact arrived with generative AI, we still have to maintain software after.
Bayko 7mo ago
Ye I honestly don't understand his comment. Is it bad code writing? Pre 2026? Sure. In 2026. Nope. Is it going to be a headache for some poor person on oncall? Yes. But then again are you "supposed" to go through every single line in 2026? Again no. I hate it. But the world is changing and till the bubble pops this is the new norm
- yoz-y 7mo ago
  The jury on this one is still out.
- phtrivier 7mo ago
  Sorry, I was not clear enough. My first word was litteraly "Yes", so I agree that a function like this is a maintenance nightmare for a human. And, sure, the code might not be "optimized" for the LLM, or token efficiency. However, to try and make my point clearer: it's been reported that anthropic has "some developpers won't don't write code" [1]. I have no inside knowledge, but it's possible, by extension, to assume that some parts of their own codebase are "maintained" mostly by LLMs themselves. If you push this extension, then, the code that is generated only has to be "readable" to: * the next LLM that'll have to touch it * the compiler / interpreter that is going to compile / run it. In a sense (and I know this is a stretch, and I don't want to overdo the analogy), are we, here, judging a program quality by reading something more akin to "the x86 asm outputed by the compiler", rather than the "source code" - which in this case, is "english prompts", hidden somewhere in the claude code session of a developper ? Just speculating, obviously. My org is still very much more cautious, and mandating people to have the same standard for code generated by LLM as for code generated by human ; and I agree with that. I would _not_ want to debug the function described by the commentor. So I'm still very much on the "claude as a very fast text editor" side, but is it unreasonnable to assume that anthropic might be further on the "claude as a compiler for english" side ? [1] https://www.reddit.com/r/ArtificialInteligence/comments/1s7jjky/anthropic_ceo_i_have_engineers_within_anthropic/ https://www.reddit.com/r/ArtificialInteligence/comments/1s7j...
  - heavyset_go 7mo ago
    If that's the case then that's dumb
mdavid626 7mo ago
Oh boy, you couldn't be more wrong. If something, LLM-s need MORE readable code, not less. Do you want to burn all your money in tokens?
- jen20 7mo ago
  I very much doubt Anthropic devs are metered, somehow.
  - mvfc 6mo ago
    The company does pay per usage for something though, be it data center usage, be it water and power for their own data centers.
mrbungie 7mo ago
Can't wait to have LLM generated physical objects that explode on you face and no engineer can fix.
- phtrivier 7mo ago
  Oh, do we agree on that. I never said it was "smart" - I just had a theory that would explain why such code could exist (see my longer answer below).
ulrikrasmussen 7mo ago
Unit testing is much much harder when you have functions spanning thousands of lines and no abstractions. You have to white box test everything to ensure that you hit all code paths, and it is much more expensive to maintain such tests, both as a human and LLM. I don't think this can be ignored just because LLMs are writing the code.
- dntrkv 7mo ago
  Massive tests files are almost as bad a massive function. Scrolling through a 3k line test suite with multiple levels of nesting trying to figure out which cases are covered is a fucking pain in the ass.

Yes, if it was made for human comprehension or maintenance. If it's entirely generated / consumed / edited by an LLM, arguably the most important metric is... test coverage, and that's it ?

konart 7mo ago

Can't we have generated / llm generated code to be more human maintainable?

grey-area 7mo ago

LLMs are so so far away from being able to independently work on a large codebase, and why would they not benefit from modularity and clarity too?

olmo23 7mo ago
I agree the functions in a file should probably be reasonably-sized. It's also interesting to note that due to the way round-tripping tool-calls work, splitting code up into multiple files is counter-productive. You're better off with a single large file.
- AlexCoventry 7mo ago
  > due to the way round-tripping tool-calls work, splitting code up into multiple files is counter-productive. Can you expand on that?
zer00eyz 7mo ago
> independently work on a large codebase Im not sure that Humans are great at this either. Think about how we use frameworks and have complex supply chains... we sort of get "good enough" at what we need to do and pray a lot that everything else keeps working and that our tooling (things like artifactory) save us from supply chain attacks. Or we just run piles of old, outdated code because "it works". I cant tell you how many micro services I have seen that are "just fine" but no one in the current org has ever read a line of what's in them, and the people who wrote them left ages ago. > clarity too Yes, but define clarity! I recently had the pleasure of fixing a chunk of code that was part of a data pipeline. It was an If/elseif/elseif structure... where the final two states were fairly benign and would have been applicable in 99 percent of cases. Everything else was to deal with the edge cases! I had an idea of where the issue was, but I didn't understand how the code ended up in the state it was in... Blame -> find the commit message (references ticket) -> find the Jira ticket (references sales force) -> find the original customer issue in salesforce, read through the whole exchange there. A two line comment could have spared me all that work, to get to what amounted to a dead simple fix. The code was absolutely clear, but without the "why" portion of the context I likely would have created some sort of regression, that would have passed the good enough testing that was there. I re-wrote a portion of the code (expanding variable names) - that code is now less "scannable" and more "readable" (different types of clarity). Dropped in comments: a few sentences of explaining, and references to the tickets. Went and updated tests, with similar notes. Meanwhile, elsewhere (other code base, other company), that same chain is broken... the "bug tracking system" that is referenced in the commit messages there no longer exists. I have a friend who, every time he updates his dev env, he calls me to report that he "had to go update the wiki again!" Because someone made a change and told every one in a slack message. Here is yet another vast repository of degrading, unsearchable and unusable tribal knowledge embedded in so many organizations out there. Don't even get me started on the project descriptions/goals/tasks that amount to pantomime a post-it notes, absent of any sort of genuine description. Lack of clarity is very much also a lack of "context" in situ problem.
- grey-area 7mo ago
  I think humans are pretty good at it with small teams and the right structure. There are definitely dysfunctional orgs as you describe where humans produce garbage code yes. I blame the org for that, not the humans. As to what defines clarity, yes of course, like the word quality this is very hard to define, but we can certainly recognise when it was not considered. I think it is a goal worth striving for though, and abandoning code standards because we now have AI helpers is stupid and self-defeating, even if we think they are very capable and will improve. The end of history has not in fact arrived with generative AI, we still have to maintain software after.

Bayko 7mo ago

Ye I honestly don't understand his comment. Is it bad code writing? Pre 2026? Sure. In 2026. Nope. Is it going to be a headache for some poor person on oncall? Yes. But then again are you "supposed" to go through every single line in 2026? Again no. I hate it. But the world is changing and till the bubble pops this is the new norm

yoz-y 7mo ago
The jury on this one is still out.
phtrivier 7mo ago
Sorry, I was not clear enough. My first word was litteraly "Yes", so I agree that a function like this is a maintenance nightmare for a human. And, sure, the code might not be "optimized" for the LLM, or token efficiency. However, to try and make my point clearer: it's been reported that anthropic has "some developpers won't don't write code" [1]. I have no inside knowledge, but it's possible, by extension, to assume that some parts of their own codebase are "maintained" mostly by LLMs themselves. If you push this extension, then, the code that is generated only has to be "readable" to: * the next LLM that'll have to touch it * the compiler / interpreter that is going to compile / run it. In a sense (and I know this is a stretch, and I don't want to overdo the analogy), are we, here, judging a program quality by reading something more akin to "the x86 asm outputed by the compiler", rather than the "source code" - which in this case, is "english prompts", hidden somewhere in the claude code session of a developper ? Just speculating, obviously. My org is still very much more cautious, and mandating people to have the same standard for code generated by LLM as for code generated by human ; and I agree with that. I would _not_ want to debug the function described by the commentor. So I'm still very much on the "claude as a very fast text editor" side, but is it unreasonnable to assume that anthropic might be further on the "claude as a compiler for english" side ? [1] https://www.reddit.com/r/ArtificialInteligence/comments/1s7jjky/anthropic_ceo_i_have_engineers_within_anthropic/ https://www.reddit.com/r/ArtificialInteligence/comments/1s7j...
- heavyset_go 7mo ago
  If that's the case then that's dumb

mdavid626 7mo ago

Oh boy, you couldn't be more wrong. If something, LLM-s need MORE readable code, not less. Do you want to burn all your money in tokens?

jen20 7mo ago
I very much doubt Anthropic devs are metered, somehow.
- mvfc 6mo ago
  The company does pay per usage for something though, be it data center usage, be it water and power for their own data centers.

mrbungie 7mo ago

Can't wait to have LLM generated physical objects that explode on you face and no engineer can fix.

phtrivier 7mo ago
Oh, do we agree on that. I never said it was "smart" - I just had a theory that would explain why such code could exist (see my longer answer below).

ulrikrasmussen 7mo ago

Unit testing is much much harder when you have functions spanning thousands of lines and no abstractions. You have to white box test everything to ensure that you hit all code paths, and it is much more expensive to maintain such tests, both as a human and LLM. I don't think this can be ignored just because LLMs are writing the code.

dntrkv 7mo ago
Massive tests files are almost as bad a massive function. Scrolling through a 3k line test suite with multiple levels of nesting trying to figure out which cases are covered is a fucking pain in the ass.