3 ms·

> They're here, because even "bad" code has uses. We can have quantity over quality. We can generate throw-away programs (where the lack of maintainability does

> They're here, because even "bad" code has uses. We can have quantity over quality. We can generate throw-away programs (where the lack of maintainability doesn't matter). We can solve some problems by brute force (keep trying until tests pass). For people who can't program, even bad code can do more than no code. If this is an acceptable definition of software engineering productivity, where "quantity over quality" is prized, then hire me. Because I guarantee I can produce dozens of PRs daily, each having tens of thousands of LoC deltas (pick any language you desire), none of which having research and/or understanding underpinning them, and all easily quantified as being "brute force."

didibus 2mo ago
There's a quote I forgot that says: "There is a Quality to Quantity". I think it was from a Chinese person, as they took manufacturing of cheap things, low quality stuff, but managed to scale it to mass quantities. I agree with that, it may not be reliable, full featured, well designed, ergonomic, etc. But quantity enables things and thus is a quality in itself. It allows use-cases that benefit from accessible cheap software. Those use-cases were not viable prior, because cost/time was prohibitive.
- frowaway4anoday 2mo ago
  Often attributed to Stalin in reference to the mass production focus of the Soviet war machine. https://quotees.co.uk/war/joseph-stalin-quantity-has-a-quality-all-its-own-quote/ https://quotees.co.uk/war/joseph-stalin-quantity-has-a-quali... When you treat scale as a design criteria, you get a different product
  - didibus 2mo ago
    Ah interesting, it does say probably, so seems it's not fully confirmed. In any case, I guess my brain re-interpreted it in the context of manufacturing and making products and remembered it as that.
- AdieuToLogic 2mo ago
  > There's a quote I forgot that says: "There is a Quality to Quantity". > I agree with that, it may not be reliable, full featured, well designed, ergonomic, etc. But quantity enables things and thus is a quality in itself. It allows use-cases that benefit from accessible cheap software. The underlying assumption here is that the quantity delivered is acceptable and does not worsen the customer experience. To continue with the manufacturing domain example; if a company produced widgets quickest and for minimal cost, yet had more lawsuits stemming from their use, is that the kind of enabling an organization should pursue? > Those use-cases were not viable prior, because cost/time was prohibitive. Sometimes a cigar is a cigar and sometimes what is thought to be a desirable use-case is prohibitive because, once sufficiently vetted, it is neither cost nor time which disqualifies it.
  - didibus 2mo ago
    You're just saying quantity is not always a desirable quality. That's true, and hence it's not every use-case that would favor quantity over other qualities. But there also exists those which do, and trading other qualities for quantity can be a good trade off. > the quantity delivered is acceptable and does not worsen the customer experience No, it will explicitly worsen the customer experience in other ways, but it will also give them a benefit: access to something they couldn't afford at all before.
Marha01 2mo ago
> Because I guarantee I can produce dozens of PRs daily, each having tens of thousands of LoC deltas (pick any language you desire), none of which having research and/or understanding underpinning them, and all easily quantified as being "brute force." I can guarantee that you cannot produce such PRs in the same quantity/quality than a modern LLM. The speed at which today's LLMs output code is superhuman.
- AdieuToLogic 2mo ago
  > I can guarantee that you cannot produce such PRs in the same quantity/quality than a modern LLM. Who said I would not use a combination of LLMs, scripts, and any other automation technique available?
ReservoirPengui 2mo ago
It's textbook historical revisionism. It's not like we didn't have mountains of bad code in the pre-LLM era. I'm old enough to remember endless complaint posts about having to wotk with legacy codebases full of horrible spaghetti code. Somebody took a long time to write it by hand.
- nevertoolate 2mo ago
  Have you realized you are attacking a straw-man? Nobody said all “hand written” code is good. I _think_ the implicit argument is: “all vibed code lacks cohesion”.
pornel 2mo ago
I'm not happy about the drop in quality either, and I'm not advocating for just making software shittier. However, look at history of DSLR cameras vs mobile phone cameras. Mobile phones were always worse than large format cameras, and we've got a massive quantity-over-quality explosion in photos taken. It didn't replace professional photography, but let people upload photos of their lunch to social media. I think in programming we're getting frustrated because we're trying to naively use high-volume low-quality code generators in our previous low-volume high-quality workflows. We're still discovering what's the programming equivalent of bathroom selfies, photos of receipts and QR codes.

didibus 2mo ago

There's a quote I forgot that says: "There is a Quality to Quantity". I think it was from a Chinese person, as they took manufacturing of cheap things, low quality stuff, but managed to scale it to mass quantities. I agree with that, it may not be reliable, full featured, well designed, ergonomic, etc. But quantity enables things and thus is a quality in itself. It allows use-cases that benefit from accessible cheap software. Those use-cases were not viable prior, because cost/time was prohibitive.

frowaway4anoday 2mo ago
Often attributed to Stalin in reference to the mass production focus of the Soviet war machine. https://quotees.co.uk/war/joseph-stalin-quantity-has-a-quality-all-its-own-quote/ https://quotees.co.uk/war/joseph-stalin-quantity-has-a-quali... When you treat scale as a design criteria, you get a different product
- didibus 2mo ago
  Ah interesting, it does say probably, so seems it's not fully confirmed. In any case, I guess my brain re-interpreted it in the context of manufacturing and making products and remembered it as that.
AdieuToLogic 2mo ago
> There's a quote I forgot that says: "There is a Quality to Quantity". > I agree with that, it may not be reliable, full featured, well designed, ergonomic, etc. But quantity enables things and thus is a quality in itself. It allows use-cases that benefit from accessible cheap software. The underlying assumption here is that the quantity delivered is acceptable and does not worsen the customer experience. To continue with the manufacturing domain example; if a company produced widgets quickest and for minimal cost, yet had more lawsuits stemming from their use, is that the kind of enabling an organization should pursue? > Those use-cases were not viable prior, because cost/time was prohibitive. Sometimes a cigar is a cigar and sometimes what is thought to be a desirable use-case is prohibitive because, once sufficiently vetted, it is neither cost nor time which disqualifies it.
- didibus 2mo ago
  You're just saying quantity is not always a desirable quality. That's true, and hence it's not every use-case that would favor quantity over other qualities. But there also exists those which do, and trading other qualities for quantity can be a good trade off. > the quantity delivered is acceptable and does not worsen the customer experience No, it will explicitly worsen the customer experience in other ways, but it will also give them a benefit: access to something they couldn't afford at all before.

Marha01 2mo ago

> Because I guarantee I can produce dozens of PRs daily, each having tens of thousands of LoC deltas (pick any language you desire), none of which having research and/or understanding underpinning them, and all easily quantified as being "brute force." I can guarantee that you cannot produce such PRs in the same quantity/quality than a modern LLM. The speed at which today's LLMs output code is superhuman.

AdieuToLogic 2mo ago
> I can guarantee that you cannot produce such PRs in the same quantity/quality than a modern LLM. Who said I would not use a combination of LLMs, scripts, and any other automation technique available?

ReservoirPengui 2mo ago

It's textbook historical revisionism. It's not like we didn't have mountains of bad code in the pre-LLM era. I'm old enough to remember endless complaint posts about having to wotk with legacy codebases full of horrible spaghetti code. Somebody took a long time to write it by hand.

nevertoolate 2mo ago
Have you realized you are attacking a straw-man? Nobody said all “hand written” code is good. I _think_ the implicit argument is: “all vibed code lacks cohesion”.

pornel 2mo ago

I'm not happy about the drop in quality either, and I'm not advocating for just making software shittier. However, look at history of DSLR cameras vs mobile phone cameras. Mobile phones were always worse than large format cameras, and we've got a massive quantity-over-quality explosion in photos taken. It didn't replace professional photography, but let people upload photos of their lunch to social media. I think in programming we're getting frustrated because we're trying to naively use high-volume low-quality code generators in our previous low-volume high-quality workflows. We're still discovering what's the programming equivalent of bathroom selfies, photos of receipts and QR codes.