This is an interesting take. Especially these days when AI reviews are fairly decent and arguably comparable to, if not better than, most human reviews in most ways.
I did this on a small microservice for a project recently where risk was constrained and I didn't see much value or appetite for human reviews. AI review, if clear, merge straight to main.
I suppose the risk is you have a vibe coder with AI psychosis blasting stuff into main on a mature project? Do you have have any sense for level of seniority, team size and size of code base that would allow this?
I get the sense everyone would need to be very senior 10+ years experience, with a relatively small team (< 10), on a medium sized and relatively modern code base?
IMO code/service owners. Orgs can be scaled by splitting code ownership into teams owning different services. And if someone isn’t competent enough to ship code on the service they’ve been assigned to work on, they aren’t qualified to be employed working in that thing. They aren’t providing value to the organization (probably net negative).
PRs don’t actually solve the “but what if someone ships crap” problem. Taking capacity from competent engineers to review and correct other employee’s code defeats the purpose of employing people: to add capacity.
Juniors/employees in training should be shadowing or paired with someone who is competent until they are competent, and assigned work at their level.
Unpopular opinion: PRs are a massive waste of everyone’s time.
Competent engineers committing working increments of software straight to main and continuously integrated and deployed > PRs of any sort.
Correct. If you me PR for everything, you’re incompetent
This is an interesting take. Especially these days when AI reviews are fairly decent and arguably comparable to, if not better than, most human reviews in most ways.
I did this on a small microservice for a project recently where risk was constrained and I didn't see much value or appetite for human reviews. AI review, if clear, merge straight to main.
I suppose the risk is you have a vibe coder with AI psychosis blasting stuff into main on a mature project? Do you have have any sense for level of seniority, team size and size of code base that would allow this?
I get the sense everyone would need to be very senior 10+ years experience, with a relatively small team (< 10), on a medium sized and relatively modern code base?
IMO code/service owners. Orgs can be scaled by splitting code ownership into teams owning different services. And if someone isn’t competent enough to ship code on the service they’ve been assigned to work on, they aren’t qualified to be employed working in that thing. They aren’t providing value to the organization (probably net negative).
PRs don’t actually solve the “but what if someone ships crap” problem. Taking capacity from competent engineers to review and correct other employee’s code defeats the purpose of employing people: to add capacity.
Juniors/employees in training should be shadowing or paired with someone who is competent until they are competent, and assigned work at their level.