[mrandish]

> "A caveat: Lines of code is an imperfect measure"

I'm pleased they at least included this. However, they address the caveat by 'rounding down' the estimated multiple of the gain. I'm not sure that is the correct adjustment, especially once we understand the range isn't limited to positive numbers.

There's strong evidence the range of code productivity denominated in "lines of code" should include negative numbers, especially in the highest-quality sphere. Perhaps the earliest and most legendary example: https://www.folklore.org/Negative_2000_Lines_Of_Code.html

[strix_varius]

Exactly this. Just this week an engineer who seems to purely vibe everything submitted a +700ish LoC fix for what seemed like a pretty simple issue. Moreover it was a perf issue, which in my experience is not usually best fixed by adding more stuff.

Today, I merged my fix, net -381 LoC.

I'm using them too of course, they read and type and hunt for bugs and test faster than I can. But I'm using them as my tool, not being a tool using them.

[xyzsparetimexyz]

> But I'm using them as my tool, not being a tool using them.

Keep believing that

[strix_varius]

Do you find it impossible to use LLMs productively without giving over your brain wholesale to them?

[Quekid5]

AFAIK, the only correlation with LoC that's got solid evidence is this: the number of bugs correlates with LoC.

[gregdeon]

Yep, this is exactly what I thought of too... If you believe negative lines of code is the goal, then they've gotten 8x _worse_!

[2f2]

Lmao I bloody love that.