Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lines of code got a better publicist

curlewis.co.nz

Post reply on HN
Print view View original

51–60 of 309 posts

Re: Lines of code got a better publicist

#51

Post by DrewADesign »

getnormality wrote: post #5

This weird trend reached an apex in a Feb 2026 OpenAI blog post [1], recently on the front page [2], which describes the process for building... something... written 100% by agents. There is no description of what the thing is, no indication of what value it provides its users. The closest it gets is "the product has been used by hundreds of users internally, including daily internal power users". But the fact that t…

> "the product has been used by hundreds of users internally, including daily internal power users".

My guess is it’s an email filter.

> million lines of code

> written 100% by agents

Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.

Re: Lines of code got a better publicist

#52

Post by weakfish »

> But! Hold my beer… in February 2026 METR effectively walked it back : their follow-up estimates flipped to a speedup (with error bars wide enough to ride a Moto Guzzi, with panniers, through!), and they abandoned the study design entirely - because developers now refuse to work without AI, and can’t reliably self-report time on agentic work. Their latest position: AI probably speeds developers up in 2026, and we can no longer cleanly measure by how much.

This may be true, but they followed in May with this [0]:

> Importantly, survey results are not necessarily grounded in reality. There are reasons to be skeptical of people’s responses to counterfactual questions such as about AI’s effect on productivity — for instance, our study in early 2025 found that people overestimated AI’s effect on their time spent on tasks by 40 percentage points on average.

[0] https://metr.org/blog/2026-05-11-ai-usage-survey/#productivi...

Re: Lines of code got a better publicist

#53

Post by orwin »

gwerbin wrote: post #16
drooby wrote: post #14

Writing. Code. Is. No. Longer. The. Bottleneck. Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck. So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited. Teams have not re-organized to match th…

Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?

Depends on your company. I'd say very rarely, and never for long.

Re: Lines of code got a better publicist

#54

Post by JCTheDenthog »

esafak wrote: post #46
sunaurus wrote: 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…

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.

Re: Lines of code got a better publicist

#55

Post by vova4kin »

The thing LOC measures best is how much code someone now has to read, understand, and keep alive. That number going up is a cost, not an output.

I spend a lot of my time taking over codebases other people left behind, and the AI-heavy ones have a recognizable shape: lots of plausible-looking code, thin tests, and nobody who can tell you why a given abstraction exists. Writing was never the hard part. Deciding what not to build, and being able to delete it confidently later, is the part that does not get faster with a model.

What did get faster for me is reading and reverse-engineering unfamiliar code - which is a little ironic, since the same tools are now producing more of the unfamiliar code that needs reverse-engineering in the first place.

Re: Lines of code got a better publicist

#57

Post by orwin »

skydhash wrote: post #39
drooby wrote: post #14

Writing. Code. Is. No. Longer. The. Bottleneck. Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck. So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited. Teams have not re-organized to match th…

> Engineers don't want to do QA because it's "beneath them".. I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful. Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and…

'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.

I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)

Re: Lines of code got a better publicist

#59

Post by nlawalker »

Not a better publicist, but:

A) a newly-receptive audience - engineers who have discovered that they very much enjoy and appreciate the tradeoff of proximity to the code for amplified velocity and impact, now that it's possible to achieve without being a manager of messy human teams.

B) an ecosystem in which it's grown nearly impossible to connect a functional description of something to how much bespoke construction and effort was involved, partially because of marketing and partially because of how much software already exists to be built on top of. It's impossible to tell from a few paragraphs of functional description whether something was built in a weekend or took a team 4 years to ship, so volume of code is the natural fallback for describing complexity.

Re: Lines of code got a better publicist

#60

Post by esafak »

JCTheDenthog wrote: post #54
esafak wrote: 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.

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.

Post reply on HN