16 ms·

Ask HN: How to deal with long vibe-coded PRs?

• zigcBenx 11mo ago
  In my opinion no PR should have so much changes. It's impossible to review such things. The only exception is some large migration or version upgrade that required lots of files to change. As far it goes for Vibe coded gigantic PRs It's a straight reject from me.
• aaronrobinson 11mo ago
  Reject it
• wengo314 11mo ago
  reject outright. ask to split it into reasonable chain of changesets.
• bulucantik 11mo ago
  [dead]
• JohnFen 11mo ago
  I'd just reject it for being ridiculous. It didn't pass the first step of the review process: the sniff test.
  • brudgers 11mo ago
    Charitably, even though it is not what you or I would do, the pull request could be a best good faith effort of a real human being. So to me, it's less about being ridiculous (and "ridiculous" is a fighting word) and more a simple "that's not how this team does things because we don't have the resources to work that way." Mildly hurt feelings in the most likely worst case (no food for a viral overtop tweet). At best recruitment of someone with cultural fit.
    • JohnFen 11mo ago
      My objection to a PR like this has nothing to do with whether or not a human wrote it. It's that the PR is too large and complex. The reason I'd give for rejecting it would be that. I wouldn't say "it's ridiculous" as the reason. I would 100% be thinking that, though.
      • brudgers 11mo ago
        That’s good. My experience is “too large/complex” provides an opening for arguementivenes and/or drama. “We don’t do it like this” does not so much. It is social, sufficient and not a matter of opinion (“too” is a matter of opinion).
        • BrenBarn 11mo ago
          What about "this is large and complex enough to be not the way we do things"?
    • f311a 11mo ago
      It's very rare to see 9K PRs by humans. They usually take weeks of work if it's a serious change. No one wants to spend such an amount of time just to get rejected. You split it and send one by one while discussing changes. But if it takes 1 hour with AI, you just send it right away...
• yodsanklai 11mo ago
  You review it like it wasn't AI generated. That is: ask author to split it in reviewable blocks. Or if you don't have an obligation to review it, you leave it there.
  • gpm 11mo ago
    Eh, ask the author to split it in reviewable blocks if you think there's a chance you actually want a version of the code. More likely if it's introducing tons of complexity to a conceptually simple service you just outright reject it on that basis. Possibly you reject it with "this seems more suitable for a fork than a contribution to the existing project". After all there's probably at least some reason they want all that complexity and you don't.
  • resonious 11mo ago
    This is it. The fact that the PR was vibe coded isn't the problem, and doesn't need to influence the way you handle it.
    • gdulli 11mo ago
      It would be willfully ignorant to pretend that there's not an explosion of a novel and specific kind of stupidity, and to not handle it with due specificity.
      • deleted 11mo ago
        [deleted]
      • WalterSear 11mo ago
        I contend that, by far and away the biggest difference between entirely human-generated slop and AI-assisted stupidity is the irrational reaction that some people have to AI-assisted stuff.
        • hatefulmoron 11mo ago
          Calling things "slop" is just begging the question. The real differentiating factor is that, in the past, "human-generated slop" at least took effort to produce. Perhaps, in the process of producing it, the human notices what's happening and reconsiders (or even better, improves it such that it's no longer "slop".) Claude has no such inhibitions. So, when you look at a big bunch of code that you haven't read yet, are you more or less confident when you find out an LLM wrote it?
• tacostakohashi 11mo ago
  Use AI to generate the review, obviously.
• devrundown 11mo ago
  9000 LOC is way too long for a pull request unless there is some very special circumstance. I would ask them to break it up into smaller chunks.
• rvrs 11mo ago
  Enforce stacked PRs, reject PRs over 500-1k LoC (I'd argue even lower, but it's a hard sell)
• hshdhdhehd 11mo ago
  With a middle finger
• vasan 11mo ago
  Just reflect upon it, see if you gave him less time to complete it. I would just have a meet with him and confront it.
• CharlieDigital 11mo ago
  Ask the submitter to review and leave their comments first or do a peer code review with them and force them to read the code. It's probably the first time they'll have read the code as well...
  • groguzt 11mo ago
    I really like this, the fact that vibe coded PRs are often bad is that people don't review it themselves first, they just look at the form, and if it looks vaguely similar to what they had in their mind, they'll just hit save and not ask the LLM for corrections
• TriangleEdge 11mo ago
  Amazon eng did some research and found the number of comments in a code review is proportional to the number of lines changed. Huge CRs get little comments. Small CRs get a lot of comments. At Amazon, it's common to have a 150 to 300 line limit to changes. It depends on the team. In your case, I'd just reject it and ensure repo merges require your approval.
  • zukzuk 11mo ago
    That’s a great way to discourage anyone ever doing any large scale refactoring, or any other heavy lifting.
    • TriangleEdge 11mo ago
      The review bots can be bypassed.
    • arachnid92 11mo ago
      Just split up your work across multiple PRs.
    • febusravenga 11mo ago
      That's good. Because large refactorings are usually harmful. They are also usually unplanned, not scoped and based on very unquantifiable observations like "I don't like the code is structured" - let's do ity way.
    • Cthulhu_ 11mo ago
      That's a good thing, large scale refactorings should be very, very rare. Even automated code style changes can be controversial because of the churn they create. For large and/or important software, churn should be left to a minimum, even at the cost of readability or code cleanliness. I've seen enough open source projects that simply state they won't accept refactoring / reformatting PRs.
      • gempir 11mo ago
        That means your code will stay old. A new language feature is released, you cannot apply it to old code, since that would make a big PR. You need to do super slowly over time and most old code will never see it. A better static type checker, that finds some bugs for you, you cannot fix them as your PR would be too big, you instead would need to make a baseline and split it up endlessly. In theory yes, maybe a bit safer to do it this way, but discouraging developers to make changes is bad IMO. Obviously depends on your usecase, if you develop software that is critical to people's literal life, then you'll move more carefully. But I wager 99% of the software the world produces is some commerce software, where the only thing lost is money.
• ChrisMarshallNY 11mo ago
  I write full app suites that have less than 9000 LoC. I tend toward fewer, large-ish source files, separated by functional domains. I once had someone submit a patch (back in the SVN days), that was massive, and touched everything in my system. I applied it, and hundreds of bugs popped up. I politely declined it, but the submitter got butthurt, anyway. He put a lot of work into it.
• 999900000999 11mo ago
  Reject it and tell them to actually code it.
• le-mark 11mo ago
  How long was this person working on it? Six months? Anything this big should’ve had some sort of design review. The worst is some junior going off and coding some garbage no one sees for a month.
  • jonchurch_ 11mo ago
    You can churn this stuff out in about an hour these days though, seriously. Thats part of the problem, the asymmetry of time to create vs time to review. If I can write 8 9k line PRs everyday and open them against open source projects, even closing them let alone engaging with them in good faith is an incredible time drain vs the time investment to create them.
• jonchurch_ 11mo ago
  We are seeing a lot more drive by PRs in well known open source projects lately. Here is how I responded to a 1k line PR most recently before closing and locking. For context, it was (IMO) a well intentioned PR. It purported to implement a grab bag of perf improvements, caching of various code paths, and a clustering feature Edit: left out that the user got flamed by non contributors for their apparently AI generated PR and description (rude), in defense of which they did say they were using several AI tools to drive the work. : We have a performance working group which is the venue for discussing perf based work. Some of your ideas have come up in that venue, please go make issues there to discuss your ideas my 2 cents on AI output: these tools are very useful, please wield them in such a way that it respects the time of the human who will be reading your output. This is the longest PR description I have ever read and it does not sound like a human wrote it, nor does it sound like a PR description. The PR also does multiple unrelated things in a single 1k line changeset, which is a nonstarter without prior discussion. I don't doubt your intention is pure, ty for wanting to contribute. There are norms in open source which are hard to learn from the outside, idk how to fix that, but your efforts here deviate far enough from them in what I assume is naivety that it looks like spam.
  • jonchurch_ 11mo ago
    Daniel Stenberg of curl gave a talk about some of what theyve been experiencing, mostly on the security beg bounty side. A bit hyperbolic, and his opinion is clear from the title, but I think a lot of maintainers feel similarly. “AI Slop attacks on the curl project” https://youtu.be/6n2eDcRjSsk https://youtu.be/6n2eDcRjSsk
    • lkramer 11mo ago
      I think it's only fair to give an example where he feels AI is used correctly: https://mastodon.social/@bagder/115241241075258997 https://mastodon.social/@bagder/115241241075258997
      • jonchurch_ 11mo ago
        Wow very cool, theyve now closed 150 bugs identified via ai assistance/static analysis! For ref, here is the post from Joshua Rogers about their investigation into the tooling landscape which yielded those findings https://joshua.hu/llm-engineer-review-sast-security-ai-tools-pentesters https://joshua.hu/llm-engineer-review-sast-security-ai-tools...
• siwatanejo 11mo ago
  Forget about code for a second. This all depends a lot of what goal does the PR achieve? Does it align with the goals of the project?
  • appreciatorBus 11mo ago
    How can you tell if it aligns with the goals of the project without reviewing 9000 lines of code first?
    • ivanjermakov 11mo ago
      PRs rarely exist in a vacuum. Usually there is a ticket/issue/context which required a code change.
    • siwatanejo 11mo ago
      Are you kidding me? You should be able to explain from the user PoV what does the PR achieve, a new feature? a bugfix? That data point is waaaaaay more important than any other when considering if you should think about reviewing it or not.
      • wiseowise 11mo ago
        Okay, it does align. What next?
        • siwatanejo 11mo ago
          Ok great. Now that it aligns, how valuable it is? Is it a deadly & terrific feature? Then maybe you should review it. It's just fixing a nitpick? Then ask the contributor to find a less verbose change.
    • Cthulhu_ 11mo ago
      Read the title and description of the PR first. If that fails the sniff test, the code would as well.
• foxfired 11mo ago
  It's funny just today I published an article with the solution to this problem. If they don't bother writing the code, why should you bother reading it? Use an LLM to review it, and eventually approve it. Then of course, wait for the customer to complain, and feed the complaint back to the LLM. /s Large LLM generated PRs are not a solution. They just shift the problem to the next person in the chain.
  • throwawayffffas 11mo ago
    How do you know they didn't bother to write it? For all we know the submitter has been quietly hammering away at this for months.
    • foxfired 11mo ago
      The title says it is vibe-coded. By definition, it means they didn't write it.
      • throwawayffffas 11mo ago
        But how do they know it's vibe-coded? It may have a smell to it. But the author might not know it for a fact. The fact it's vibe-coded is actually irrelevant the size of the request is the main issue.
        • foxfired 11mo ago
          I'm not gonna make assumptions on behalf of OP, but if you have domain knowledge, you can quickly tell when a PR is vibe-coded. In a real world scenario, it would be pretty rare for someone to generate this much code in a single PR. And if they did in fact spend 6 months painstakingly building it, it wouldn't hurt to break it down into multiple PRs. There is just so much room for error reviewing such a giant PR.
        • sunaookami 11mo ago
          You can recognize it by the rocket emojis in the PR description ;)
• never_inline 11mo ago
  close button.
• ripped_britches 11mo ago
  Obviously by vibe reviewing it
• throwaway106382 11mo ago
  You don't. Was your project asking for all this? No? Reject.
• alexdowad 11mo ago
  Be tactful and kind, but straightforward about what you can't/don't want to spend time reviewing. "Thanks for the effort, but my time and energy is limited and I can't practically review this much code, so I'm closing this PR. We are interested in performance improvements, so you are welcome to pick out your #1 best idea for performance improvement, discuss it with the maintainers via ..., and then (possibly) open a focused PR which implements that improvement only."
  • ivanjermakov 11mo ago
    Depends on context of course, but in my book "my time and energy is limited" is not a valid reason for a reject. Get back once you have time, review in chunks.
    • wiseowise 11mo ago
      > is not a valid reason for a reject As a reviewer or as a submitter?
    • alexdowad 11mo ago
      ivanjermakov, I don't know if you are an open source maintainer or not (I am, for several projects). If you are, and you follow the policy that "I will never reject PRs because of having no time, I will always get to it eventually", then I salute you. That is a self-sacrificing, altruistic position to take. It's also a very difficult position to maintain for the long term. If you can do it: congratulations! As for me, my position is: "My project is my house. You want to be a guest in my house, you follow my rules. I really like people and am usually happy to answer questions from people who are reasonably polite, to review and provide feedback on their PRs, and so on. But I won't be pressured to prioritize your GitHub issue or PR over my work, my family, my friends, my health, or my personal goals in life. If you try to force me, I'll block you and there will be no further interaction." If you don't like that position, well, I understand your feelings.
      • ivanjermakov 11mo ago
        I'm absolutely with you on that. I'm not saying that every contribution deserves equal attention and that rejecting contributions is a bad/impolite thing. There has to be a better reason than "your PR is too big" as it's likely just a symptom, also very much context sensitive. If it is a 5kLOC PR that adds a compiler backend for a new architecture then it probably deserves attention because of its significance. But if it's obviously low quality code than my response would be that it is low quality code. Long story short, it's you (submitter) problem, not me (reviewer, BDFL) problem.
• exclipy 11mo ago
  I made a /split-commit prompt that automatically splits a megacommit into smaller commits. I've found this massively helpful for making more reviewable commits. You can either run this yourself or send this to your coworker to have them run it before asking you to re-review it. Sometimes it doesn't split it among optimal boundaries, but it's usually good enough to help. There's probably room for improvement and extension (eg. re-splitting a branch containing many not-logical commits, moving changes between commits, merging commits, ...) – contributions welcome! You can install it as a Claude Code plugin here: https://github.com/KevinWuWon/kww-claude-plugins https://github.com/KevinWuWon/kww-claude-plugins (or just copy out the prompt from the repo into your agent of choice)
• jeremyjh 11mo ago
  I'd just close it without comment. Or maybe if I'm feeling really generous I'll make a FAQ.md that gives a list of reasons why we'll close PRs without review or comment and link that in the close comments. I don't owe anyone any time on my open source projects. That said, I haven't had this issue yet.
  • tracerbulletx 11mo ago
    That's fine for an open source project, but many many companies are mandating AI use, they're putting it in performance reviews, they're buying massive Cursor subscriptions. You'd be cast as an obstructionist to AI's god like velocity ™.
    • jeremyjh 11mo ago
      Well in my case I'd just fire them if they opened a 9,000 LOC PR that they didn't understand.
• MikeNotThePope 11mo ago
  How about this? “This PR is really long and I’m having a hard time finding the energy to review it all. My brains gets full before I get to the end. Does it need to be this long?” Force them to make a case for it. Then see how they respond. I’d say good answers could include: - “I really trieeld to make it smaller, but I couldn’t think of a way, here’s why…” - “Now that I think about it, 95% of this code could be pushed into a separate library.” - “To be honest, I vibe coded this and I don’t understand all of it. When I try to make it smaller, I can’t find a way. Can we go through it together?”
• johnnyanmac 11mo ago
  excuse me, 9000? If that isn't mostly codegen, including some new plugin/API, or a fresh repository I'd reject it outright. LLM's or not. In my eyes, there really shouldn't be more than 2-3 "full" files worth of LOC for any given PR (which should aim to to address 1 task/bug each. If not, maybe 2-3 at most), and general wisdom is to aim to keep "full" files around 600 LOC each (For legacy code, this is obviously very flexible, if not infeasible. But it's a nice ideal to keep in mind). An 1800-2000 LOC PR is already pushing what I'd want to review, but I've reviewed a few like that when laying scaffolding for a new feature. Most PR's are usually a few dozen lines in 4-5 files each, so it's far below that. 9000 just raises so many red flags. Do they know what problem they are solving? Can they explain their solution approach? Give general architectual structure to their implementation? And all that is before asking the actual PR concerns of performance, halo effects, stakeholders, etc.
• throwawayffffas 11mo ago
  > How would you go about reviewing a PR like this? Depends on the context. Is this from: 1. A colleague in your workplace. You go "Hey ____, That's kind of a big PR, I am not sure I can review this in a reasonable time frame can you split it up to more manageable pieces? PS: Do we really need a DSL for this?" 2. A new contributor to your open source project. You go "Hey ____, Thanks for your interest in helping us develop X. Unfortunately we don't have the resources to go over such a large PR. If you are still interested in helping please consider taking a swing at one of our existing issues that can be found here." 3. A contributor you already know. You go "Hey I can't review this ___, its just too long. Can we break it up to smaller parts?" Regardless of the situation be honest, and point out you just can't review that long a PR.
  • MartijnHols 11mo ago
    Telling a new contributor no thank you is hard. Open source contributors are hard to come by, and so I’ve always dealt with PRs like this (albeit before AI days but from people who had never written a line of code before their PR) by leaving a message that it’s a huge PR so it’s going to take a while to review it and a request to make smaller PRs in the future. A couple of times I ended up leaving over a hundred review comments, but most times they were all fixed and the contributor stuck around with many better PRs later.
    • eru 11mo ago
      Git is flexible enough that you can tell people to break up their PR. They don't have to redo all their work. If you want to be really nice, you can even give them help in breaking up their PR.
      • Cthulhu_ 11mo ago
        Yeah exactly, the OP describes a completely new service built start to finish all in one merge request, where normally you'd start with a proposal and work from there.
        • 11mo ago
• bmitc 11mo ago
  Reject it and request the author makes it smaller. PRs should be under 1000 lines. The alternative is to sit down with them and ask what they're trying to accomplish and solve the problem from that angle.
• dosinga 11mo ago
  Ideally you have a document in place saying this is how we handle vibe coding, something like: if you have the AI write the first version, it is your responsibility to make it reviewable. The you can say (and this is hard), this looks like it is vibe code and misses that first human pass we want to see in these situations (link), please review and afterwards feel free to (re)submit. In my experience they'll go away. Or they come back with something that isn't cleaned up and you point out just one thing. Or sometimes! they actually come back with the right thing.
• dbgrman 11mo ago
  TBH, depends on what is being reviewed. Is it a prototype that might not see light of day and is only for proof-of-concept? Did an RFC doc precede it and reviewers are already familiar with the project? Were the authors expecting this PR? Was there a conversation before the PR was sent out? Was there any effort to have a conversation after the PR was shared? Was this even meant to be merged into main? I'll just assume good intent first of all. Second, 9000 LOC spanning 63 lines is not necessarily an AI generated code. It could be a code mod. It could be a prolific coder. It could be a lot of codegen'd code. Finally, the fact that someone is sending you 9000 LOC code hints that they find this OK, and this is an opportunity to align on your values. If you find it hard to review, tell them that I find it hard to review, I can't follow the narrative, its too risky, etc. etc. Code review is almost ALWAYS an opportunity to have a conversation.
• tayo42 11mo ago
  You can't really review this. Rubber stamp it or reject it.
• abhimanyue1998 11mo ago
  vibe review it with AI then run it on vibe production support. simple.
• throwaway290 11mo ago
  Don't accept this PR. If it's bot generated you are not here to review it. They can find a bot to review bot generated requests.
• deleted 11mo ago
  [deleted]
• EagnaIonat 11mo ago
  Everyone talking about having them break it down into smaller chunk. Vibe coding there is a near guarantee the person doesn't know what the code does either. That alone should be the reason to block it. But LLM generated code is not protected by law, and by extension you can damage your code base. My company does not allow LLM generated code into anything that is their IP. Generic stuff outside of IP is fine, but every piece has to flagged that it is created by an LLM. In short, these are just the next evolution of low quality PRs.
  • exe34 11mo ago
    > Everyone talking about having them break it down into smaller chunk. Vibe coding there is a near guarantee the person doesn't know what the code does either. that's the point though, if they can't do it, then you close the ticket and tell them to fork off.
    • EagnaIonat 11mo ago
      I agree, but you are potentially opening yourself up to 20+ PRs which are all vibe coded.
      • scott_w 11mo ago
        Copy and paste is your friend here. If there's 20+ huge PRs, just paste "This PR is far too large to review, please break it down and submit smaller PRs and engage with us ahead of time to understand how to solve this problem." Comment & Close PR, only engage in discussions on tickets or smaller, understandable PRs. As other have said: if someone drive-by opens a huge PR, it's as likely to be malware as a beneficial implementation.
      • exe34 11mo ago
        You can read one or two and decide if it's worth going through. Otherwise you can just reject them.
  • smsm42 11mo ago
    > Vibe coding there is a near guarantee the person doesn't know what the code does either. Accepting code into the project when only one person (the author) knows what it does is a very bad idea. That's why reviews exist. Accepting code that zero persons know what it does is sheer screaming insanity.
• userbinator 11mo ago
  If it's full of the typical vibe-coded nonsense that's easy to spot upon a quick-but-close inspection (unused functions, dead-end variables and paths that don't make sense, excessively verbose and inaccurate comments, etc.), I would immediately reject.
• ninetyninenine 11mo ago
  You vibe review it. I’m actually only half kidding here.
• andreygrehov 11mo ago
  That 10+ years old joke never gets old: 10 lines of code = 10 issues. 500 lines of code = "looks fine." Code reviews.
  • whynotmaybe 11mo ago
    I recently reached another milestone. +153675, -87954 : I don't care. Just taking time to read it will take longer than bondo fix the related bugs.
• wheelerwj 11mo ago
  The same way you do a non vibe coded pr. If its a shit pr, its a shit pr.
• wheelerwj 11mo ago
  The same way you review a non vibe coded pr. Whats that got to do with anything? A shit pr is a shit pr.
• aryehof 11mo ago
  This is effectively a product, not a feature (or bug). Ask the submitter how you can you determine if this meets functional and non-functional requirements, to start with?
• CamperBob2 11mo ago
  Please review this PR. Look carefully for bugs, security issues, and logical conflicts with existing code. Report 'Pass' if the PR is of sufficient quality or 'Fail' if you find any serious issues. In the latter case, generate a detailed report to pass along to the submitter. (ctrl-v)
• raincole 11mo ago
  You ask questions. Literally anything, like asking them why they believe this feature is needed, what their code does, why they made a DSL parser, etc. The question itself doesn't matter. Just ask something. If their answer is genuine and making sense you deal with it like a normal PR. If their answer is LLM-generated too then block.
  • deleted 11mo ago
    [deleted]
• ako 11mo ago
  AI code generators are getting better fast, in the near future they will be able to produce good changes faster than you can review. How will you deal with it then? Most vibe coding tools can also produce smaller PR, but then you have to deal with 250+ PRs in 1 week. Is that more manageable? My guess is we need new tool, get the human out of the loop. More automated reviews, tests, etc.
  • ako 11mo ago
    Instead of downvotes i would appreciate some insightful comments on this, as i'm currently struggling with this problem. In the last week i've vibe-code (vibe-engineered?) a typescript project with 230+ commits, 64 typescripts files, with 27k+ lines of code. Too much to actually read. Validation mostly through testing, automated test, architecture reviews (generate mermaid diagrams). I'm mostly reviewing the code structure and architecture, libraries it uses, etc. It has 600+ unit and integration tests, but even reviewing those is too much...
    • smsm42 11mo ago
      > In the last week i've vibe-code (vibe-engineered?) a typescript project with 230+ commits, 64 typescripts files, with 27k+ lines of code. Too much to actually read. Congratulations, you discovered that generating code is only part of software development process. If you don't understand what the code is actually doing, good luck maintaining it. If it's never reviewed, how do you know these tests even test anything? Because they say "test passed"? I can write you a script that prints "test passed" a billion times - would you believe it is a billion unit tests? If you didn't review them, you don't have tests. You have a pile of code that looks like tests. And "it takes too long to review" is not an excuse - it's like saying "it's too hard to make a car, so I just took a cardboard box, wrote FERRARI on it and sit inside it making car noises". Fine, but it's not a car. It's just pretending. If it's not properly verified, what you have is not tests, it's just pretending.
      • ako 11mo ago
        I’m well aware, thank you, have been coding for 40+ years (including 6502 and 68000 assembly), masters in computer science, have built healthcare software where bugs can lead to death. But with LLMs enabling us to generate source code faster, our review process is becoming an increasingly larger bottleneck for productivity. We need to start thinking how we can scale this process.
• viccis 11mo ago
  Open source? Close it and ask them resubmit a smaller one and justify the complexity of things like a DSL if they wanted it included. For work? Close it and remind them that their AI velocity doesn't save the company time if it takes me many hours (or even days depending on the complexity of the 9k lines) to review something intended to be merged into an important service. Ask them to resubmit a smaller one and justify the complexity of things like a DSL if they wanted it included. If my boss forces me to review it, then I do so and start quietly applying for new jobs where my job isn't to spend 10x (or 100x) more time reviewing code than my coworkers did "writing" it.
  • krackers 11mo ago
    > then I do so and start quietly applying In this job market? And where pretty much every company seems to be following the top-down push for AI-driven "velocity"?
    • nextlevelwizard 11mo ago
      When you are applying from a job you are more desirable and you aren't desperate so you can take your pick. If your current job is bad then you can't really lose much. Otherwise you need to be the person at the company who cuts through the bullshit and saves it from when the VibeCodeTechDebt is popping the industry.
    • viccis 11mo ago
      That's why I would start applying instead of just quitting. There are plenty of companies that use AI responsibly or not much at all.
      • xeonmc 11mo ago
        This is why we need a programmer union, so that coders can collectively reject reverse-centaur slopwork, like miners rejecting asbestos mines or workers refusing to fix dangerous machines while it’s running.
        • 11mo ago
• atoav 11mo ago
  Tell them to give you a phone call and have them explain the code to you : )
• fathermarz 11mo ago
  Let me ask a different question. Large refactor that ended up in a 60K line python PR because the new lead didn’t feel like merging it in until it was basically done. Even ask other devs to merge into his branch and then we would merge later. How does one handle that with tact and not lose their minds?
  • JonChesterfield 11mo ago
    Refuse to merge into their branch. If you have serious test coverage and the refactor doesn't change behaviour, it'll be fine. If you don't have test coverage, or if the "refactor" is also changing behaviour, that project is probably dead. Make sure there's a copy of the codebase from before the new lead joined so there's a damage mitigation roll back option available.
  • wiseowise 11mo ago
    You get Leetcode subscription and start going through paths for a company that can match or exceed your salary.
• sshine 11mo ago
  Same standard as if they had made it themselves: a sequence of logically ordered commits.
• anarticle 11mo ago
  No face, no case. They have to break it way down, just like at any org. In fact, I would ask for more tests than usual with a test plan/proof they passed. 9k is a little spicy, separate PRs, or an ad hoc huddle with them rubber ducking you through the code. Depends on if you care about this that much or not. Unless you really trust them, it's up to the contributor to make their reasoning work for the target. Else, they are free to fork it if it's open source :). I am a believer in using llm codegen as a ride along expert, but it definitely triggers my desire to over test software. I treat most codegen as the most junior coder had written it, and set up guardrails against as many things llm and I can come up with.
• T_Potato 11mo ago
  I have a tangent question: How do you deal with a team that spends days nitpicking implementation, double-speak and saying. I didn't actually expect you to implement this the way I said, I was just saying it would be nice if it was like this, can you undo it. I spend 3 weeks on a code review because of the constant back and forth; and I wish oh I wish they would allow PR to be small but the rule is that the PR has to implement the full deliverable feature. And that can mean 20 files to constantly change and change and change and change. Oh and then the why did you use Lombok question that occurs even though the project uses lombok and so you are stuck defending the use of a library that's is used in the project for no random reason than to flatter the egos of the gatekeepers who say, yes this is good but I want you to name this abc instead of ab before we merge. When in context it doesn't add or remove any value, not even clarity.
  • dbetteridge 11mo ago
    Doesn't help you much I imagine, but the one time we had a dev like this he was fired after multiple complaints to the team lead.
  • tjansen 11mo ago
    Generally, my stance is that I add more value by doing whatever ridiculous thing people ask me to change than waste my time arguing about it. There are some obvious exceptions, like when the suggestions don't work or make the codebase significantly worse. But other than that, I do whatever people suggest, to save my time, their time, and deliver faster. And often, once you're done with their initial suggestions, people just approve. This doesn't help all the time. There are those people who still keep finding things they want you to change a week after they first reviewed the code. I try to avoid including them in the code review. The alternative is to talk to your manager about making some rules, like giving reviewers only a day or two to review new code. It's easy to argue for that because those late comments really hinder productivity.
• cat_plus_plus 11mo ago
  Vibe review with all the reasons it should not be merged obviously.
• Roark66 11mo ago
  Many people gave good tips, so let me answer in general. As someone on the "senior" side AI has been very helpful in speeding up my work. As I work with many languages, many projects I haven't touched in months and while my code is relatively simple the underlying architecture is rather complex. So where I do use AI my prompts are very detailed. Often I spot mistakes that get corrected etc. With this I still see a big speedup (at least 2x,often more). The quality is almost the same. However, I noticed many "team leads" try to use the AI as an excuse to push too difficult tasks onto "junior" people. The situation described by the OP is what happens sometimes. Then when I go to the person and ask for some weird thing they are doing I get "I don't know, copilot told me"... Many times I tried to gently steer such AI users towards using it as a learning tool. "Ask it to explain to you things you don't understand" "Ask questions about why something is written this way" and so on. Not once I saw it used like this. But this is not everyone. Some people have this skill which lets them get a lot more out of pair programming and AI. I had a couple trainees in the current team 2 years ago that were great at this. This way as "pre-AI" in this company, but when I was asked to help them they were asking various questions and 6 months later they were hired on permanent basis. Contrast this with: - "so how should I change this code"? - You give them a fragment, they go put it in verbatim and come back via teams with a screenshot of an error message... Basically expecting you will do the task for them. Not a single question. No increased ability to do it on their own. This is how they try to use AI as well. And it's a huge time waster.
  • randomNumber7 11mo ago
    You can lead a horse to water, but you can’t make it drink. Also people with that mentality had been a waste of time before AI too.
• ojr 11mo ago
  I would test if the new features work and if there is any regressions around critical business functions and merge it, if my manual tests pass.
• locknitpicker 11mo ago
  > How would you go about reviewing a PR like this? State the PR is too large to be reviewed, and ask the author to break it down into self-contained units. Also, ask which functional requirements the PR is addressing. Ask for a PR walkthrough meeting to have the PR author explain in detail to an audience what they did and what they hope to achieve. Establish max diff size for PRs to avoid this mess.
• huflungdung 11mo ago
  [dead]
• exe34 11mo ago
  simple, ask them to break it down into smaller pieces with clear explanation of what it does and why it's needed. Then set up an AI to drag them in the dirt with pointless fixes. or just close them as won't-fix.
• LaFolle 11mo ago
  There are good suggestions in the thread. One suggestion that possibly is not covered is that you/we can document clearly how AI generated PRs will be handled, make it easy for contributors to discover it and if/when such PR shows up refer the documented section to save yourself time.
• rhubarbtree 11mo ago
  In our company, you would immediately reject the PR based on size. There are a bunch of other quick bounce items it could also fail on, eg documentation. The PR would then be split into small ones up to 400 lines long. In truth, such a big PR is an indicator that either (a) the original code is a complete mess and needs reengineering or more likely (b) the PR is vibe coded and is making lots of very poor engineering decisions and goes in the bin. We don’t use AI agents for coding. They’re not ready. Autocomplete is fine. Agents don’t reason like engineers, they make crap PRs.
  • ethin 11mo ago
    This! And vibe-coded solutions usually will implement stuff your project already has in it, instead of reusing what already exists. Or Claude will massively over-engineer something that could be collapsed to 30 lines or something.
    • Cthulhu_ 11mo ago
      Can confirm, I asked it to write a unit test for a small component, it wrote tons of code that parsed and validated some JSON configuration (a theme file) instead of just the unit under test. I just wrote it myself instead of try and argue with it. Maybe the AI was too clever for its own good? Have AI coding assistants evolved from junior (naive but alright) to medior (overly complicated and complete)?
• est 11mo ago
  write another AI to hardcore review it and eventually reject it.
• PeterStuer 11mo ago
  Before review ask for a rational and justification. Might be just overcomplicated AI slop, could also be someone actually went beyond the basics and realy produced something next level. A simple email could tell the difference.
• ugh123 11mo ago
  Are there tests written? You could start by demanding tests pass and demonstrate some kind of coverage metric.
• sherinjosephroy 11mo ago
  [dead]
• O-stevns 11mo ago
  That's a lot of code for a PR, though i should admit I have made PR's being half that size myself. Personally I think it's difficult to address these kinds of PR's but I also think that git is terrible at providing solutions to this problem. The concept of stacked PR's are fine up to the point where you need to make changes throughout all yours branches, then it becomes a mess. If you (like me) might have a tendency to rewrite your solution several times before ending up with the final result, then having to split this into several PR's does not help anyone. The first PR will likely be outdated the moment I begin working on the next. Open source is also more difficult in this case because contrary to working for a company with a schedule, deadlines etc... you can't (well you shouldn't) rush a review when it's on your own time. As such PR's can sit for weeks or months without being addressed. When you eventually need to reply to comments about how, why etc.. you have forgotten most of it and needs to read the code yourself to re-claim the reasoning. At that time it might be easier to re-read a 9000 lines PR over time rather than reading 5-10 PR's with maybe meaningful descriptions and outcome where the implementation changes every time. Also, if it's from a new contributor, I wouldn't accept such a PR, vibe coded or not.
• mort96 11mo ago
  Close them.
• occz 11mo ago
  Easy, you reject it.
• smsm42 11mo ago
  The only way such a PR can be reviewed is if it's accompanied with a detailed PRD and tech design documents, and at least half of that LOC count is tests. Even then it requires a lot of interactive work from both sides. I have seen PRs third or quarter of this size that took weeks to properly review and bring to production quality. Unless there's something artificially inflating the side of it (like auto-generated files or massive test fixtures, etc.) I wouldn't ever commit to reviewing such a behemoth without a very very good reason to.
• renewiltord 11mo ago
  It's basic engineering principle: you do not do work amplification. e.g. debouncing, request coalescing, back-pressure are all techniques to prevent user from making server do lots of work in response to small user effort. As example, you have made summarization app. User is try to upload 1 TB file. What you do? Reject request. You have made summarization app. User is try upload 1 byte file 1000 times. What you do? Reject request. However, this is for accidental or misconfigured user. What if you have malicious user? There are many technique for this as well: hell-ban, tarpit, limp. For hell-ban simply do not handle request. It appear to be handled but is not. For tarpit, raise request maker difficulty. e.g. put Claude Code with Github MCP on case, give broad instructions to be very specific and request concise code and split etc. etc. then put subsequent PRs also into CC with Github MCP. For limp, provide comment slow using machine. Assuming you're not working with such person. If working with such person, email boss and request they be fired. For good of org, you must kill the demon.
• calini 11mo ago
  Vibe merge review it using Copilot or equivalent, and then close it :)
  • cryptonym 11mo ago
    Prompt: be over cautious on every code line, this is junior code and they can learn a lot from this PR. Generate many comments on why it shouldn't be merged as-is and make sure every corner case is covered. Be super paranoid, mistakes in the code could hurt the company or people. If you are lucky, they will also vibe fix it.
• lionkor 11mo ago
  Close them and report to your boss. If your boss doesn't care, look for a new job. Once you have a new job, quit the old and cite that specific case as the reason.
• shinycode 11mo ago
  Don’t read it, approve it.
• hsbauauvhabzb 11mo ago
  “Hey chatgpt, reject this pr for me. Be extremely verbose about the following topics: - Large prs - vibe coding - development quality”
  • wiseowise 11mo ago
    Finally, an advice from 10x AI engineer.
• ares623 11mo ago
  Ask them if they reviewed the AI’s output before opening the PR. If they didn’t then ask them to at least review it first rather than having you do all the work. If they did then is a 2nd review from you really necessary? ;)
• ethin 11mo ago
  If it's obviously AI generated and is an absurdly long PR, I'd ask them to extensively justify the complexity (especially if it does side quest-isms like this example where the AI created a DSL and stuff: why exactly is the DSL required?). If the project already implements the feature, I'd ask that they remove the re-implemented parts and use what already exists. If one of the dependencies of the project does this, I'd ask that they update the PR to use those instead of wholesale redoing it. If they respond, at all, with AI-generated responses instead of doing it themselves, or their PR description is AI generated, or it's blatantly obvious they used AI, I would immediately mentally classify the PR as an ultra low effort/quality PR until proven otherwise. Might seem harsh, but I prefer PRs from people who actually both understand the project and what the PR is trying to do. I don't mind if people use AI to assist in that understanding; I don't even mind if they use AI to help write parts of the PR. But if I can tell that it's AI generated (and completely re-implementing something that the project either has already or is in the stdlib or a dep is a very good sign of AI generated code in my experience), I'm far more inclined to dismiss it out of hand.
• ZeroGravitas 11mo ago
  How you reject the first one of these, compared with the hundretth and the millionth(!) is probably going to be an interesting development over next few years. Personally, I've felt drained dealing with small PRs fixing actual bugs by enthusiastic students new to projects in the pre-slop era. Particularly if I felt they were doing it more to say they'd done it, rather than to help the project. I imagine that motive might help drive an increase in this kind of thing.
• ivankahl 11mo ago
  What are your organization's expectations or policies regarding PR size and acceptable AI usage? Even if your organization hasn't set any expectations, what are yours—and have you communicated them to the author? If expectations have been shared and these changes contradict them, you can quickly close the PR, explain why it's not acceptable, and ask them to redo it. If you don't have clear guidelines on AI usage or haven't shared your expectations, you'll need to review the PR more carefully. First, verify whether your assumption that it’s a simple service is accurate (although from your description, it sounds like it is). If it is, talk to the author and point out that it's more complicated than necessary. You can also ask if they used AI and warn them about the complexities it can introduce.
• grodriguez100 11mo ago
  Don’t. I would refuse to review a PR with 9000 LOC and 63 new files even if written by a human. Something that large needs to be discussed first to agree on an architecture and general approach, then split in manageable pieces and merged piece-wise in a feature branch, with each individual PR having reasonable test coverage, and finally the feature branch merged into master.
• bluerooibos 11mo ago
  I wouldn't review it - bad engineering practice to submit this much work in one go - it puts too much expectation on the reviewer and makes it more likely that something gets broken. Even 1000 lines is pushing it, IMO. Tell them to split the PR up into more granular work if they want it merged.
• fxtentacle 11mo ago
  „I trust you that you have proof-read this“ and then just merge. When production explodes, their name will be all over „git blame“.
• sanskarix 11mo ago
  [dead]
• Cthulhu_ 11mo ago
  I wouldn't, they can start by writing requirements and a design first, then break it up into manageable components. Or just refuse to review and let the author take full responsibility in running and maintaining the thing, if that's possible. A PR is asking someone else to share responsibility in the thing.
• onion2k 11mo ago
  How would you go about reviewing a PR like this? AI is red herring in discussions like this. How the change was authored makes no difference here. I wouldn't. I'd reject it. I'd reject it even if the author had lovingly crafted each line by hand. A change request is not "someone must check my work". It's a collaboration between an author and a reviewer. If the author is failing to bother respecting the reviewer's time then they don't deserve to get a review.
• phendrenad2 11mo ago
  Are they truly vibe-coded? Or is the person simply accomplishing months of work in one day? Do you think the submitter reviewed it themselves? There's a difference you know. Like it or not, AI coding is not going away. In your case, 9000 LOC and 63 files isn't that crazy for a DSL. Does the DSL serve a purpose? Or is it just someone's feature fever dream to put your project on their resume?
• Lapsa 11mo ago
  strict lines of code limitation enforcement will lead to half-finished change requests and leak technological gibberish upstream to lovely business folk
• alganet 11mo ago
  "too big, please break it into smaller self-contained PRs" [ Close with comment ]
• sanskarix 11mo ago
  [dead]
• deleted 11mo ago
  [deleted]
• fifilura 11mo ago
  Is it Java/Spring? Then probably go along and be happy that a human didn't have to write those 9000 lines for a trivial service.
  • Cthulhu_ 11mo ago
    Man I'd hate it even more then. If I ever get back to Java I hope this nonsense has been resolved. I've been spoiled by Go where they're a lot more pragmatic about things. I want to add a brouhaha about code volume but it's compared with Java so never mind.
• fhd2 11mo ago
  I'd say you have three options: 1. Reject it on the grounds of being too large to meaningfully review. Whether they used AI or not, this is effectively asking them to start over in an iterative process where you review every version of the thing and get to keep complexity in check. You'll need the right power and/or standing for this to be a reasonable option. At many organisations, you'd get into trouble for it as "blocking progress". If the people that pay you don't value reliability or maintainability, and you couldn't convince them that they should, that's a tough one, but it is how it is. 2. Actually review it in good faith: Takes a ton of time for large, over engineered changes, but as the reviewer, it is usually your job to understand the code and take on responsibility for it. You could propose to help out by addressing any issues you find yourself rather than making them do it, they might like that. This feels like a compromise, but you could still be seen as the person "blocking progress", despite, from my perspective, biting the bullet here. 3. Accept it without understanding it. For this you could _test_ it and give feedback on the behaviour, but you'd ignore the architecture, maintainability etc. You could still collaboratively improve it after it goes live. I've seen this happen to big (non-AI generated) PRs a lot. It's not always a bad thing. It might not be good code, but it could well be good business regardless. Now, however you resolve it, it seems like this won't be the last time you'll struggle to work with that person. Can, and do they want to, change? Do you want to change? If you can't answer either of these questions with a yes, you'll probably want to look for ways of not working with them going forward.
• dustingetz 11mo ago
  zoom call ask them to walk you through it ask for design doc if appropriate what is test plan who is responsible for prod delivery and support (no difference from any other large pr)
• arianjm 11mo ago
  It always depends on your position and their position, but by the sounds of it... I'd say it's too big for a simple "review this". I'd ask for them to write their thought process, why they made the decisions they made, what the need for so many files and so many changes. I may ask for a videoconference to understand better, if it's a collegue from work. By now hopefully you should know if their approach is valid or not really. If not sure yet, then I'd take a look at the code, specially at the parts they refer to most importantly in their answer to my previous questions. So not a detailed review, a more general approach, to decide if this is valid or not. If it's a valid approach, then I guess I'd review it. If not, then give feedback as to how to make it valid, and why it isn't. Not valid is very subjective. From "this is just garbage", to "this is a good approach, but we can implement this iteratively in separate PRs that will make my life easier", again, it depends on your and their position.
• mexicocitinluez 11mo ago
  The same way you would do literally any other PR. I don't know why this is special. If the code sucks, reject it. If it doesn't, accept it. This isn't hard.
• reactordev 11mo ago
  Easy, auto reject and close it. If asked why, state that each feature should be its own PR. Don’t waste any more brain cells on it. If an engineer really cared, they would discuss these changes with you. Each new feature would be added incrementally and ensuring that it doesn’t break the rest of the system. This will allow you to understand their end goal while giving them an avenue to achieve it without disrupting your end goal.
• brutal_chaos_ 11mo ago
  Having experienced AI at $job and having tried to make vibecodong a thing, run when you see it. Yes, that means good enough AI gets through, what's the harm in that if it works as you need it to?
• pomarie 11mo ago
  One thing that actually works is getting AI to review the basic stuff first so you can focus on architecture and design decisions. The irony of using AI to review AI-generated code isn't lost on me, but it does help. That said, even with automated review, a 9000 line PR is still a hard reject. The real issue is that the submitter probably doesn't understand the code either. Ask them to walk you through it or break it down into smaller pieces. If they can't, that tells you everything. The asymmetry is brutal though. Takes an hour to generate 9000 lines, takes days to review it properly. We need better tooling to handle this imbalance. (Biased take: I'm building cubic.dev to help with this exact problem. Teams like n8n and Resend use it to catch issues automatically so reviewers can focus on what matters. But the human review is still essential.)
• giantg2 11mo ago
  Start with the test files. There's no way the AI had meaningful and working test cases. Pop a comment on each test file about missing tests or expanding them. That will force the dev to review their own code and make substantial changes.
• meltyness 11mo ago
  Proof by counterexample, just find the inevitable security flaw.
• Yizahi 11mo ago
  Alternative to the reject and request rewrite approach, which may not work in the corporation environment. You schedule a really long video call with the offending person, with the agenda politely describing that for such a huge and extensive change, a collaborative meeting is required. You then notify your lead that new huge task has arrived which will take X hours from you, so if he wishes to re-prioritize tasks, he is welcome. And then if the meeting happen, you literally go line by line, demanding that author explain them to you. And if explanation or a meeting are refused, you can reject RP with a clear explanation why.
  • Msurrow 11mo ago
    See, now that’s a proper f** you in corporate-speak.
  • watwut 11mo ago
    Sir, I see a big senior manager future in you. My hats down.
  • a4isms 11mo ago
    This is the answer, and it has been the answer going back to the before times when we didn't have pull requests but we did in-person team code reviews before merging branches (yes, really). A massive, complicated merge without documentation and extensive support from other interested/impacted people and teams justifying things like a parser DSL? That is always going to be a problem whether AI generated it or the developer locked their office door and went on a three-day manic coding binge. AI doesn't directly make this stuff worse, it accelerates a team's journey towards embracing engineering practices around the code being written by humans or LLMs.
    • djmips 11mo ago
      we still do this on very big fundamental changes.
  • iamleppert 11mo ago
    Oh, how I would love to work with you. I'd drown you in more meetings, documentation on code (LLM generated of course) than you could ever imagine. You can use the LLM to generate as much documentation on the changes as you want. Just give it your PR. If someone tries to reject your vibe coded AI slop, just generate more slop documentation to drown them in it. It works every time. If they push back, report them to their manager for not being "AI first" and a team player.
• james_marks 11mo ago
  “This is unnecessarily complex” and cite 1-2 egregious examples, with a LOC estimate that you think is more reasonable. 5 minutes, off the cuff.
• 0x000xca0xfe 11mo ago
  Fight slop with slop. Use an AI to review it in excruciating detail and write a lenghty justification for the rejection. Make sure to really hit a couple thousand words. Maybe getting their own time wasted will teach the submitter about the value of clarity and how it feels to be on the receiving end of a communication with highly asymmetric effort.
  • chuckadams 11mo ago
    Nice, but I suspect the PR submitter will simply reply with their own AI-generated counterpoints. They'll probably come to an agreement to turn both of you into paperclips.
    • 0x000xca0xfe 11mo ago
      If they resubmit you at least have proof that the conversation is completely braindead and the other side is happy to engage in uprofessional behavior and generally wasting time and resources. This should be convincing enough even for a non-technical team lead while for the initial PR it might be hard to explain objectively why it's bad.
• drfrank3 11mo ago
  AI creates slop of dead or inefficient code that can be cleaned up. I think that developers that obsess over control have a difficult time adjusting to this. The greater danger is that AI can create or modify code into something that is disconnected, stubbed, and/or deceptive and claim it’s complete. This is much worse because it wastes much more time, but AI can fix this too, just like it can the slop- maybe not deterministically, but it can. And because of this, those that get in the way of creating source with AI are just cavemen rejecting fire.
• zzzeek 11mo ago
  It's garbage, reject it. Over engineered. Update your PR guidelines that AI is fine to help write code but PRs have to be ultimately human designed.
• HelloNurse 11mo ago
  Complaining about inadequate tests and documentation should be a very efficient and effective strategy against slop.
• fancyfredbot 11mo ago
  If it shouldn't be 90k LOC, and it doesn't need a DSL parser then reject it as overcomplicated and unmaintainable. Make it clear how large and complex you expect it to be and where existing code or framework should be reused so they can go away and address your concerns and so that there's a high chance you'll be able to approve if they do. Above all, you aim to allow the contributor to be productive, you make it clear what constraints they need to operate under in order to use AI codegen effectively. You want to come across as trying to help them and need to take care not to appear obstructive or dismissive.
• dlisboa 11mo ago
  Close them. It's not a PR in good faith. A pull-request is meant to be reviewable, 9k LOC is not.
• ontouchstart 11mo ago
  A more difficult question might be if it were merged now and 100 merges later you found a serious bug with a root cause in this PR, do you ask the same person to fix it?
• self_awareness 11mo ago
  Reject, with unnecessary technical debt reason. Most of the times custom DSLs are not needed. The question is what was the original task that needed to be fixed? I doubt it required a custom DSL. Issue a research task first to design the scope of the fix, what needs to be changed and how.
• javier_e06 11mo ago
  I would request in the PR references to the unit test with 100% coverage. Once I run it and if it passes I would do a spot check and look for glaring errors. Nothing deep. Perhaps I would run lint or some static analysis tool on the code. If the analysis tools come out squeaky clean and the unit test passes? Well, what's not to like? One or more problems? Reject the whole thing.
  • thinkingtoilet 11mo ago
    The problem is you can get a very large, messy, and inconsistent code base that eventually will slow things down. Even if tests pass, the code can be a detriment in the long run.
  • data-ottawa 11mo ago
    I don’t like the 100% test coverage approach. The PR will be huge, plus AI is great at adding tons of shallow tests. I see tests as little pins that hold your codebase down. They can be great for overall stability, but too many and your project becomes inflexible and brittle. In this case you’d be nailing a bunch of code that you don’t want to the code base.
• dzink 11mo ago
  With AI code complexity is a cost bigger than money. Because it takes infinite amount of time from humans (maintainers, engineers) and requires increasing amount of memory and hardware to handle (unnecessarily) you have to account for it and hold contributors accountable for it. Otherwise any code will become unmanageable and un-runable and un-upgradable.
• ErroneousBosh 11mo ago
  Instant reject, advising them not to resubmit.
• jake-coworker 11mo ago
  I usually share this resource when people start doing this https://google.github.io/eng-practices/review/developer/small-cls.html https://google.github.io/eng-practices/review/developer/smal...
  • claar 11mo ago
    Apparently "CL" is "Change List", Google speak for a Pull Request, if anyone else was confused like I was.
• drbojingle 11mo ago
  If they can vibe code it they can vibe disassemble it and vibe small PR it.
• _jplc 11mo ago
  Reject them
• dearilos 11mo ago
  Put up guardrails to enforce quality code.
• bitbasher 11mo ago
  "CoS" - Close on Sight
• ilc 11mo ago
  The same way I would with a human: If I thought the service should only be 1000 lines tops: - Reject due to excess complexity. If it is a proper solution: - Use AI to review it, asking it to be VERY critical of the code, and look for spots where human review may be needed, architecture wise, design wise and implementation wise. - Ask the AI again to do a security review etc. - Tell the author to break the PR down into human size chunks using git. Why those things? It's likely some manager is gonna tell me review it anyways. And if so, I want to have a head start, and if there's critical shoot down level issues I can find with an AI quickly. I'd just shut the PR down now. As in any "security" situation, in this case the security of your codebase and sanity, defense in depth is the answer.
• paul_h 11mo ago
  Ask AI number 2 to summarize the intention (look at the .patch) to markdown. Reset. Ask you AI to read the intention as of the orig author had written it, and say you've grave doubts about the contrib's functionally and non-functionally and for it to help you put that into words to feel back to the contributor. Basically the playbook from https://paulhammant.com/images/SimonSinghsFermatExcerpt.jpg https://paulhammant.com/images/SimonSinghsFermatExcerpt.jpg
• irvingprime 11mo ago
  Reject. Period. No compromise. No friendly comments about how it can be improved. Just reject it as unreviewable. Then ban the idiot who submitted it.
• pacifika 11mo ago
  Roughly takes an hour to review 1000 loc. tell your manager to book you in for a day and a half on the review. Usually scheduling it in is a deterrent for a quick approval
• nish__ 11mo ago
  Build it locally and QA test it.
• NumberCruncher 11mo ago
  Why not fighting fire with fire and using AI to: Version A: find 100 LOC which can be reduced to 50 LOC without changing the functionality. Then ask the author to go through the PR making sure it's not bloated. Repeat. Version B: find hidden bugs. Ask the author to fix them. Repeat. Keep them occupied saving your face. I would also fine tune an own agent to automatise this kind of work for me.
• jasonjmcghee 11mo ago
  That's unreasonably large. Depending on the content, PRs tend to get harder and harder to read with every line of code. 1k added lines is imo already pushing it. 9k and 63 files is astronomical and very difficult to review. A proper review means being able to understand the system and what's being changed, how, and why in order to be able to judge if it was done properly and includes everything it should and nothing it shouldn't. 9k lines is just too much to be able to do this properly.
• EdwardDiego 11mo ago
  I wrote a lot of comments - for humans, but then I also specifically addressed some to the bot - "Cursor, remove all emojis in log messages, and do not use print for debugging, use a logger, where you are using a logger you are repeatedly importing the logging library in various conditional clauses, you should always import at the top level of the file" etc. etc. etc. - because you know that they're going to feed my review back to the bot. The fact that someone submitted this PR in that state though...
• thw_9a83c 11mo ago
  > How to deal with long vibe-coded PRs? This is partly a joke, but it works: Rewrite your project in an obscure, unpopular, uncool programming language, that LLMs cannot use to meaningfully write code. You will get zero vibe-coded PRs and you will remain in a full control over your source code.
• collingreen 11mo ago
  My gut says close it. My more professional side says invite the person to review it together - I do this for big or confusing PRs regardless of AI and it is both helpful and a natural backpressure to big PRs. My tactical side says invite the person to show you their ai process because wow that's a lot of code that's super cool if it's good enough and then see if the AI can turn the PR into small, coherent, atomic chunks (rewritten with some arch learned from the existing project) and leave the person with those prompts and workflows. My manager side already is very explicit with the team that code review is the bottleneck AND the code both working and being easy to understand is the authors responsibility, which makes these conversations much much easier.
• cyrusradfar 11mo ago
  Trigger: Shameful Self Promotion I created a tool in VSCode for this called Intraview. It allows you to create a dynamic code tour to provide feedback. It works with your existing agent and creates a sharable tour that you can navigate and provide feedback step by step. Rationally, this is much easier than reviewing the diff, because you can prompt to break up the PR logically so you can approve in functional pieces.
• rurban 11mo ago
  I just came back from installing a vibe coded new service and frontend. It had most of the new required features the old python single file service didn't have. A new big shiny react typescript monster. Good UI. The client would have loved be use it, as it was much easier to use. But in the end it was premature, not tested, and not adjustable to the client needs on-site. Too many states, even a global postgresql store. Super fragile. So I had to sidestep the new shiny Claude generated react code, after 2 people tried to fix it for 3 weeks, implemented the basic new features on the old system in a day, and this works stable now. No global state, just a single job file you copy there manually. Enforce good SW practises. Test that it works. Have a backup solution ready if it doesn't work. Have simulators to test real behaviors. My simulators saved my day.
• darepublic 11mo ago
  > a DSL parser oh no
• flambojones 11mo ago
  Sounds like an opportunity for the person who sent it to learn to improve their prompts. I've set my default claude rules to emphasize doing small-contained commits and use a stacking tool like Graphite to help them get reviewed.