Comment by seadan83
6 days ago
Reviewing code is often slower than writing it. You don't have to be an exceptionally fast coder or slow reviewer for that to be true.
6 days ago
Reviewing code is often slower than writing it. You don't have to be an exceptionally fast coder or slow reviewer for that to be true.
The amount of time I spend going back and forth between the implementation and the test cases to verify that the tests actually fully cover the possible failure cases alone can easily exceed the time spent writing it, and that's assuming I don't pull the branch locally and start stepping through it in the debugger.
The idea that AI will make development faster because it eliminates the boring stuff seems quite bold because until we have AGI, someone still needs to verify the output, and code review tends to be even more tedious than writing boilerplate unless you're speed-reading through reviews.
If this was the case, regular code review as a practice would be entirely unworkable.
"regular" code review is indeed a total theater, a travesty, a farce.
Real, meticulous code review takes absolutely forever.
This speaks to the low quality assurance bar that most of the software industry lives by.
If you're programming for a plane's avionics, as an example, the quality assurance bar is much, much higher. To the point where any time-saving benefits of using an LLM are most likely dwarfed by the time it takes to review and test the code.
It's easy to say LLM is a game-changer when there are no lives at stake, and therefore the cost of any errors is extremely low, and little to no QA occurs prior to being pushed to production.
Interesting point! I'd like to explore this a bit more.
Would you mind going into a bit more specifics/details on why regular code review practice would become unworkable, like which specific part(s) of it?
Huh? Why? How? Say the code takes one day to write, and two days to review. What about that is unworkable?