3 ms·
> "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
by mrandish 4mo ago
> "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 https://www.folklore.org/Negative_2000_Lines_Of_Code.html
- 2f2 4mo agoLmao I bloody love that.
- Quekid5 4mo agoAFAIK, the only correlation with LoC that's got solid evidence is this: the number of bugs correlates with LoC.
- gregdeon 4mo agoYep, this is exactly what I thought of too... If you believe negative lines of code is the goal, then they've gotten 8x _worse_!
- strix_varius 4mo agoExactly 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 4mo ago> But I'm using them as my tool, not being a tool using them. Keep believing that
- strix_varius 4mo agoDo you find it impossible to use LLMs productively without giving over your brain wholesale to them?