Live data from Hacker News

Lines of code got a better publicist

curlewis.co.nz

61–70 of 309 posts

Re: Lines of code got a better publicist

#61
post #6

I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to, except apparently it was not satire at all, and indeed seemed to reflect the position of many CEOs etc when it comes to LLM code generation. I do think that over the past few months, it feels like the hype around producing unmaintainab…

The word “slop” was a good choice to talk about the mass of code generated by AI. I think it resonates with non-tech people and it conveys disgust. It’s clear that we should avoid slop. “Technical debt” never hooked management in the same way and we have found it hard to convince them that it needs to be addressed. Debt in general is something that can be a problem, but doesn’t need to be avoided or addressed until i…

Technical debt is a indefinable quantity which makes it very prone to be abused to mean "I wish I could rewrite this in [insert some fashionable language, framework or coding style]".

AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.

Re: Lines of code got a better publicist

#63
I don't see LOC as that different from number of hours in the office. They'd always say pre-pandemic "If they're not in the office, how will I know they're working?" Simple, use the output metrics that you use to evaluate all of your workers to see what they contribute to the business.

Re: Lines of code got a better publicist

#64

Earlier quoted context omitted.

Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction: > Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.

> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s t…

It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going to be "left in the dust".

Re: Lines of code got a better publicist

#65
post #46

Earlier quoted context omitted.

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 con…

>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.

> 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?

Re: Lines of code got a better publicist

#67

Earlier quoted context omitted.

> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s t…

It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going…

Yeah, I’ll second that. I see folks moving _fast_, but boy oh boy are they breaking things (or delivering something that never worked) which if anything makes _me_ slower lol

Re: Lines of code got a better publicist

#68

> I think every engineer should be using AI daily. Why?

Because it's fun. And why shouldn't we be into incremental automation?

I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.

Re: Lines of code got a better publicist

#69
>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.

It is weird that the author seems to understand that the pro-AI claims made by AI companies about the product’s necessity are not falsifiable, but then backtracks with “woah woah woah but don’t think I’m anti-AI.”

How is the assertion above any more rigorous than the productivity claims the author is criticizing throughout the rest of the article? That you won’t “survive” if you don’t adopt AI within a few months?

It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…

Re: Lines of code got a better publicist

#70

Earlier quoted context omitted.

Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction: > Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.

I read the entire paragraph, and the entire article. Nothing in there explained to me why every engineer should be using AI every day.

Because I don't think that's the point of the article, which is just a commentary about how AI labs are marketing the effectiveness of their services by using terms like "8x more code per quarter" like that's an obvious good thing (which it isn't).

If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.

Post reply on HN