And the exact same things you would need to safely give up on PRs for human developers (auto-formatters, linters, comprehensive end-to-end tests, continuous deployment pipelines, etc), are also things that place meaningful guardrails on LLMs, and help them maintain a reasonable quality bar.

I would always feel bad in those cases, because it's clear they spent a lot of time, and I'm going to have to say "no" and they will feel like they wasted a ton of effort.

The thought process around this has started shifting for me in the last few weeks. I'm a lot more comfortable saying "no" with a list of concerns when I suspect the code is AI-generated, and I see others doing the same. CLs that would be sitting around for days because no one wants to be the first to say, "this is bad, don't do this" now get quicker feedback.

The good thing is this feedback doesn't feel like as big a deal as it used to because people are less personally attached to code they generated in 30 minutes vs. code they hand crafted over a week. I had at least 2 LLM-generated PRs that were complete, correct, tested, and pre-reviewed by me, but I got feedback that they were going in the wrong direction. This would have been 8 hours of wasted effort a year ago, but now it's just an extra 30 minutes to rework the direction with LLM assistance.

Run several rounds of such reviews until the clanker fails to find problems.

I've been thinking about this in art. Is it the end result that matters, or the process of creating it?

I once saw a hideous sculpture. Didn't like it at all. Then the video zoomed and I saw that the whole thing (quite massive) had been hand-built out of individual toothpicks, and suddenly I thought it was amazing.

Perhaps an even better example: I read a story of a man in india who carved a passage through a mountain, so there would be a shorter route from his remote village to the city. He did it by hand and it took him 20 years. We seem to have an instinctive admiration for heroic effort.

In business, generally only the end result matters. Although, the end result also includes the client's perception of how the product was made... (see also: fake fairtrade etc.) In a meaningful way, the perception, the story, is reality.

I wonder if that's occurred to him.

This was true long before AI. With AI the difference is just a lot bigger. It exposes team inefficiencies quite mercilessly. We have a big glaring issue with the current AI tools not being to suitable for usage by multiple users. All interactions are one on one. Which means hand offs between tools and people are bottle necked on people communicating with each other. So, any issues there with people delaying, gate keeping, etc. become very visible.

The sentiment of pushing back on AI is understandable but probably not a productive reflex. We need to find more effective ways on staying on top of massive amounts of changes. It's not going to slow down and insisting on manually reviewing all code is not going to be a long term sustainable way of developing software. It simply does not scale. I'd question the added value of manual PR reviews at this point. Are they finding real issues? Are we valuing those issues correctly? Could we come up with automated ways to find and fix those same issues? There are a lot of open questions about how we are going to do this. But no question about the notion that we need to up our game on this front.

I get this feeling, too. I do however think the onus is on the developer to make something reviewable by their team members if they want a speedy review. Stacked PRs, scoping things down, properly structuring commits so you can review commit-by-commit for example.

I also think that "I spent a bunch of time on this" is not a valid reason for expecting an approval. It should hurt if you've produced a bunch of code that is way off target, even if it ends up implementing the feature. That's how I learned at least.

A proper way to go about large projects, in my opinion, is the same as with software development at large. Fail fast if possible. Draw up a crude boxes and arrows sketch or just discuss how you want the code to integrate with whatever already exists and invite the team to comment. If no one has anything to say, well then they can't complain later when you implement that approach. But if anyone cares then most likely valueable input will come that makes the end result better.

Like : Here is the ticket, this was the goal. I set out by beginning here- but encountered problems x y z I then refactored to accomplish. Finally..

You just dont drop a blob from orbit.

Ironically, ai could generate that quite well from existing documentation (ticket, tasks and prompts) + https://marketplace.visualstudio.com/items?itemName=vsls-con....

Because the problems AI causes are fundamentally problems of good design. It has the same problems of large teams, but less politics. Do your design well ahead of time, and AI review, or a large team, will amplify what you can do. Potentially by a lot.

Do it badly (or like most companies: do it with bad knowledge of the problem or just don't do it at all) and both team and AI will make a mess of things. If the team is made up of inexperienced programmers, they won't even complain, in fact I've seen teams that like this to be happening. At least in AI reviews I've always seen "grumbling" (in the sense of what you might call mean comments)

If a human put some effort into it, that's a signal.

I think this comment misses the point. Let's forget about AI and assume that there are three developers: A, B, and C. Now, A is supposed to make a PR, but instead they describe it to B, and B writes the code. C reviews the PR and gives feedback. A passes the feedback and the responses between B and C.

As you see, this is not easy for either B or C, and A is totally useless in this scenario. When you replace B with an LLM that doesn't get tired or bored, only C complains about the process.

One of the main reasons that art is valuable is in its ability to communicate emotions. Good art has the ability to serialize emotions within the artist and deserialize them within the mind of the viewer. It's not just "wow, this is a pretty picture", it's "wow, this is how another person sees the world, and now that I understand that, I feel an intimate connection with them".

On top of that, we have been running multi-model AI reviews on every PR through their respective GitHub integrations (Codex, Gemini, Copilot, Greptile, CodeRabbit).

They never fully overlap, and yet they somehow usually all miss the same things. The most significant improvement came from having agents commit their plan along with their work.

On the upside, it means I get to focus my reviews on different things.

https://zed.dev/blog/introducing-deltadb

The serfs will till and sow the server fields!

That said, sometimes low-trust environments are the issue, not PRs. In a higher trust environment, PR review is a helpful thing you usually desire, not dread.

I've worked with people who consider themselves 'prolific humans'. Someone always has to tidy upp later, and its never them

I am not sure there is a good analogue for reviews in the AI world. The human operating the AI should obviously review everything produced but that is clearly not as good as a second pair of human MK1 eye balls from pair programming.

Then don't review the code. Ask Agents to review and merge it, also shift the responsibilities to the AI agents as well.

If you think human is a bottleneck, then either optimize for humans, or remove humans. What's the problem?

The fix, imho, is for the reviewers to also use ai to review the code. However, the ultimate responsibility for the outcome(s) should be on the committer - you commit it, you own it, so to speak. If there's an incident, they need to be the one paged in the middle of the night. Bugs resulting from it will land on their desk.

The reviewers aren't a shield/safety net.

Yeah, why not reduce the team size to zero while you are at it?

These generalizations about software engineering have never been useful, IMO. Context is everything, there is no flow chart for building a perfect software process.

Although, I'd say you are absolutely delusional if you think we are universally beyond the point where manual review of pull requests is required.

Before AI they had to actually put in work, or at least play games of trying to steal credit from other people without getting noticed. Now that AI appeared, they see it as the ultimate way to take credit for work they didn't do: Put everything into Claude, let it do the work, copy and past output back to someone else. Minimum effort invested, maximum visibility achieved.

It will continue as long as they think they're getting away with it. If managers aren't willing to intervene, or worse if they encourage this due to the volume of output that seems to be appearing, it's only going to get worse.

Obviously you have to communicate with your coworkers. But I think the solution has to essential be: "Im not going to read that."

I have worked with non-tech employees to set up Claude to help them do small tasks. I’ve helped to review and improve completely vibe-coded projects by such employees.

I’m not sure what my role will be, but I fully embrace that my traditional role of writing code is gone.

the honest truth is that maybe 10-20% of SWE (at best) are “good”. sure it is harsh but i won't lie. if you're good you'll probably relate.

the rest kind of suck.

i’ve never gotten anything lower than Exceeds Expectations in my career so I’ve seen how awful some engineers were. i’ve seen how amazing a tiny minority were and i made them my mentors.

these days i have a simple policy.

if they cannot think, they are fired. why waste resources (time and money) on someone who can’t use their brain? i’d rather give AI credits to someone who uses their brain.

thinking is the humans job. the ai needs to execute on what the human thought of, improved, planned.

Because you could also just point the better model at the generated code and tell it to improve it, so why save the prompt too?

If they're gonna spy on me with AI cameras, I can oppose them with AI research. :)

If that's genuinely your attitude then your org has a problem.

Code review is slow and less fun, for the average sw eng. But for high quality work it's indispensable. So treat code reviews as a scarce resource. Optimize for code reviewer time and attention. Have your PRs the right size? Are they well described? Do you give context? Do they fit in the bigger story? Do you mix in unrelated drive-by fixes? How easy is it to deal with you once you have received comments? Do you address them promptly? Do you give your reviewers credit (if not praise) for their help? Do you give back by doing code reviews yourself with high quality feedback? There are lot of things you can do to streamline things and give code reviews the place in a teams workflow that it deserves.

Just send them the prompt instead, let them see how little effort you care to place into communicating with them

That might teach those people a lesson.

Yes, "not actually doing his job". If he's sending you un-reviewed, un-filtered, untouched AI output, that's not doing his job.

Prolific humans should scale to the review/test/QA/staging backpressure - not just push to have whatever they produce accepted.

Prolific is not a badge of honor, and "lines of code" is not a quality metric.

If they continue to do that, then someone has to tell them they're doing a bad job.

And a some of them never did improve, and got fired for it.

I think slowly opening their eyes to the actual scope of the ticket is a lot easier on them than saying "no".

A bit sick and tired of arguments like yours

On the other hand, my priority isn’t maximising my personal career benefit, but the collective benefit of my team, so I suppose I either see it more as a 2v1 sorta game, or perhaps my “player” is an amalgam of myself and my teammates. Playing this way, outsourcing everything you do to an LLM is the worst move, because you lose the touchpoints that tell you where the friction is in your team.

Edit: it's a joke people

[0] https://abner.page/post/are-we-harold-bloom/

Because the prompt is the quintessence of intent regarding the information to be conveyed.

1. Your skills are >2 standard deviations above everyone else's.

2. You're fast at producing a lot of half-baked garbage, and your coworkers are too shy to confront you, so they just try to ignore it.

(one of these scenarios is much more likely)

I run both infrastructure and security - that means a lot of relatively self-contained PRs to infrastructure-as-code and dependency management systems. I'm also the team lead, which makes me responsible for a lot of throwaway prototyping, as well as cleaning up anyone else's mess...

Yes, the prolific-but-damaging engineers are all too common in corporate. But particularly in startup land, you tend to find your high-performers wearing a lot of hats at once.

Doing something that wastes other people’s time or makes more work for them than necessary makes me feel awful.

I’ve always worked in a way that respects other people’s time and I always tried to make sure I did everything I could to minimize the work I’m asking someone to do for me.

Is it even actually good to get to a point of blaming someone for an incident?

This is the complaint:

> he doesn't make it easy for the team to look at.

He has traded readability for volume. The lack of readability is causing him to ship less. This was a bad trade because the readability is the bottleneck not the code creation. He should improve readability.

The solution is in the title - he wants human attention, he needs to demonstrate human effort.

OR - he gets a review for every review he does.

The argument here is that all code reviews are done with attention and care, but quality of a code review is highly dependent on the reviewer and the team’s review process, and in the real world the quality of reviews pretty much follow the same distribution curve as, say, agile project management: For the time invested in reviewing, a handful of teams get excellent utility from them, most teams get little benefit, and a sad few actually cause harm.

If most code reviews provide only a little benefit at base for most teams, recommending that most teams should also delay shipping quality work is going to sound a lot like bad advice.

It is definitely very grunt-like for an LLM.

Code reviews, documentation, static analysis, only retrieving deps from internal repos, unit tests, integration tests, ....

Especially in domains where shipping software is not the main product, and a plain cost center to the main business of physical goods.

He’s sent a couple more emails like that since. I don’t even bother to read them once I see the format.

Someone who produces absolutely nothing and have no impact has cost, but is still better than someone who produces net negative. And the people who solely act as interface between LLM and whatever might fall to later category.

https://chromewebstore.google.com/detail/possiblymadebyahuma...

So in essence you have one guy working at 4x and e.g. four other getting just 0.7x - net effect is still positive, but everyone save for that one person is miserable.

Mind you, the 4x dev doesn't necessarily have to be particularly talented - they only need to get their foot in the door before anyone else.

Back during the ZIRP days you could immediately tell that this is the case in a team by staff rotation alone. Nowadays people understandably cling to their jobs, so you might now know until it's too late.

IME, it’s because they lack the experience to have the Taste one develops as a senior engineer. “This works, and is somewhat understandable” is as far as they get. Little to no understanding of how this solution could fit better in the codebase.

Code review is not for feedback, it’s for ensuring quality (many eyes on the output) and have a shared involvement in the evolution of the code. The time for feedback is earlier, once you have an idea of the solution.

Respectfully, in a high-trust environment, feedback should be delivered well before the PR stage. If you've let someone write a whole bunch of code without having a shared understanding of how the solution should work, you may have earlier process issues that PRs are papering over

Sadly, in my case, it is the auditor. Our SOC2 documents have this lovely "every change has been reviewed by at least one other human", and it's going to be a fun battle to get that reworded

This is false, you’re just oblivious to people who grew up in conditions that would make them that way.

And that's not rare in teams. Lots of teams and developers do code review wrong.

I even hear other people complain that I "block" their code review. I mean, if there are issues in your code, of course I am going to flag them, what do you think the purpose of code review is?

I’ve noticed that large PRs aren’t just a problem for human reviewers: they’re a problem for AI reviewers too.

If I submit a 100 line PR I’m likely to get some useful comments back from both humans and LLMs. In fact the LLM is likely to come back with so much feedback it gets down to the nitpicky/annoying level.

If I submit 1000+ lines in my PR, the humans either don’t have time and/or get scrolling blindness, and the AI reviewer is likely to give me a response that amounts to, “<<slaps roof>> Looks good to me bro: ship it!”

I guess they have a limited token budget for reviews so you can bamboozle them simply by blowing most or all of that budget.

The problem with the personality above is that the person isn't playing like a team (like you said) but as an individual maximizing their own visibility while loading their coworkers up with the review effort. They found an asymmetry to abuse (they generate text easily, coworkers get a lot of extra work to review it). They don't care what it costs their coworkers. They just like that it makes them look good.

I have had coworkers say "Oh I don't know, Claude added that" in response to questions like that without even a hint of shame or self-reflection.

We've already established that most of it is noise. You don't need to keep up with producing noise.

All my experience in trying to hire developers has been wading through an endless stream of people who were just useless.

Me: I want to represent a 2d grid, what data structure should we use? Them: A string?

This was someone applying for senior engineer. Others I've had filled their CV with SQL related acronyms. But couldn't explain what a foreign key was and then stubbornly insisted that at their current corp they would never ever use foreign keys in their SQL database!

I've had senior engineer when asked how to check if we had a 2d array with an item at x,y tell me if anything is on the same column or row, they couldn't do it, couldn't even verbalise how to approach it.

"Web Developers" who didn't know the difference between GET and POST. Web Developers that have never heard of PUT or what it would be used for.

and even at "good" companies you have people who can game the system to get in, and then they struggle to get anything done on time or be responsible for taking on and completing any initiatives bigger than a single task on a bigger scope.

I've managed some incredibly prolific developers and some very slow ones, and the prolific ones are pretty much always the ones more available, more willing to fix things, more willing to take feedback.

And also: they make less mistakes because their skills are sharp. This anecdote comes to mind: https://austinkleon.com/2020/12/10/quantity-leads-to-quality...

If you have to constantly rationalize performance differences by demeaning others, this says more about you than the prolific people.

I don’t know how many of y’all did these, but I’m sure I wasn’t the only person. At my undergrad it was very common for a group of students to all to get together, compare notes from lectures and readings, and basically come up with a group study guide of sorts. People were given specific sections to share, you didn’t just send all of your notes - usually 2 people per section’s take on that portion. You could always tell who just copy and pasted their shorthand (usually indecipherable) and who actually took the time to edit it/clean it up. This was at a time when almost everyone did it on laptops.

The people who took the time to make their portion(s) digestible for others were asked back, the others weren’t.

Or if you don't care you can just ignore this persons messages.

feels like its becoming reality that we as a human don't need to this anymore

We had better management for a few months, and many on the team were actually quickly closing the skill gap with me, but we had another shuffle and things are stupid once more.

So I'd offer that's option 3. (There's always a third option to any suggested either-or fallacy.)

But of course HN has to with the most uncharitable interpretation.

The answer that almost guarantees I'll hire you is "there's got to be a library function for that, so I look in the manual". Almost as good is somebody whiteboarding how they'd convert ddd to mm-dd (and then account for leap years, etc.)

I get a disturbing number of people who say things like "I would communicate with the person asking for this to see what they're really intending blah blah"

My favorite answer was on a phone interview where he just hung up and wouldn't answer when we called back.

Change your auditor and compliance, SOC2 is created for a trust between organizations employing humans, if you think agents can own the things, lead the way, introduce a new compliance, if companies sign up for it, then you will be the first who is removing the human bottleneck.

I think the ultimate answer to this is a stacked PR workflow (which we had at Meta), where I can cheaply maintain/review a 1,000 line PR as a stack of 10 incremental PRs. But unfortunately GitHub et al are still not quite there on this one.

...is "Rule of Law" IMO

If a coworker is creating a ton of AI-made PRs, I think the first step should always be to run an AI against them with the "assume this is low quality code and find all problems, big and small" text that was suggested in a comment here, and let that be the first line of defense.

To keep the dev on their toes, each dev should come up with their own prompt for AI PR review and they can switch off who reviews it each time, until there are no problems remaining.

Then a human can start to review it.

It will quickly show the low quality code being produced and the massive waste of time it is for everyone, not to mention all the money spent on tokens for the whole process.

Or it'll work, and everyone will have their way, and only have to review code that's pretty decent.

In this sense, I'm not sure I've ever seen a team that does codereview "right".

In the before times, most PR feedback was stylistic, with the occasional bug identified. Now that we have ubiquitous auto-formatters/linters/CI, most PR review falls into either "you misunderstood the spec", or "I disagree with your architectural choices" - and my personal feeling is that your process ought to catch both of those well before the PR stage

The problem here is that all tech companies look alike. Take for example the interview process (copied by almost any company out there that thinks they are google). Another example: the under/meets/above expectations BS. And now the most recent example of “token usage as sign of productivity”.

So, it’s getting tremendously difficult to simply switch jobs that offer something different

So the actual problem statement is not "how do I keep up" but "how do I correctly tune my filter", which is solvable.

The biggest challenge there I think is that many people are not prepared for just how sharp and uncompromising that filter needs to be, but that too is solvable.

I still think a single in person LC style (doesn't have to be LC per se, could be domain specific) logical thinking/reasoning exercise is useful. I want to ensure the person can actually put 2 and 2 together and think. This is just a fast filter.

If they seem like they can think, then I like to do 2-3 systems design interviews. I'll try to give them something related to things I like, such as graph structures, writing a complex query that needs to be dynamically generated, or something related to infrastructure or how they'd do something that I've already done. After all, this is MY project they're joining.

So far that has worked well.

Few more things -

I like to test if they are a humble type (they can work on a team putting ego on the side - the mission is our number 1 priority). if they say they know something that i know and asked, then they can be sure I'm going to drill them on it. if it turns out they lied, i'm not wasting more time. Thanks for your time, take care. This is very important to me. Just say you don't know, it isn't a big deal because ever since like 1994 that has not been an issue. You can just learn things online, and AI makes that even faster. I am never afraid to say I don't know something, and I've asked plenty of "dumb" questions (while doing some due diligence first) so I don't really mind.

Can they handle information overload? I am the type of person who has multiple branches in my head of actions I can take next, so while I may appear stressed I'm really not. Can they keep up? Our goal as software engineers should be to come up with solutions that solve the problem in a way that makes building on it simpler in the future. My goal is simplicity and effectiveness. So I'll see if they can keep up, and eventually reduce the work to be done into atomic pieces. This is a fun exercise because it is collaborative and we get to bounce ideas fast back and forth.

Finally, I like to let them use their favorite tools, including AI tools (codex, claude, some ppl have esoteric custom stuff which is cool), to solve a problem together. It might be code related, it might not. Really depends on my mood. I like to see how they work and what sort of output they can come up with. This filters out people who only ask AI stuff, instead of having some framework they've already developed to be effective.

Honestly I don't know how to scale this process. I'm not really going to feel bad either about firing fast, ultimately this is a business and I don't want customers to suffer because we have some issues internally.

At the same time, I wonder if I even need to build out an org with 100s of people. That was an inefficiency (look at all the layoffs), and it is traumatic.

If I can find a few great people who can be supercharged and turbocharged and electrified with AI, then they can take on & own bigger responsibilities. My number 1 goal is to ensure they're with me on the mission, and after that all things seem to sort of fit into place.

Others are just trying to get code done, and don't care about quality. These are the types that are upset that their code gets rejected because their goal is advancement and money, and not doing a good job.

FWIW, it's okay to care about both. But if you don't care about doing a good job, you're going to drive everyone around you insane.

Prolific bad coders are a bane on the company, and AI is only going to make them worse.

Sounds like they know this question is a “gotcha” question but just misinterpreted which direction you were going with it.

Some will ask a question like this expecting you to treat it like a puzzle and outline how you’d solve it as-is; others ask it as a way to probe how you’ll deal with strange or misguided requests (the case you noted as disturbing); and others yet will ask it to see how you’d practically solve it (your intention).

Seems like a bad interview question without context regarding kind of answer you’re looking for.

With human reviewers, I find that by the time someone has churned out enough of a solution to post a PR, they are already quite invested in specifics of the solution, and it makes it emotionally costly (to both author and reviewer) when someone says "hey, I'm not a fan of this whole approach, lets start over and do it this other way"

> first step should always be to run an AI against them

What if they write an agent which takes the feedback and resolves them with a new commit. Which again didn't do anything other than offloading more to humans who are reviewing.

> each dev should come up with their own prompt for AI PR review and they can switch off who reviews it each time, until there are no problems remaining.

This assumes AI reviews are correct most of the time, if so, why do we need even humans. Why not have repository level code reviewer which is run immediately after code has been created?

regardless of where you move it, there is still a bottleneck: humans.

If you don't remove them, you will just pass the ball between agents and at the end of the day human still needs to review it.

On your original claim, I have seen engineers put up 5x more PRs simply because they paid less attention to the quality or put less thought on each one of them.

I have seen people put up 5x more quality PRs too. But as long as they follow the good practice of doing a code review for every PR they put up (or 2 if you require 2 per PR), they got their stuff through quickly as well.

> your process ought to catch both of those well before the PR stage

We have multiple points where mistakes of any sort can be caught, and code review is one of them.

Yes, most architectural issues should be caught earlier, but some will only become evident in code: some by the dev themselves, others by reviewers.

This is only a problem if you mostly catch architecture issues at code review phase.

You can also look to change to different roles (product management, even sales) or jump to a different career completely.

There are options if you look. You're not going to find a dream job that pays $600K for 4 hours of no-pressure work per day and perfect coworkers, but there are a range of job options with tradeoffs along the compensation-effort pareto front.

I think that only speaks for your own experience. I have definitely seen more than a few PRs that needed significant work.

That's not prolific, that's just producing slop, with AI otherwise.

I'm just tired of developers pretending that low output is some sort of silver bullet for quality, and high-output is automatic slop. Neither are true. In 99% of cases, low output doesn't correlate with anything positive. High-output can naturally go either way, but slop doesn't make one "prolific".

The emotional toll there is real, but this is exactly the moment when you expose the knowledge of that external dependency to the unbiased party that is the reviewer.

I like combining approvals to satisfy the urge for completion and closure, with a request for fast-follow refactor to better match the newly discovered model of interaction. (The worst code review experience I have seen is when a reviewer accepts it as-is and does a fast follow refactor themselves, depriving the author of the opportunity to learn and remain an expert in that area)

Right? Right?!

Otherwise you place all burden on high performers to not only push PRs but babysit the rest of the team.

It's not an easy fix, especially with AI letting people cosplay as high performers.

I'm not sure how much I'd enjoy working on teams who were routinely producing PRs that were in bad shape.

If you would ask someone to write a piece of code, and a part of the problem is this conversion, then you would be right to expect they reach for a library, but even if they don't you would be giving them the opportunity to explain themselves, and judge the explanation, not the answer. Also, if your test is "does this person reach for a library at the right time", you could do a lot less esoteric and confusing by just asking them to add 10 days to a date. If you just ask this one specific problem, it is likely they assume you are looking for them to demonstrate the skills involved in actually solving the problem, i.e. leetcode.

This is also why some people give you the blabla answer, because it is indeed very unlikely that someone needs to do this legitimately. This is because its a toy problem. Someone's professional reaction to the problem in isolation should indeed be: this is weird, I've never been asked something like this, what's up?

Finally, even though the question is terrible, I would still rate the "whatsup?" response higher than the "leapyear" response. I would want a developer to triple check that this problem needs solving, before they would solve it themselves.

Finally finally, if there's one answer to one question that, when answered trivially in a way literally taught in most basic programming courses (use the standard library / a third party library), makes them a "guaranteed hire", I also have significant doubts about the level of talent you are bringing in, as any experienced interviewer will tell you that qualified people will get important questions wrong, and unqualified people will get important questions right.

I understand that this reaction might be quite harsh, and I know better than anyone that its hard and time consuming to do good interviews, but please consider that you are rejecting people who may be very confused and sad by this way of rejection.

Reviewers have comments which were not addressed by the PR author - author not allowed to do other work.

No such comments, especially no reviews - author can do other work.

If their PRs don't get merged they don't perform. It is trivial to overload your coworkers with secondary tasks due to your "high performance".

I prefer fizz-buzz as a question because it is obvious there isn't a library. It is also a problem you should be able to do in an interview. It has enough weirdness that there is no best answer, despite having several workable paths you could try.

We're all aware that a huge portion of the busywork that makes a team successful is not actually reflected in their upwards-facing deliverables (increasing test coverage, improving infra, adopting new tools/methodologies, preemptive security patching, etc). Your actual high performers, if you have any, are doing all that stuff in addition to their regularly-scheduled duties.

If management weren't at least tacitly on board with this arrangement, your high performers would go work somewhere else. So my experience is that good managers don't tend to see this your way.