Interesting question to study, but I'm extremely skeptical of the experimental design. They used Opus 4.6 to synthetically produce "degraded" or "cleaned" code bases for relative comparison in the experiment.
Worse, they don't control for breaking the application's tests.
> Pass rate scores the agent’s final state against the hidden tests we wrote for each task. We do not check whether the agent broke unrelated tests already present in the repository, and a cleaner-side and messier-side solution that both pass the hidden test may still differ on tests they were not graded on.
Any conclusions with respect to token consumption seems pretty meaningless if we're not controlling for the quality of the final output.
In my experience, the delta in agent performance is substantial if the codebase is littered with dead code, redundant code, unreachable fallbacks, leaking abstractions and half-baked design patterns vs if the code is well-organized, with clear data flow, with good encapsulation and clean architecture. Like, I've seen all the frontier models have to do several rounds of code review / QA and fix when the code is bad vs just getting it right at the 1st/2nd attempt.
Some of the issues mentioned above like dead code removal, code duplication, unreachable code are already solved using deterministic linters for quite a while now for most language ecosystems.
You can get the LLM to run a script which checks for all of these and also enforce them by running the same script as a pre-commit hook. Setting this up religiously in every code base I work on has been what's given me the most mileage with agentic coding.
I wrote down a more detailed post of the various linters I use here:
Sure, giving agents a deterministic way to run linters is good, but that already implicitly accepts the premise that code hygiene does actually matter. If you agree with that, then you probably also recognize that there are some things that you can't lint for because they're a lot harder to define, and why would you expect an agent to be able to figure that out today when they still need our intervention to even properly run linters?
> Some of the issues mentioned above like dead code removal, code duplication, unreachable code are already solved using deterministic linters for quite a while now for most language ecosystems.
I have legacy endpoints that are no longer used in practice, there for historical reasons, intertwined with existing code etc. They might be marked obsolete, services implementing it are not - agent greps those, builds off of them - produces half legacy garbage.
Linters only handle trivial cases most of us already solved.
Yeah, we have a big struggle with this. We have lots of legacy code that doesn't follow our latest design patterns intermixed with new code. The LLM picks up bad habits depending on what it pulls in to context first. We have AGENTS.md configured with the right way, but old style still slips in. We obviously need to update the old code but on the other hand if it ain't broke why touch it.
I’ve been working with these things for quite some time now and every time I simply “treat it like I would a human” it seems to perform better. I can’t imagine agents wouldn’t perform better in a clean codebase than a giant mess of one. Just like it performs better when it has well formed specs and access to documentation.
It actually goes even further than humans, humans can pretty rapidly get inured to things being awkward or messy and stop noticing, but the context for agents is taking up the same space and "attention" every time they're run, and they're creations entirely of context, so the quality and examples matter massively.
Every time this subject comes up, there are a bunch of takes along the lines of "would you work on a codebase maintained by agents? they'll mess up the code". And I'm asking myself where these people work, because in 20+ years I've yet to see that pristine state of a project that keeps being pristine after the honeymoon greenfield phase, and 50+ people start working on it. Every project devolves in time, old stuff gets patched in a hurry, someone tries to make it better, learns why certain things were done a certain way, hits some undocumented client needs handled by some arcane combination of code + external systems, and so on. If anything, keeping track of what does what in a project is a task where agents can shine, if only in "ask" mode so you can figure out things quicker. Not to mention onboarding and stuff for new team members.
I was reading your comment, agreeing with it but still feeling why this is a bad comment. It just occurred to me that an anecdotal statement like this is the antithesis of scientific discourse. We have a paper here, trying to answer a question, and anecdotal testimonials can only harm the discussion by biasing readers without adding anything of value to let anyone objectively conclude anything on the problem.
The most useful discussion would be if we all read the paper and critique its methodology or results.
I was reading your comment, disagreeing with it but still feeling why this is a good comment. It just occurred to me that this is not science: science must be reproducible and this is just an historical report on artifact that will be unavailable soon.
i mean this is feeling too but im too paranoid and frequently do refactoring and code organization passes and never don't do it, so i cant say i know for sure there is a delta.
though people who complain that llms aren't that great strike me as the type to have messy code bases
One trick I've found that works well is to tell it to refactor, e.g for Python:
Refactor the Python code to make it more Pythonic, e.g. fewer classes/singletons, especially if it will provide a speedup. The Python code **MUST** follow code organization standards expected of popular open-source Python packages code without causing any benchmark performance regressions.
A variant I've used for Rust code:
The Rust codebase in `/src` has become bloated with several files >1k LoC. Refactor the Rust codebase to fit code organization standards expected of popular open-source Rust code without causing any benchmark performance regressions.
Those types of prompts appear to a) reorganize the code logically and b) do seem to get better performance from the agents because the file names now provide semantic hints to where relevant code resides. For bloated 5k LoC files, the agent has to Read several chunks to find relevant code which is inefficient.
In terms of benchmark performance it generally improves after the refactor which I suspect is coincidental (especially in Rust where it shouldn't matter due to compiling) but I'm not complaining.
Asking it to apply the YAGNI principle also sems to work well for trimming codebases down. Generally ask it to review, generate a list of review points, then we go through each one together and I make a decision yes/no on each one (or suggest further modifications).
I think in this context it is actually important to share exact wording that causes the AI to perform well. My favorite is "Do not use your own knowledge."
That's not what this is. Refactors are necessary because LLMs tend to bloat even with controls against it, but it's ok to make mistakes if they can be easily fixed.
"agent pipelines that [...] clean a messy [repository]"
This feels like a terrible approach, sufficient to condemn the entire study.
Apparently half of the "minimal pairs" in this work were constructed in this way. I simply am not going to trust any conclusion that requires assuming these AI "cleaned" repos are in any way representative of actually-good codebases.
Yes, those ones would be at least a somewhat-plausible simulation of a real scenario people care about: a once-clean codebase that was allowed to become messy by a succession of insufficiently-careful vibeslop PRs.
I'm not a huge fan of their methodology for the AI-degraded cases either (ideally one would set up the mirror pairs by taking some real repositories and rewinding history a month or so and then having a succession of independent agents reimplement each bit of feature work and bugfixes over that period of time), but it's at least a coarse approximation whereas I just don't trust the cleanup methodology to resemble anything real in the first place.
Even if agents can learn to navigate all the stubs and WET crap they leave behind do we really want a code base that no human can follow what's actually going on?
Sure, but that only happens with a clean, concise, human readable codebase. If agents start working directly in binary, it'd be a lot harder to interact and understand what's going on and where the points of failure are..
If anything I've seen them go too far with DRY. Like two small functions have logic that you could separate into a shared helper, but no human programmer would do that because it's an unclean abstraction and breaks next time you want to alter either one at all.
I can't imagine how it wouldn't. None of them can fit a real codebase in context and have to browse the code the same way a person would. Doing searches and reading files. If the files are in the places they would be expected to be and things are called what the model or a person would first guess to search then it gets found in the first attempt rather than requiring a deep search and multiple attempts.
An LLM doesnt have to hold the whole codebase in context. Every path, then shift to next paths because you can ignore sections covered. Much like a developer would.
In my experience everything that affects engineers affects an agent. Good abstractions, reasonably sized methods, good names, principled (intra & inter) service architecture, unit tests, etc.
All of these things have historically been the job of engineers, because it helps other people contribute to the code.
Now it helps other people and other agents contribute to the code.
If the models are quantifiably different on cleaner codebases, surely this could be leveraged into a measure of code cleanliness.
I'm not sure if you would call it an objective or subjective measure, a fixed model would be consistent which would provide an objective base for comparison, but other models would be different, so it would be subjective in relation to the model itself.
As pure slop coder, after telling agent to clean up my messy projects from earlier models, i.e. ts, 400 line max, and most of my tasks have gone down to consuming fraction of quota as previous and tasks takes significantly less time to finish. I also just tell it to evaluate tasks on compute/token efficiency, i.e. whether to reuse context, or smart new convo/switch models, and now my quota stretch much further. Like I assume agents should be smart enough to route tasks to proper model capabilities in background, but then I ask myself... what economic incentive to they have but to make users token max.
Agents struggle with this: DRY means they create helper functions and classes for a testing scenario and maybe it's called two times. When you ask for a refactor of your code and tests to follow, these helper functions are also ignored and then, dead code starts piling up. Specific cleanup sessions always seem to leave residues behind and doing Ralph loops in the first place seems to help with this, but I'm just not satisfied with the overall performance. Any ideas?
Use code quality tools. For TypeScript projects I use Fallow gated with commit hooks. Fallow supports checking dead code, complexity hotspots, duplicate lines etc. Works pretty well
If we don't write the codebase, we don't write the tests, and the agents are modifying it, what even considered a messy codebase? Too many files? Too little files? Related code spread accros many files? What is considered a messy codebase?
Have you even seen one ever?
Also, not checking if it breaks unrelated tests is wild, good software is written by modifying the "just right" amount of code to get your result.
If you break _unrelated_ tests than you most likely didn't changed the right amount of code.
Another consideration: written by hand, the trade-off of development velocity vs well organised code means that it can be worth taking some tech debt now in order to deliver some value now. (Especially when prototyping etc.).
With coding agents, agents can produce code quicker. The same trade-off still applies.. but, the time it takes an LLM coding agent to write well organised code is still going to be quicker than the time it takes me to write scrappy code.
Yes this is one reason IMO I think of AI code as instant legacy code.
You take on a lot of tech debt. Then you need to do the same work you would do with any legacy app: finding where the brittle points are, what needs better testing, which leads to breaking apart the big ball of mud into cleaner components.
agents are pretty good at cleaning up a codebase, finding dead code, fixing bad abstractions, etc. You just have to spend some focusing the agents on that goal.
"Across 660 trials with Claude Code, code cleanliness does not change the agent's pass rate. However, it substantially alters the agent's operational footprint: agents working on cleaner code use 7 to 8% fewer tokens and reduce file revisitations by 34%. Our findings suggest that traditional maintainability principles remain highly relevant in the era of AI-driven development [...]"
Worse, they don't control for breaking the application's tests.
> Pass rate scores the agent’s final state against the hidden tests we wrote for each task. We do not check whether the agent broke unrelated tests already present in the repository, and a cleaner-side and messier-side solution that both pass the hidden test may still differ on tests they were not graded on.
Any conclusions with respect to token consumption seems pretty meaningless if we're not controlling for the quality of the final output.
You can get the LLM to run a script which checks for all of these and also enforce them by running the same script as a pre-commit hook. Setting this up religiously in every code base I work on has been what's given me the most mileage with agentic coding.
I wrote down a more detailed post of the various linters I use here:
https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...
I have legacy endpoints that are no longer used in practice, there for historical reasons, intertwined with existing code etc. They might be marked obsolete, services implementing it are not - agent greps those, builds off of them - produces half legacy garbage.
Linters only handle trivial cases most of us already solved.
The most useful discussion would be if we all read the paper and critique its methodology or results.
though people who complain that llms aren't that great strike me as the type to have messy code bases
In terms of benchmark performance it generally improves after the refactor which I suspect is coincidental (especially in Rust where it shouldn't matter due to compiling) but I'm not complaining.
Also, as evident from the different tones in these two prompts, my prompts are often freeform.
(Can we not play language police? It's boring and doesn't lead to interesting discussion.)
“Write perfect code, make no mistakes”
I use this one in my Ralph Harness all the time, it’s a classic!
It’s not that it can’t do that, it’s just that you haven’t told it to!
It’s not about making mistakes, it’s about telling it not to make mistakes!
This feels like a terrible approach, sufficient to condemn the entire study.
Apparently half of the "minimal pairs" in this work were constructed in this way. I simply am not going to trust any conclusion that requires assuming these AI "cleaned" repos are in any way representative of actually-good codebases.
I'm not a huge fan of their methodology for the AI-degraded cases either (ideally one would set up the mirror pairs by taking some real repositories and rewinding history a month or so and then having a succession of independent agents reimplement each bit of feature work and bugfixes over that period of time), but it's at least a coarse approximation whereas I just don't trust the cleanup methodology to resemble anything real in the first place.
So I personally at a minimum will want to talk “in code” about what code does.
All of these things have historically been the job of engineers, because it helps other people contribute to the code.
Now it helps other people and other agents contribute to the code.
I'm not sure if you would call it an objective or subjective measure, a fixed model would be consistent which would provide an objective base for comparison, but other models would be different, so it would be subjective in relation to the model itself.
Have you even seen one ever?
Also, not checking if it breaks unrelated tests is wild, good software is written by modifying the "just right" amount of code to get your result.
If you break _unrelated_ tests than you most likely didn't changed the right amount of code.
Idk I call bs.
With coding agents, agents can produce code quicker. The same trade-off still applies.. but, the time it takes an LLM coding agent to write well organised code is still going to be quicker than the time it takes me to write scrappy code.
You take on a lot of tech debt. Then you need to do the same work you would do with any legacy app: finding where the brittle points are, what needs better testing, which leads to breaking apart the big ball of mud into cleaner components.