Earlier quoted context omitted.
It’s still a bad metric. I have worked with code where 1000s of lines are very straightforward and linear. I’ve worked on code where 100 lines is crucial and very domain specific. It can be exceptionally clean and well-commented and it still takes days to unpack. The skills and effort required to review and understand those situations are quite different. One is like distance driving a boring highway in the Midwest:…
The number of bugs tends to be linear to lines of code written meaning fewer lines of code for the same functionality will have fewer bugs. So I’m pretty skeptical that reviewing 2000 lines of code won’t take any more time than reviewing 200 lines of code. Furthermore how do you know the AI generated lines are the open highway lines of code and not the mountain road ones? There might be hallucinations that pattern ma…
It depends on the code. If you’re comparing code of the same complexity then, sure, 2000 lines will take longer than 200.
I was comparing straight linear code to far more complex code. The bug/line rate will be different and the time to review per line will be different.
> Furthermore how do you know the AI generated lines are the open highway lines of code and not the mountain road ones?
Again, it depends on the code. Which was my point.
Linear code lacks branches, loops, indirection, and recursion. That kind of code is easy to reason about and easy to review. The assumptions are inherently local. You still have to be alert and aware to avoid driving into the cornfields.
It’s a different beast than something like a doubly-nested state machine with callbacks, though. There you have to be alert and aware, and it’s inherently much harder to review per line of code.