We only do about 3-10 reviews a week, depending… it’s not there to replace you, it’s there to help.
Before AI assistance we would do fewer reviews, because the AI is finding things - real things worth fixing - now some reviews (the reviews of our colleagues who haven’t figured out how to use AI to review their pull requests before submitting them effectively) get recycled 2-3 times before they’re adequately cleaned up.
Documentation and requirements are better aligned with code, unit test coverage is better, and the developers who use AI to review their code before putting in a pull request generally are getting through on the first pass. You still have to read the documentation and requirements, review the code, but now it’s actually approaching accurate and complete much more closely than it used to.
Our team is small and diverse, some do embedded C, some do GUI oriented .NET, some do backend processing in Rust / Linux - we all know our domains and there is lots of value in the collective wisdom, but it doesn’t translate super easily or efficiently - AI is helping with that.
If you’ve got 100 pull requests to review every day - quit. Maybe stick around for the paycheck until you find something better, but that’s not a job, that’s a clusterbomb waiting to go off.
For this, we need to start using (much more) secure ID tech, so you really know who is submitting, and prioritize those who have made good quality submissions in the past. Sadly, this may negelect “unknown” authors, but such is life.
Also, we may need to recruit more code authors / wanna be code authors to act as code reviewers more of the time, perhaps following the model we use in our commercial operation where all authors also act as reviewers.
That’s fine when you’re looking at 1 or 2 reviews. Now try sifting through hundreds a day.
We only do about 3-10 reviews a week, depending… it’s not there to replace you, it’s there to help.
Before AI assistance we would do fewer reviews, because the AI is finding things - real things worth fixing - now some reviews (the reviews of our colleagues who haven’t figured out how to use AI to review their pull requests before submitting them effectively) get recycled 2-3 times before they’re adequately cleaned up.
Documentation and requirements are better aligned with code, unit test coverage is better, and the developers who use AI to review their code before putting in a pull request generally are getting through on the first pass. You still have to read the documentation and requirements, review the code, but now it’s actually approaching accurate and complete much more closely than it used to.
Our team is small and diverse, some do embedded C, some do GUI oriented .NET, some do backend processing in Rust / Linux - we all know our domains and there is lots of value in the collective wisdom, but it doesn’t translate super easily or efficiently - AI is helping with that.
If you’ve got 100 pull requests to review every day - quit. Maybe stick around for the paycheck until you find something better, but that’s not a job, that’s a clusterbomb waiting to go off.
I was referring to the people running open source projects that are receiving 100s of reviews per day from people just blasting outs PRs.
For this, we need to start using (much more) secure ID tech, so you really know who is submitting, and prioritize those who have made good quality submissions in the past. Sadly, this may negelect “unknown” authors, but such is life.
Also, we may need to recruit more code authors / wanna be code authors to act as code reviewers more of the time, perhaps following the model we use in our commercial operation where all authors also act as reviewers.