[esafak]

All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing. The question is how to do it reliably, given that a human cannot possibly read all of it. The answer seems to me to involve spot checks with proofs of correctness and statistical quality control, the latter being things that can be automated. One issue I see is that the models are constantly changing and are therefore not well understood statistically.

[jimbokun]

If you are generating that many lines of code it’s also almost impossible to tell if you’re building the right thing. You need to deploy each functional change and measure if it’s giving you the expected outcome, before moving onto the next thing.

[JCTheDenthog]

>All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing.

Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.

[jcelerier]

> If you can deliver the same thing in fewer correct lines of code

it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.

Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?

[bluGill]

Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).

[robotresearcher]

Parent said "I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N."

You're arguing the inverse: that at least some parts of the code are independent of N. Sure. But the topic is the part that isn't.

[cratermoon]

This is still not an argument for more lines of code. It demonstrates that lines of code are positively correlated with number of features, yes. But that's like saying the number of nails scales with the size of a house. More nails does not create more house.

[esafak]

Then you simply produce those fewer lines of code even faster. The question is, how fast are you delivering correct code?

Moreover, writing too terse code harms readability and maintainability. There is such a thing as irreducible complexity.