Yeah the review fatigue thing is a huge problem at the moment. When your work becomes 90% reviewing AI code, it is very demotivating.
I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code. (And on setting up rules for what the lines of code should look like that are easily checked with deterministic tools or by llms.)
For large diffs, I’ll have the human driver walk me through the code in a call and if they understand it well enough to explain it to me, and explain the implications of the changes, that’s good enough for me; if they can’t answer how something works, I’ll respectfully turn down their contribution.
This cost shifting is how I stay sane and avoid burn out at work as well as stay apprised of major behavioral changes in the software we run.
I also think it’s important to emphasize that in an organization, individual productivity is secondary to group productivity, and group productivity is different than the sum of its parts.
I understand your reasoning but my reaction to this suggestion is very strong revulsion :) On both sides of it, I would despise this process.
But you're right about thinking in terms of group productivity and costs and incentives.
We solved this at work by creating a system that has an LLM read a Jira ticket assigned to Mike, create an implementation by itself and post a PR using a service account. Then Mike can come along and review it, thereby satisfying peer review as it was authored by a different user (in our SCM) than the one that reviewed it.
Needless to say it is getting really hard to care about my job anymore
> I have been focusing a lot more on testing and "manual" validation than on reviewing individual lines of code.
Same, but there is a reason I did not choose to work in QA so this sucks too
Fair. But a big part of what I disliked was the tedium, which is largely alleviated. I quite enjoy making sure things I'm building work properly, now.
[flagged]