Surviving Code Reviews in the era of AI
81 points by mrpossoms
81 points by mrpossoms
My coworkers are all fully AI pilled. As a consequence, every PR that comes my way for review is on average ~6k lines of diff.
It's well established that even PRs an order of magnitude smaller than this are too big to be effectively reviewed. I'm still clinging to the idea that us humans should understand how the systems we are building work, so I'm hesitant to use AI for reviews aside from more general question answering. Much of what it produces in the way of explanations are difficult to follow and overly verbose anyway.
I'm sure I'm not the only person here who has been dealing with this problem, so I'm curious if anyone here has found any strategies (organizational or personal) which have helped weather this maelstrom.
6k diffs are completely unreviewable, and would be rejected in our workplace. We have rules that PRs with diffs cannot be > 400 lines (with exceptions for things like moving code). These rules apply if the code is produced by AI or humans, there is no difference between the two.
We use AI PR reviews, but only as a first pass in order to save human reviewers some time.
IMO AI tools are useful but they are just that, tools. The code produced and decisions made are still the responsibility of the people using the tools. Ex: AI isn't capable of deciding if code is good enough to ship.
I imagine that many of us are finding ourselves in the position that large PRs should be unacceptable and can't possibly be reviewed effectively, but we have no political will to actually enforce that. Management wants things to go out and cares less how you feel about it. So the choice is to either give up and let it through, or become a point of friction for everyone that will eventually have a target on their back. I would love to keep the standards high and just use AI as a tool to make it easier to meet them, but it's not what I'm seeing on the ground.
Yeah, this is what I've seen at both my current and previous employer. It's an extremely predictable outcome to anyone who was paying attention a couple years ago. Everybody is riding the Vibe Bobsled all the way down the hill: https://dustycloud.org/blog/faulty-towers-vibe-sickness-and-the-vibe-bobsled/
My strategy is to try to keep my head down and try to ride out the bubble. Not at all satisfying, but I don't think there is a better option.
This might be controversial but at some point it's just not in my job description to rescue someone else's company from their own misguided ideas or from their failure to promote people who understand engineering quality management.
It's not just that it's impossible for a human reviewer to productively review a 6000-line blob (I mean, at least if it were a sequence of commits that you can follow or something...). It's impossible for a human reviewer to productively sit in the loop with a review agent and judge its output in any objective capacity.
Is that a good way to write software? No. Does it produce good software? Also no. Am I going to fret over it and fight for proper engineering quality standards, thus doing the job that's supposedly meant to be done by the people who get multi-million bonuses on bad fiscal years when they fail to meet every single objective, wave the company card for 2,000-dollar dinners, and take two-year sabbaticals? Not until I get my multi-million failure bonus, at least 2K in steaks and tequila, and my two-year sabbatical.
Is it very likely that said software is eventually going to become unmaintainable and the company will eventually crash out? Absolutely -- but my job literally ends at saying so.
Is it very likely that said software is eventually going to become unmaintainable and the company will eventually crash out?
Not that you're wrong, but the problem is this the entire industry, not a few companies here and there.
Is that a good way to write software? No. Does it produce good software? Also no.
I don’t think we know this. If you repeatedly prompt Claude to review, and look for simplifications you can get it to produce something pretty good that you can actually read and meaningfully supervise.
This is very unfortunate, particularly given LLMs are great at splitting up commits and handling merge conflicts. Any chance you can convince your coworkers to use agents for that? Or is it a lost cause?
My feeling right now is lost cause. There's a lack of direction from leadership other than "use AI to go faster." So some amount of people are always going to interpret that as liberally as possible and resist anything that would add friction.
This is so unfortunate. I feel like I get so much value out of making commits smaller -- I keep finding so many issues in smaller pieces of work (the maxim of larger chunks of work getting less thorough review is very real)
Yeah, I was going to say the same thing. I learned that with a tool like jj assisted by AI you can actually make really readable series of commits designed to be reviewable, and that you understand.
That takes time and human attention. AI can not only assist to make more code faster, it can assist in understanding, being more carefully and being more legible as well. The question is whether people and organizations are actually interested in this.
I have been doing some fairly large things successfully by having similar interactions with Claude that I would with a mid-level engineer. I review the plan, ask a lot of probing questions, look for code smells, and make it produce the work as a small set of stacked commits (thanks jj!). (I.e., “Fix this in the original bad commit if possible.”)
I don’t deeply review the code until it’s been through one or two full Claude code-review cycles (which are pretty impressive) and findings are addressed. Then I have it write a review guide to walk me through the code. Then I review the code.
No doubt some would argue that I don’t need to do any of that, but I disagree, based on the stuff that gets fixed in the process.
Are there any actually good AI PR review tools for this sort of "first pass" analysis? I would actually like this if it existed, but every tool I've seen produces absolute dogshit feedback and is OUTRAGEOUSLY expensive
We use Greptile, after comparing it with CodeRabbit. From our experience, CodeRabbit was horribly noisy and useless. Greptile catches a fair number of issues and I strive for a 5/5 rating from it. Even the false positives are fine because it requires a human to say “no because…” instead of implying it.
Often, I’ll draft a PR, Greptile gives feedback, and I’ll redo the full PR or stack because of something it flagged. My coworkers get added once the AI reviews are resolved.
I use Claude locally with this plugin and this prompt. It is very effective at finding issues.
We just use Github copilot, I haven't tried anything else. The majority of the feedback is useful IMO.
Honestly I'm not looking for much in a first pass AI review, I just want to know about things like gaps in test coverage for added code, spelling mistakes, etc and have them fixed before a human sees it.
Codex as GH bot (https://learn.chatgpt.com/docs/third-party/github) is actually really good this year and many times picked up things I completely missed. Occasionally it's still dumb but then you just downvote that comment and move on. It's definitely worth it.
Overall, make sure you use something that has access to the whole codebase rather than looking just at the patch.
Builtin Claude Code /code-review is pretty darn good in my experience, if you tell it not to limit the output to ten findings (why on earth?) and produce a persistent numbered list of findings you can then walk through and address.
we tried like five or six for a while to compare them all (we didn't have them all looking at the same PR, we created multiple PRs on a single branch for this experiment and assigned different bots to each one) and eventually settled on cubic. For whatever that's worth. Our devex team set up the experiment and got feedback from the engineers on which one seemed the most helpful. I've found cubic to be pretty good tbh.
EDIT because the context probably matters: We have a bunch of medium-sized typescript apps that do a lot of financial computation with a basic React UI bolted on.
I have this problem too, and its taken me awhile but the point of view I arrived at is:
My proclivity is towards careful review and slimming down prs. My boss has been very clear that he wants only high level review around “is the feature working and are their automated tests “
I’d say if you’re out of step with the rest of the team expectation wise maybe have a sit down with management and figure out what they’re expecting from review.
I would not recommend trying to warn about them of the ills or pitfalls of excessive uncritical AI usage. You are unlikely to convince them with words. The organization has to feel the fallout out of their decision-making to make changes. Naysaying has usually only worsened my credibility.
This is revealing to you in plain sight the engineering culture at your workplace. If you don't have the agency to reject those PRs and say "I can't reasonably review a 6000 line PR, break it down into smaller changes" then your workplace has a big problem.
People should be understanding what they're committing to a codebase. They should be able to explain to you in their own words what the purpose of a given diff is. If they can't do that and you're expected to not push back, just write "LGTM!", and hit merge, then you're working at a slop company producing slop. This is not responsible use of AI.
Some people (or their managers) can be reasoned with and told "hey, this isn't working, this isn't good engineering, stop this. (etc)" and come back to reality. So see if you can arrange a conversation with your team/manager to get guidelines or rules put in place about people taking ownership of their code, max PR lengths, use of stacked PRs, human-written explanations, etc. Maybe stressing the "we want to be using AI responsibly" point can work.
If you can't talk about this at your workplace—or you do but they don't see a problem and won't change anything—then I'm sorry to say that you're going to have to either put up with it (by not doing reviews at all or ensuring that you're just meeting your manager's expectations like what CharlesT mentioned) or make the tough decision to leave. It sucks, but that's how it goes when you clash with your workplace culture.
TL;DR: talk to your team and managers about it, express your concerns and try to change things for the better. There is no other strategy. There is no fixing this without other people being on board.
If there isn't a good summary written of "Why?" and "What?" with the PR, it's an immediate "return to sender." A PR shouldn't chuck work over the wall and force you to reverse engineer it. It should be an engineering demonstration of "This is what we needed, this is what I considered, here's the code and why it works." If you allow otherwise, these sort of extensive reviews will tank your productivity and you'll be dealing with those consequences while the "productive" people get the kudos.
A lot of review systems let people stack up multiple reviews in sequence. I would ask them to limit the size of PRs and work in atomic units, and if they don't and still send massive ones just send them back.
In parallel to my review, I'd kick off an AI review with one from a set of prompts I'd been curating. When I'm done reviewing, I'd check what AI says. I split out the files in the review tree, get a feel for the overall, and then tackle the simple leaf parts first.
Code reviews are a two way street, don't approve what you aren't comfortable with. Add lots of comments where appropriate and feel OK saying "Changes are required."
This is where we are moving too - LLM generated PRs are ok, and even sending a Claude response in an answer to a question on slack is ok, but the author needs to include human-typed text and thoughts at the top to give a "why" and "what" which describes the human intent and rationale. The agent responses are artifacts or attachments to the author's intent, not the entire answer. And more importantly the author should be available to voice chat or respond to these questions.
sending a Claude response in an answer to a question on slack is ok
That sounds dystopian and like an easy way to drop the ball on engineering communication. I'm asking probably because I've already looked and also asked an LLM.
Sometimes it is a cross team thing where the person asking the question may not have the context - in multiple senses - of what they are looking for.
For example let's say I'm responsible for infra spend, and find some lambda that is costing us money but doesn't seem to be working, I can have the agent dig into this and give a timeline of when it was provisioned / what the errors are / how much it is costing. Then when bringing this up to the person who may have provisioned the lambda, I can explain what led to me finding this, and then paste the agent findings at the bottom of the message for them to read.
The Claude output is not the full answer, but an artifact on the message. Like if I pasted a csv snippet or code snippet.
But you are right that it could be considered a failing of the engineering org that the question asker's agent does not have this context, and sometimes a failing of the asker for not doing enough work to answer it themselves.
You're not going to like it, but my strategy so far has been stepping away from code reviews. I used to be super reactive on code reviews and try to review as much as possible because I loved it. Now I only review PRs people directly ask me to review.
I'm not there yet, but I know at some point I'm going to do what everyone else does and approve after only a cursory glance and maybe a few surface comments. I hate doing this, but gotta stay sane.
Set boundaries and say “no”, with ways to get to “yes”. I quickly review small PRs and ignore big ones to conserve my energy and focus. I can’t review everything and I never could.
When someone directly asks for a review of a large PR, I directly tell them it’s too large. I explain that it takes a lot of time to review something so big. I have a strong standard for both PR diff and descriptions.
Saying “no” works if you give people tools to get to “yes”.
Stacked PRs are a wonderful tool to break up large PRs, and LLMs are quite wonderful at doing most of the splitting. They are mediocre at figuring out good ways to split, sadly. So if someone is interested in learning, I directly teach them how I would split a large PR. There’s a lot of taste and not a lot of good rules.
I’ve found amazing success with sitting down with people and reviewing with them. When they see what I’m reviewing for and looking for, they understand better. I’ll vocalize my questions and concerns as I review, write them down, and cross them off as I review.
I introduced a plain-language skill at my work that works really well. I usually tell people I couldn’t understand their docs, comments, or PR descriptions without it, so I require they apply it to their code before approval.
By doing the above, I usually can break apart the review into chunks of questionable material. Those chunks are the smaller PRs. If it were actually smaller PRs, I would have quickly found answers to my questions like “was this a move or a refactor”.
LLM code reviews are useful, but only if you have taste. It flags EVERYTHING and you have to have judgement of what is worth fixing and what is a hallucination. Here, you say no to the LLM, and it’s often quite receptive. I’ll literally say no to it with reason, and sometimes it’ll correctly push back with something I missed.
Finally, I really struggle with how some people speak these days, they have their own dialect of LLM in their voice. So I usually work with an LLM: give it context, quote the person, ask the LLM for a plain language version, and ask my paraphrase is correct. I go back and forth until it feels clear. For these folks, communication is not their strength, so I try to meet them where they are and push them to improve in other ways.
Set boundaries and say “no”, with ways to get to “yes”.
When they see what I’m reviewing for and looking for, they understand better.
This shows how you're trying to ensure quality and not just be a roadblock.
Teammembers might also be able to codify some things in their AGENTS.md files or in skills so you can prevent things from making it to review. If the best you can do is getting folks to talk about what they review, just standardizing the team on quality aspects is a win.
I believe going forward, there will be two kinds of software teams:
Ones where there is an expectation that no matter how much AI helps, a human is ultimately responsible for understanding all of the source code and keeping an on eye on it as it evolves. Every line of code landed must go through someone's eyeballs first.
This is how most dedicated software companies have run for the past few decades.
Ones where the software is written and maintained by AI agents. Humans have an executive role over the codebase: they can inspect bits and pieces if they want, but are much more likely to ask AI questions about the code and trust the answer.
This is how most non-software companies who contracted out to a separate development house for their bespoke software has worked for decades. If you're a bakery and you want some custom program to help you keep track of orders and figure out how much of each kind of donut to bake each day, you found a software contracting company and hired them to write you a program. You're a baker, you can't read code. All you could do is ask the company what the program does and trust their answers. The difference now is that instead of it being a separate company of humans, it's a set of AI agents. But the workflow is the same.
Both models are viable and I expect that we will continue to see both styles for many years going forward. I won't make any claims as to which model is better under which conditions.
However, it is absolutely essential that everyone on the team be crystal clear about which development style they're doing or no one is going to be happy. It sounds like you're a #1 and the rest of your team is a #2. You'll need to get that sorted out.
Thanks for writing this out! I had a gut feeling in this direction but struggled getting it into words.
I have this problem, but I have no strategies.
Much of what it produces in the way of explanations are difficult to follow
Thank you for including this phrase. I have to read/re-read/ponder most LLM-generated explanations, even shorter code review comments. In general, LLM-generated prose is genuinely difficult to understand. LLM-generated short comments tend to be jargon-packed, with rare jargon: a length check "gates" array access, a test "pins" some particular behavior, things like that. Mostly it's a case of verbing weirds language, but not always. I think sentence structure is also a barrier to comprehension.
There's also a human tendency to demand clean-up of anything an LLM identifies as a problem. If LLMs were consistent, this would be OK, but they're not. Sometimes they insist on manifest constants, sometimes they don't. Sometimes expressing a doubt in a comment is a sin, sometimes they're ignored. Dogpiling ensues.
Using AI is not an excuse for large diffs! If the developer doesn't want to hand refactor the code (my preference is to hand refactor it to my taste) they can ask the AI to split it into smaller fucntional chunks.
If neither the human nor the AI can split it up into digestible chunks, well both should work harder.
Glib answer, find better co-workers.
Real answer, do what https://lobste.rs/s/7tpc5q/surviving_code_reviews_era_ai#c_joijyn suggests and make your co-workers better.
(For context: I founded Review Board, one of the earliest code and doc review products on the market — 20 years now — and have been building that and thinking about these problems for a while, so... I have opinions. But I'll keep it simple.)
I'm in full agreement, a 6K line diff is too much for a human to review, and AI-only review isn't the answer. I've been fighting the "please break your changes into smaller pieces" uphill battle for two decades, and I think it's been hard partly because it's a lot of work to retroactively break up a change and it requires a different mentality when you're actually doing the coding work.
AIs aren't making that any easier for humans, between large diffs and larger influxes of changes and progressively less and less context forming in anyone's heads.
I've been spending a lot of time thinking and working on this problem lately. I do think there's a lot that can/needs to be done here for review and retaining institutional knowledge beyond just giving up and giving in to AIs. But, fighting fire with fire, I do think AI tooling (as part of a broader strategy and toolset) can help with this problem in a way that still keeps the human firmly in control and informed.
Our space is very saturated now, so I'm keeping some of what we're building for this close to the chest until we're ready to announce, but one thing you might consider is using AI to help you break things down locally so you can focus on smaller pieces at a time. Should help you see what's going on and fit more of it in your own head.
You can also try to start by having AI do a first pass and summarize at a higher level what the change is trying to do and where to start with your review process, what things you should know and remember and focus on and look out for, rather than just "please review this (so another AI can fix it)."
(Or wire up an agent to check for diff sizes and complexity and reply with helpful prompts the developer can add to their CLAUDE.md to better cap commits, every single time they do it... Let me know how that works out for you.)
I believe more code review tools need to let teams set limits on diff sizes, too. That's one of the things we offer, but increasingly something that companies turn off due to pressure from developers producing large diffs. It's at least a first stab at encouraging people to be mindful of diff sizes.
There's also a lot of good discussion in this thread. Things are messy right now and a lot of us are seeing the same problems, with very few really good solutions. I'm hoping I can bring some fresh approaches to the market (I really think there's a lot that a dedicated and well-integrated code review tool can do here, if it's wired in right.), but I also think our industry's going to be learning some hard lessons here soon about combining cognitive debt with "move even faster and break even more things".
yeah, pardon my weighing in, since this has been your professional focus while it's only been incidental for me, but...
my view is that... code review practices are a horizontal concern. for those who've been fortunate enough not to learn this business jargon, it means things that affect every team regardless of product area. like most horizontal concerns, these practices need to be shifted left - considered from the earliest stages of development, rather than at the end - if they're going to turn out well.
unfortunately, upper management is categorically against adequate investment in horizontal concerns, because the harms from doing so are almost impossible to measure and often take the form of externalities that harm customers without directly affecting the bottom line.
I cope with this awareness by telling myself that C-suite knows they're making everything worse and if I were to burn myself out trying to change that, I'd be doing them a favor they don't deserve.
Yes, from what I have seen in practice and read elsewhere this problem is rampant. There are a lot of opinions out there. I thought Rust's approach was interesting and helpful: https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/
Basically if your engineering leadership is condoning or enabling this behavior you have very few options aside from driving a bot through the review.
Aggressive approach: Have Claude review and nitpick the shit out of it. Make sure to tell Claude to look for bugs, style errors, and opportunities for simplification through better design. Tell your colleague you’re willing to have a human discussion about a PR of say 600 lines.
Non-aggressive approach: ask your colleagues to produce PRs only after their agents have reviewed repeatedly and converged; their agents have simplified all comments to allow easy comprehension by the next reader, and have their agent produce a reviewer’s guide.
Still have Claude do a review and if Claude has a lot, let them know that Claude found so many issues you think they could spend more time going over it. Also, if you have any design comments it’s worth leaving those.
AI producing the code diarrhoea is not compatible with the current review workflows we have. I don't think both can survive in their current form.
Some partial mitigations require throwing more AI at the AI:
You can tell AI to split the changes into smaller PRs. You can try nagging it to write DRY code and challenge it to redo the change in half of the lines of code (BTW don't try to salvage any existing code. AI is better at rewriting from scratch than editing code).
Set up AI code review, run all the linters you can find, give it checklists to follow, make it try hard to prove the code has bugs.
You can tell AI to write you a walkthrough of the changes, and tune the prompt to exclude stuff you already know. Require the doc to be logically structured, and force it through a few rounds of removing verbosity.
If there is a review that you can’t sensibly review because your coworker didn’t break it down well, reject it and tell them why. If your team norms don’t allow for that you need to talk to your coworkers and come up with a consensus that does not ignore the central fact that these PRs aren’t getting reviewed by a human as is.
The size alone makes my response very easy: "This is way too long. I can't review this. I suggest you chop it up first." And if I'm ordered to review it anyway: "This is too long to be trusted. Rejected. Chop it up first." And if they do chop it up, I'll be happy to review that, though I expect I will have to reject most of those pieces for one reason or another.
Don't review code.
If no one cared enough to write the code themselves, and no one has bothered to read the code themselves, and no one cares enough to make it easy for someone to read the code… what is code review really accomplishing?
Dave Beazley once complained to me about a presentation he saw where a company said they had millions of lines of Python code that they were struggling to manage and that they needed various contorted mechanisms to deal with it.
His response: “rm -rf .; the ‘rf’ stands for ‘re-factor.’”
I believe that the diff based PR has been bad from jump street; the AI tools have only made my conviction that this is the case stronger. It's an abstraction violation, because it's a claim on human time to review a machine document.
A 6K diff hitting you is a management issue. Humans will always be overwhelmed by the speed of automation (genAI or not) - in other branches of engineering, like manufacturing, humans are allowed to access samples to establish quality and only rarely they are expected to check every single output. The answer to your question is that, you don't handle a 6K lines diff. It doesn't mean that these 6K lines diff won't need to be verified somehow, and we could discuss what technologies and techniques can be used for the verification but I believe it is out of the scope of the OP's question.
And more subtle management mistake also in play, it seems: the non-crisp separation of Ai-driven coding and human driven coding. For good or for bad, people who decided to not read the code and handed coding to AI shouldn't share the same playground of coding artisans. They cannot co-exist - and often the artisan will simply loathe the AI-pilled folks. Makes no sense using the "be professional" card on people that will so obviously antagonize one another.
So the fact the you put yourself or that someone put you in the path of an automated coding flow is an indication of an organizational problem.
Some, namely artisans, will claim your workplace is broken if you aren't allowed to pull the andon cord and block a 6K diff. Maybe that's the case, but you also have to ask yourself if you're not out of place, in being in a company that decided to give up on their code crafting ways. It is possible and likely that a PR with a 6K diff is the intended goal here.
I think the complexity of a change vs. the LOC involved is very language dependent and very explicit languages (go e.g.) tend to have higher LOC compared to terser languages or those that provide more abstractions.
Sorry, is it well-established in research literature that ~600 line PRs are too big to be effectively reviewed?
I was thinking something similar. I do Scala and a ~600 line PR of code with some density is starting to be too big .
It must be language dependent. There's no way I'm not pushing back on a 6k PR. AI generated or not.
I know the dogma is that you have issue as the first moment to collaborate, then coding happens, and then a PR appears and that's the second and last moment of collaboration (and often the first one between developers).
Developers like it as they don't have to bother with anyone else, can work autonomously, can feel productive. Organizations like it as it's legible and they can pretend developers are always replaceable with other developers without affecting the quality of the outcome.
But you could talk to each other, work on stuff together, along the way build theories together about how things work now and how they should work, and keep all this in the back of your head as you work on new features. This, I think, results in a higher quality system in the end, and also important, people are happier too. But it takes time and effort and needs to be supported. Intense collaboration isn't easy.
Who knows whether this is really the case anymore with AI development. We're all finding our way in this and the situation keeps evolving. My intuition is that quality still requires human understanding. That human understanding is more important the more novel your project is, and the more critical a piece of infrastructure it is. That AI lets you run ahead of your human understanding (just like using someone else's library or programming language is), but that if you run ahead too far you get into trouble. But again, we're in unprecedented times here.
We accidentally ran a small experiment with AI-assisted code review at work. I was working on a fairly underspecified ticket and needed a PR approval to merge to main. The only colleague available was working on a different part of the project and didn't have much context on what I was changing. They normally use a bespoke AI agent to assist with their own reviews, where they know the code and can properly judge its suggestions. In this case, though, they admittedly relied much more heavily on the agent and only superficially triaged its comments. The first review round was actually useful. It caught a couple of edge cases and made some reasonable suggestions. The second round was mostly nitpicking, but I made the suggested changes anyway. By the third round, it was proposing changes that effectively reverted changes it had asked for in the second round. At that point we stopped, because it became fairly obvious that it wasn't converging toward "this is good enough, approve". It would apparently just keep finding something to comment on. A human reviewer has an implicit stopping condition: the code doesn't have to be exactly how they would have written it; it has to be good enough to merge. An LLM prompted to review a PR seems to have no equivalent concept unless the human supervising it supplies one. Once it has exhausted the meaningful issues, it won't just say "looks good". It can move on to subjective preferences, increasingly marginal suggestions, and eventually contradict its own previous advice, so the problem not just humans reviewing LLM-written code, LLM reviewing human-written code is not much better :D
If you're only in there for the money,
Wait a minute. Do "told you so" moments actually happen? Meaningfully??
I've been at this for 36 years now. I have had so. many. fricking. told-you-so. moments. Occasionally, it's been valuable with a peer/colleage. But NEVER with any non technical type of person. Never. They didn't understand what I was saying in the first place (it's why they begrudgingly employ me to deal with the necessary evil that is software development), and so, it's no surprise that they don't understand/care in the second place.
For me, it's the copious amount of comments. I've always been a fan of rare/valuable comments (https://c2.com/ppr/wiki/WikiPagesAboutRefactoring/CommentCostsAndBenefits.html).
But so much of the slop generated code is rife with tautological comments meant to keep a "code must be commented" linted world happy. I have tried to poison against this with agent files. It has had mild improvements, but not a lot.