3 ms·

In what context would generating code faster not be a desired outcome? Assuming of course everything else stays the same (quality, etc.)

nubg 2mo ago
I think most AI doomers will tell you that the quality of their code is better than LLM-generated code.
- c2h5oh 2mo ago
  I did witness ai output advantage dwindle as codebase grew in a team of experienced devs who switched to 99% ai generated changes. The last time I've checked ai still had an edge adding new features, but the team collectively lost the project knowledge and any problem discovered that llm could not fix took significantly longer to correct - they were effectively working on a new to them codebase.
c2h5oh 2mo ago
I think that question hinges on the second part of your comment and should be answered as: Does anyone know any company that went back to hand-written code because it decided drawbacks of ai generated code or some other concerns outweight the output benefits?
probably_wrong 2mo ago
Lines-of-code has long been accepted as a terrible measure for code quality, and I believe it has been strongly correlated with poorer code quality.
- samlinnfer 2mo ago
  It's correlates directly with business objectives.
- adamtaylor_13 2mo ago
  No one is advocating for lines of code here.
  - probably_wrong 2mo ago
    It has a 1-to-1 correlation, though: the faster you can generate code (which is the one quality under discussion), the more lines of code you can generate in a given unit of time, and vice versa. So I would argue we are talking about lines-of-code, just indirectly. I don't see how one can hold "speed of code generation" as a good metric while, simultaneously, holding "number of lines generated in a unit of time" as a bad metric. And more worrisome, I'm not sure how one would reward one without rewarding the other creating a perverse incentive. But I'm open to be proven wrong.
cyanydeez 2mo ago
It's so weird how "assuming" is like watching super man hold a train back from a little girl on the railroad tracks.
flohofwoe 2mo ago
Shitting out lots of code faster was already possible before (just hire more interns who do it for free heh) the question is at what quality and is more code in less time really the biggest problem in professional software development that had to be solved? LLMs can be very useful for all sorts of things, but large scale code generation is IMHO the least interesting use case. And even when LLMs are successfully used for code generation, I feel like progress has been reset to the early 60s and people are now rediscovering all the failed software development approaches (eg "spec-driven" is pretty much the equivalent of "waterfall", I'm now waiting for UML diagrams to make a comeback as the next big thing with an "agentic engineering" label slapped on ;) Classic interactive "vibecoding" with quick turnaround times (but much quicker than now please, don't make me wait and let me slip out of the flow) might actually turn out to be the most useful way to build software with LLMs (or let's better say "prototypes"). Because everything else currently looks like we're building up too much bureaucracy around the software development process again, and just in time when we finally got rid of that shit (now we have that absurd amount of .md files in pseudo-human-language as "skills", "rules", "context", "memory", ...) like it was common in the 70s when the work was split between "software architects" who only do the high level design, and "implementers" who only bake that design into code. This was obviously a stupid idea and I don't know why the "AI bros" seem to be so keen on repeating that mistake. Every approach that builds a "human language specification" that's separate from source code written in a much more precise programming language is doomed to fail (eg the code is the spec!), and that's nothing new, we've known this for decades, but that brain virus of "upfront software architecture" always keeps creeping back into the minds of people at the first opportunity.
- adamtaylor_13 2mo ago
  It's fascinating how people jump straight into their biases, making all sorts of inferences that were never mentioned. Where did anyone advocate for "large scale code generation"? LLMs are a fantastic way to go from, "We thought this this feature" to "It's shipped and in people's hands". That could've been 100 lines or 1,000 lines but that's not the point.
  - flohofwoe 2mo ago
unknownfuture 2mo ago
> Assuming of course everything else stays the same (quality, etc.) Kinda begging the question, aren't we here?

nubg 2mo ago

I think most AI doomers will tell you that the quality of their code is better than LLM-generated code.

c2h5oh 2mo ago
I did witness ai output advantage dwindle as codebase grew in a team of experienced devs who switched to 99% ai generated changes. The last time I've checked ai still had an edge adding new features, but the team collectively lost the project knowledge and any problem discovered that llm could not fix took significantly longer to correct - they were effectively working on a new to them codebase.

c2h5oh 2mo ago

I think that question hinges on the second part of your comment and should be answered as: Does anyone know any company that went back to hand-written code because it decided drawbacks of ai generated code or some other concerns outweight the output benefits?

probably_wrong 2mo ago

Lines-of-code has long been accepted as a terrible measure for code quality, and I believe it has been strongly correlated with poorer code quality.

samlinnfer 2mo ago
It's correlates directly with business objectives.
adamtaylor_13 2mo ago
No one is advocating for lines of code here.
- probably_wrong 2mo ago
  It has a 1-to-1 correlation, though: the faster you can generate code (which is the one quality under discussion), the more lines of code you can generate in a given unit of time, and vice versa. So I would argue we are talking about lines-of-code, just indirectly. I don't see how one can hold "speed of code generation" as a good metric while, simultaneously, holding "number of lines generated in a unit of time" as a bad metric. And more worrisome, I'm not sure how one would reward one without rewarding the other creating a perverse incentive. But I'm open to be proven wrong.

cyanydeez 2mo ago

It's so weird how "assuming" is like watching super man hold a train back from a little girl on the railroad tracks.

flohofwoe 2mo ago

Shitting out lots of code faster was already possible before (just hire more interns who do it for free heh) the question is at what quality and is more code in less time really the biggest problem in professional software development that had to be solved? LLMs can be very useful for all sorts of things, but large scale code generation is IMHO the least interesting use case. And even when LLMs are successfully used for code generation, I feel like progress has been reset to the early 60s and people are now rediscovering all the failed software development approaches (eg "spec-driven" is pretty much the equivalent of "waterfall", I'm now waiting for UML diagrams to make a comeback as the next big thing with an "agentic engineering" label slapped on ;) Classic interactive "vibecoding" with quick turnaround times (but much quicker than now please, don't make me wait and let me slip out of the flow) might actually turn out to be the most useful way to build software with LLMs (or let's better say "prototypes"). Because everything else currently looks like we're building up too much bureaucracy around the software development process again, and just in time when we finally got rid of that shit (now we have that absurd amount of .md files in pseudo-human-language as "skills", "rules", "context", "memory", ...) like it was common in the 70s when the work was split between "software architects" who only do the high level design, and "implementers" who only bake that design into code. This was obviously a stupid idea and I don't know why the "AI bros" seem to be so keen on repeating that mistake. Every approach that builds a "human language specification" that's separate from source code written in a much more precise programming language is doomed to fail (eg the code is the spec!), and that's nothing new, we've known this for decades, but that brain virus of "upfront software architecture" always keeps creeping back into the minds of people at the first opportunity.

adamtaylor_13 2mo ago
It's fascinating how people jump straight into their biases, making all sorts of inferences that were never mentioned. Where did anyone advocate for "large scale code generation"? LLMs are a fantastic way to go from, "We thought this this feature" to "It's shipped and in people's hands". That could've been 100 lines or 1,000 lines but that's not the point.
- flohofwoe 2mo ago

unknownfuture 2mo ago

> Assuming of course everything else stays the same (quality, etc.) Kinda begging the question, aren't we here?