← Back to context

Comment by BeetleB

17 hours ago

It's a code review, right?

Give feedback that about the docs and block merging till the issue is resolved.

36 comments

BeetleB

Reply
LPisGood  16 hours ago

This sounds easy in principle, but a half dozen of these sort sorts of massive PR’s per week is basically untenable. I’m not gonna read the hundreds of lines of added documentation to decide if they’re correct or not. The price of generating new words is just so much higher than the price of evaluating it that I can’t be bothered.

  • tcmart14  9 hours ago

    Just hit "deny." I've been training my co-workers that the AI-isms their "AI Assisted coding" do that some shit just isn't acceptable. I leave a comment and hit deny. It also helps that I control the policies on the repo and they can't merge in with a denial from anyone. So it's either a fix it, or explain why your work isn't getting done. My manager is also 100% with this.

    I've denied for poor branch names and commits from AI. I've denied for too verbose of comments from AI. I've denied for parts of the code base being touched that are not relevant to the case they are working on (login isn't broken, your case is to add a check box in the settings pane, remove the changes made to login).

    Pre-AI I wasn't fine with PRs with multiple features and touching irrelevant areas of the code base. Why would I be fine with it because my co-workers got new toys? You want AI to refactor a part of the codebase? Fine. Separate branch, new PR, and in the description, present an argument for it. Don't shoe horn it into something else. Also, I'm not obligated to hit approved on shit.

    I may also be a bit privileged because I can be a pain in the ass to whole team. I may be slower, but I've got the numbers, my code is creating way less bugs then my "fast more efficient" co-workers.

  • BeetleB  16 hours ago

    > but a half dozen of these sort sorts of massive PR’s per week is basically untenable.

    Actually, rejecting them is precisely what will make them easy.

    "Sorry, the comments are so bad I'm stopping here. Please fix them and then I'll resume the code review."

    You're giving everybody (including yourself) more work by:

    1. Reviewing the code (even if you skip the documentation).

    2. Letting too many abstruse comments in which everyone in the team will have to read.

    3. Allowing the behavior to continue.

    Become the bottleneck so the team can talk about it. If they decide this shouldn't be a blocker, just declare you won't review the comments going forward.

    • matheusmoreira  9 hours ago

      > "Sorry, the comments are so bad I'm stopping here. Please fix them and then I'll resume the code review."

      This is also how I do code review of AI work on my projects. If the work is offensive to the point I can't complete the review, I simply reject the code and tell the AI why. Then it goes off and fixes it. This repeats until the issues are either gone or are small enough that I can just fix them myself and move on.

      There is no need to be upset. Just iterate until it's right. If it's cheap to write, it's equally cheap to rewrite.

Gigachad  15 hours ago

You can't keep up with the slop. And before you finish a first pass read on the wall of diff, another AI sloperator on the team has hit approve and the PR is merged.

  • LPisGood  14 hours ago

    Exactly this. Even if I spend a bunch of time requesting a review — and our team does respect each other enough to at least nominally respond to comments before merging — the update itself will be another thousand line diff from the original that requires again the same level of review or I just accept that it looks fine.