3 ms·

The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly. Li

The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly. Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality. A huge part of the job of Software Engineering is producing the right amount of code at the right time.

ben_w 3mo ago
> Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality. > A huge part of the job of Software Engineering is producing the right amount of code at the right time. Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small. 120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? No unit tests, no code review? Won awards. Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down. (Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)
- hatefulheart 3mo ago
  Survivorship bias, you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise, or a product that is possible within constraints that otherwise could have been a success, but not realised by sloppy work and incompetence. Furthermore the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So given the choice you yourself prefer top quality engineering, so do your customers. Much in the same way you are a customer of your projects dependencies. Difference being, as developers we get to see how the sausage is made, our customers only see second and third order effects.
  - aiisjustanif 3mo ago
    > you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.
    - bsenftner 3mo ago
      Well, that's the other side of incompetence: they know how to spin their tools, but they don't know when to stop, or how to stop the change requests, the balance between shippable, maintainable, and what the market wants at that time.
    - hatefulheart 3mo ago
      I understand and of course I am familiar with the hypothetical you are trying to set up here but I was specifically pointing out a logical fallacy I see banded round all the time by people who should know better or educate themselves. I will say that if “good engineering practices” comes up in your root cause analysis for a failure to launch a product you are not thinking critically.
    - resonious 3mo ago
      Over optimizing and spending too much time on engineering decisions is also something an incompetent development team would do.
  - deleted 3mo ago
    [deleted]
  - ben_w 3mo ago
    > Survivorship bias The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.
- preisschild 3mo ago
  Good point. In my experience even hobby free software projects are generally better engineered than most proprietary software sold by businesses
- rusk 3mo ago
  > Successful product though, wasn't it If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah. Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.
- 21asdffdsa12 3mo ago
  The first thing they buy of the success money though, is a struggling technical competitors, so that this team can clean up there mess. This would mean that AI is only a good contributor at startups and with prototypes.
- nyeah 3mo ago
  Lines of code are a business liability. They are future cost.
- andrewaylett 3mo ago
  There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company. One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive. The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.
- jmcqk6 3mo ago
  > Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small. One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.
- kingds 3mo ago
  I'd argue PayPal was a successful business, not a successful piece of software.
  - ben_w 3mo ago
    That's kind of the point. The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.
DanielHB 3mo ago
> Lines of code are a liability, not an asset. I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course). That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema. Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.
- aiisjustanif 3mo ago
  I don’t think this is a great argument for such a small amount of LoC. 1000 lines depending on the service it provides could be very small.
  - pluralmonad 3mo ago
    > more scalable but was freaking 100000 lines of code to maintain compared to the quick and dirty 1000 lines of code...
- hughw 3mo ago
  I wonder though if, as long as you have LLMs to maintain the extra code, it's worth it to gain the new feature. Less tech debt than your intuition expects.
  - andrewaylett 3mo ago
    Why would an LLM be any more capable of maintaining the extra code than I am?
    - hughw 3mo ago
      Sure man, knock yourself out.
another_twist 3mo ago
This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.
- RicardoLuis0 3mo ago
  > Measuring productivity with LoCs is like measuring output with cash burn. companies are doing that as well lol (re: tokenmaxxing)
epolanski 3mo ago
I think that coding reviews are no longer feasible as they used to. The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'. They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously. I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost. The industry has never valued product, let alone code quality except in places they are core to the business. Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.
- eiifr1 3mo ago
  [flagged]
  - epolanski 3mo ago
    > Damn you folks are legit stupid. You're definitely out of the line with such language. And naive. Your biggest error is thinking that: 1. there's quality software out there. It's definitely far from the industry standard, even in high budget big techs, far from it 2. that people opening the wallet care about software quality. good has been always better than perfect 3. that the average PR review has significant impact on code quality, clearly false by point 1. 4. that proper AI usage for doing adversarial reviews of plans and implementations won't catch by far more issues than the average pr out there nit picking coding styles but not even bothering to test the feature/branch Thus I stand to my opinion. Quality PRs are too expensive nowadays and the engineers that will thrive will be the already great ones that will be enhanced by the tool, not companies shelling money on reviewing the average garbage MIT-bred leetcode blackbelt is slopping. They will only involve core/critical code and libraries.
    - budsniffer952 3mo ago
      Don't bother my man. All of the commenters talk about the "bad code" AI writes as if the code that's out there in the world isn't also compete garbage. Of course, everyone here is in the 99th percentile in ability, am I right? The sheer number of people I'm meeting that say about trivial things "AI cant do that" is astonishing. Oh well.
sidewndr46 3mo ago
This is one of the things I ran into early on. LLM needs to compute the determinant of a matrix? Sure, just spit out some huge hyper optimized implementation of it. Good luck maintaining that. Slapping "use industry standard open source libraries for common functions" has improved the quality of LLM output for me by such a large margin.
deleted 3mo ago
[deleted]
davidpapermill 3mo ago
> A huge part of the job of Software Engineering is producing the right amount of code at the right time. I'd go further and say that usually the goal is to use as little code as possible without sacrificing readability. Brevity is compression, and compression surfaces the salient points of a problem. Elegance often comes down to brevity.
bigbuppo 3mo ago
So it's like jazz... it's the code you didn't commit that matters?
NotAFurry2 3mo ago
"A huge part of the job of Software Engineering is producing the right amount of code at the right time." But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)

ben_w 3mo ago

> Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality. > A huge part of the job of Software Engineering is producing the right amount of code at the right time. Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small. 120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? No unit tests, no code review? Won awards. Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down. (Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)

hatefulheart 3mo ago
Survivorship bias, you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise, or a product that is possible within constraints that otherwise could have been a success, but not realised by sloppy work and incompetence. Furthermore the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So given the choice you yourself prefer top quality engineering, so do your customers. Much in the same way you are a customer of your projects dependencies. Difference being, as developers we get to see how the sausage is made, our customers only see second and third order effects.
- aiisjustanif 3mo ago
  > you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.
  - bsenftner 3mo ago
    Well, that's the other side of incompetence: they know how to spin their tools, but they don't know when to stop, or how to stop the change requests, the balance between shippable, maintainable, and what the market wants at that time.
  - hatefulheart 3mo ago
    I understand and of course I am familiar with the hypothetical you are trying to set up here but I was specifically pointing out a logical fallacy I see banded round all the time by people who should know better or educate themselves. I will say that if “good engineering practices” comes up in your root cause analysis for a failure to launch a product you are not thinking critically.
  - resonious 3mo ago
    Over optimizing and spending too much time on engineering decisions is also something an incompetent development team would do.
- deleted 3mo ago
  [deleted]
- ben_w 3mo ago
  > Survivorship bias The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.
preisschild 3mo ago
Good point. In my experience even hobby free software projects are generally better engineered than most proprietary software sold by businesses
rusk 3mo ago
> Successful product though, wasn't it If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah. Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.
21asdffdsa12 3mo ago
The first thing they buy of the success money though, is a struggling technical competitors, so that this team can clean up there mess. This would mean that AI is only a good contributor at startups and with prototypes.
nyeah 3mo ago
Lines of code are a business liability. They are future cost.
andrewaylett 3mo ago
There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company. One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive. The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.
jmcqk6 3mo ago
> Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small. One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.
kingds 3mo ago
I'd argue PayPal was a successful business, not a successful piece of software.
- ben_w 3mo ago
  That's kind of the point. The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.

DanielHB 3mo ago

> Lines of code are a liability, not an asset. I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course). That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema. Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.

aiisjustanif 3mo ago
I don’t think this is a great argument for such a small amount of LoC. 1000 lines depending on the service it provides could be very small.
- pluralmonad 3mo ago
  > more scalable but was freaking 100000 lines of code to maintain compared to the quick and dirty 1000 lines of code...
hughw 3mo ago
I wonder though if, as long as you have LLMs to maintain the extra code, it's worth it to gain the new feature. Less tech debt than your intuition expects.
- andrewaylett 3mo ago
  Why would an LLM be any more capable of maintaining the extra code than I am?
  - hughw 3mo ago
    Sure man, knock yourself out.

another_twist 3mo ago

This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.

RicardoLuis0 3mo ago
> Measuring productivity with LoCs is like measuring output with cash burn. companies are doing that as well lol (re: tokenmaxxing)

epolanski 3mo ago

I think that coding reviews are no longer feasible as they used to. The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'. They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously. I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost. The industry has never valued product, let alone code quality except in places they are core to the business. Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.

eiifr1 3mo ago
[flagged]
- epolanski 3mo ago
  > Damn you folks are legit stupid. You're definitely out of the line with such language. And naive. Your biggest error is thinking that: 1. there's quality software out there. It's definitely far from the industry standard, even in high budget big techs, far from it 2. that people opening the wallet care about software quality. good has been always better than perfect 3. that the average PR review has significant impact on code quality, clearly false by point 1. 4. that proper AI usage for doing adversarial reviews of plans and implementations won't catch by far more issues than the average pr out there nit picking coding styles but not even bothering to test the feature/branch Thus I stand to my opinion. Quality PRs are too expensive nowadays and the engineers that will thrive will be the already great ones that will be enhanced by the tool, not companies shelling money on reviewing the average garbage MIT-bred leetcode blackbelt is slopping. They will only involve core/critical code and libraries.
  - budsniffer952 3mo ago
    Don't bother my man. All of the commenters talk about the "bad code" AI writes as if the code that's out there in the world isn't also compete garbage. Of course, everyone here is in the 99th percentile in ability, am I right? The sheer number of people I'm meeting that say about trivial things "AI cant do that" is astonishing. Oh well.

sidewndr46 3mo ago

This is one of the things I ran into early on. LLM needs to compute the determinant of a matrix? Sure, just spit out some huge hyper optimized implementation of it. Good luck maintaining that. Slapping "use industry standard open source libraries for common functions" has improved the quality of LLM output for me by such a large margin.

deleted 3mo ago

[deleted]

davidpapermill 3mo ago

> A huge part of the job of Software Engineering is producing the right amount of code at the right time. I'd go further and say that usually the goal is to use as little code as possible without sacrificing readability. Brevity is compression, and compression surfaces the salient points of a problem. Elegance often comes down to brevity.

bigbuppo 3mo ago

So it's like jazz... it's the code you didn't commit that matters?

NotAFurry2 3mo ago

"A huge part of the job of Software Engineering is producing the right amount of code at the right time." But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)