“You as an author, you own the change. So you actually still need to read and understand your AI-generated change before asking anyone else to spend time on reviewing your potential AI slop. For a low-risk change with high confidence, we can maybe just trust our tests and rely on an AI review. But for the high-risk ones or the low-confidence changes, we need to ask someone else to review, not just for finding bugs, but also to spread knowledge.”
Engineering Enablement · Software Engineering & Infra · November 2026
Context
Brian Houck asked for one change a team could try to make developers' days better. André Meyer's answer is a team agreement on pull request etiquette for AI-assisted work, because review load is growing and developers either rubber-stamp reviews or get stressed doing them properly.
Transcript
Yeah, then just if I then have a question, but I know that my team will be around later for collaboration time, I might be willing to wait for half an hour or an hour to ask that question instead of just dropping by my colleague and interrupting them all the time.
…Andre. If a team wanted to make more of their work days quote-unquote good over the next month, what's one change that you would recommend for them to try? And how would you tell whether it helped both the developers themselves, but also ultimately did it result in good outcomes for the customer?
So, my number one suggestion would be to optimize for focused versus collaboration work. But another thing I have been thinking of more recently is that PR review load is increasing a lot. And for developers, it's a huge challenge to deal with this growing review load. André Meyer they just rubber stamp reviews or they do it properly, which stresses them, increases cognitive load, and so on. So, what I would do is I would gather with the team and agree on something like a PR etiquette for AI-assisted work, basically saying, Okay, you as an author, you own the change. So, this means you actually still need to read and understand your AI-generated change before asking anyone else to spend time on reviewing your potential AI slop. And then the author might also need to rate something like the risk level or like a confidence score or something, because if it's a low-risk change or like high confidence in that change, we can maybe just trust our tests. So, we may not even need to ask someone else to, or like another human, to review it, and we can just rely on an AI review. But for the high-risk ones or the low-confidence changes, we need to ask someone else to review, even not just for finding bugs, but also to spread knowledge…
So, if I understand, it's like a mix of both having the time to do deep focused work and then having clearly agreed to sort of accountabilities and boundaries on where everyone's responsibilities lie on that. And you think like doing those two things will lead to better days?
Absolutely. Yeah, I think if we can reduce the number one thing that we still keep hearing in the age of AI, which are meetings and too many interruptions, that's an actionable and simple thing to. To work on and explore. And the other thing really is the growing cognitive load that developers keep…
Awesome. I think that's a great place to leave it. I'd like to remind the audience: too many DevEx Metrics Compass little guidance is the paper out now. ACMQ could not encourage people to read it anymore. It is phenomenal. Andre, thank you so much for joining us.
More from Engineering Enablement
