6 ms·

In my experience, Claude only knows how to spew code. Every problem you want it to solve, it translates into "more code" rather than "less code". You have to ve

In my experience, Claude only knows how to spew code. Every problem you want it to solve, it translates into "more code" rather than "less code". You have to very closely code review everything it does, otherwise your codebase is going to just grow and grow, and asymptotically approach 100% debt. I code review everything that Claude produces, and I'd estimate about 90-95% of the time, my reaction is WOW it works but too much code dude, let's take 3 hours to handhold you through simplifying it until nothing more can be removed.

tailscaler2026 6mo ago
Of course it writes a lot of code. It gets paid per token. That's guaranteed future income every additional line of technical debt.
- HoldOnAMinute 6mo ago
  Periodically you can also ask it to review the recent changes and see if there is a risk-free way to streamline them. You can also tell it to periodically summarize the "lessons learned" from the recent session(s)
- embedding-shape 6mo ago
  Then local models shouldn't suffer from the same problems, but they do. They just aren't trained in the direction of "less code == better long-term maintainability" I'd say, rather than some grand "increased-token-usage" conspiracy. You can certainly steer them a bit to reduce the issue parent talks about, but they still go into that direction whenever they can, adding stuff on top of stuff, piling hacks/shim on top of other hacks/shims, just like many human developers :)
  - bonesss 6mo ago
    Training data is the masses of code from everyone. Restrict that data to just the best of the best, the tersest of the tersest, and we’d see better output. I don’t think people are sharing that kinda stuff (Jane Street’s gems stay locked up), and even if they did my presumption is that it’d be too narrow and demanding for general audiences. Big hopes for the long future, damned to some degree of mediocrity in the near term mass product.
- layer8 6mo ago
  At some point they’ll introduce “deletion” tokens that cost ten times the regular token price. ;)
- enraged_camel 6mo ago
  >> Of course it writes a lot of code. It gets paid per token. I don't buy it. I think a much more likely reason it leans towards adding code is because deleting code carries inherent risk: it can break things in major ways or minor ways or very visibly or invisibly. Adding new code, on the other hand, is a lot safer: the only parts that can break are those the AI touched inside its own working context. So it doesn't have to go down rabbit holes and potentially create bigger and bigger messes.
operatingthetan 6mo ago
A lot of people seem to think if you give the agent a framework and clear plans that it spews "good" code. I doubt it though.
wccrawford 6mo ago
I haven't used Claude, just Sweep, Copilot and whatever Jetbrains has. But they've definitely deleted code, not just added it. I know, because they have deleted code that I definitely still needed, and I had to reject those changes and start over on the prompt.
HoldOnAMinute 6mo ago
Here's what I do Tell it "Do not change any files yet, just listen." Then we discuss the problem. Then I have it write to a file it's understanding of the change. I review that carefully. Then I let it implement. I approve each change after manually looking at it. I already know what it should be doing. Make smaller changes and check each one carefully before and after.
- dvfjsdhgfv 6mo ago
  This is a reasonable approach but has nothing to do with what is being pushed on us from all sides.
joebates 6mo ago
Same. Luckily I enjoy the process of refactoring and deleting code is nearly arousing, so I get the initial dopamine rush of wow this works, followed by the dopamine rush of "wow now this is cleaner and works so much better". Keeps me in touch with the codebase too.
- pixelready 6mo ago
  Pruning code is to software engineers what cancelling plans is to introverts :) I think I need to work up a Claude skill named marie-kondo, so that when it breathlessly presents its triumphant solution, I can go “yes, but does it spark joy?” And have it go into an aggressive refactor loop with me.
  - fragmede 6mo ago
    Sounded like fun so had Claude do one up here: https://github.com/fragmede/marie-kondo-ai-skill https://github.com/fragmede/marie-kondo-ai-skill
    - nostrebored 6mo ago
      Hypothetical future callers, "for extensibility" abstractions, single-use helpers, ceremonial try/except blocks, and options dicts with one key all get culled. — But this is never the problem. Claude WILL NOT abstract and WILL NOT use your abstractions. It finds them all “ceremonial” and the idea that you could add something that might seem indirect that actually dramatically reduces the problem space is almost impossible to convey. You can watch this in action for any API whose design you’re familiar with in a domain you understand well. If you attempt to design the same API with Claude, your will invariably get a mess of flat, insane types and no reuse. I’m talking an array of tuples of maps of set to map type insanity. What has been helping is a mandatory pass of “Claudisms”, but even then it can only find the problem and never the solution. It is so frustrating.
- suzzer99 6mo ago
  I question any dev who doesn't get aroused by deleting code. I just removed an entire graphql endpoint - 500 lines of front and back-end code. I may need to be hosed down.
notarobot123 6mo ago
At this point, it's worth asking whether lots of relatively straightforward verbose code is actually significantly worse than the least code necessary for the problem. Obviously, architecture matters. What might matter less is verbosity. The reason we aimed for minimal "accidental complexity" up to now was directly related to the cost/pain of changing and maintaining that code. Hasn't the economics of maintenance and change shifted so much that accidental complexity isn't actually all that expensive/painful? I think a bit of refactoring, renaming and restructuring has been helpful for maintainability but recently I've been a little less inclined to worry about the easy readability of function bodies and fine implementation details. It still feels wrong but I can't justify the effort anymore.
- Trasmatta 6mo ago
  > Hasn't the economics of maintenance and change shifted so much that accidental complexity isn't actually all that expensive/painful? I sincerely believe that extensive accidental complexity will ALSO be bad for AI agents. Their quality will diminish as their context windows get filled up with endless amounts of spaghetti and accidental complexity. I feel like we won't fully start feeling those effects for another year or so.
  - panflute 6mo ago
    True, yet they have a Moore's Law like growth going for properties like their context windows.. I think the larger problem with letting them be verbose is Occam's razor. The more verbose they are the more variant behavior they will have where any variation that is not strictly necessary is likely to include incorrect behavior.
    - deleted 6mo ago
      [deleted]
    - pona-a 6mo ago
      Attention is an O(n^2) algorithm. Combined with Moore's doubling, it will at best produce linear growth (assuming Moore's law is still remotely close to alive)
ddesotto 6mo ago
I think this is more a by product of the way these models are architected. “One more token” i usually much more likely than a “STOP”. Knowing when to stop and doing more with less is something also very hard for human developers. For me what throws me off most of the time is the structure on the mid-level. It usually makes sense in the loc and maybe project level, but on the file and folder level it just loses reference on what it already has or what it does not need to be too verbose about.
- monkpit 6mo ago
  > I think this is more a by product of the way these models are architected. “One more token” i usually much more likely than a “STOP”. That’s not really how it works. An agent wouldn’t get halfway through _any_ implementation and just stop abruptly - it’s not as simple as rolling the dice until you land on “stop”. It will stop when it believes, for whatever reason, the output has achieved whatever task was laid out. You’re welcome to refine what the definition of that task may be, or you can let it go off.
runeb 6mo ago
A particularly pronounced version of this can often be seen by letting 2 agents review and code in a loop. One agent will find some problems with the code, the other agent will address the review by adding more code. A good human developer might see that the better way to address the review is to backtrack and pick a different approach. The ai agents seem more prone to getting stuck down bad branches of the decision tree.
fragmede 6mo ago
Try codex.
ok_dad 6mo ago
Hey that’s my exact experience. I started coding the interfaces by hand which helps with the architecture but you still have to say, “don’t add a bunch of helpers and stuff, stick to filling in the stubs.” Then I only have to spend one hour handholding the clanker to get it perfect. I usually do a lot of manual refactoring as well during that time.
layoric 6mo ago
This was a large part of my problem with Claude code, it is far too eager to get to the code writing. Matt Pocock's skills and Codex I have found to work together quite well. You still have to ensure design/architecture is being followed, and review carefully obviously, but Codex by default seems to look for minimal change approach a lot more than Claude does/ever did.
fhub 6mo ago
I'm curious how much you have tuned your CLAUDE.md file. You can get very specific and direct about what your expectations/desires are. You can also have another agent do a critical review with your expectations/desires and feed that back.
- joquarky 6mo ago
  Just be careful to not put too much in there or it won't have enough attention left over for the tasks. Look at the doc hub pattern if your {agent}.md file is getting more than ~100 lines.
borski 6mo ago
You can also tell it to specifically focus on removing unnecessary code as a pass, and it does that pretty well.
- joquarky 6mo ago
  I do one of these occasionally and it usually finds redundancies and/or inconsistencies to clean up. It's very effective and should be part of any process involving agentic coding.
joquarky 6mo ago
It really does want to make everything overcomplicated. I end most of my pre-plan prompts with "KISS - Keep it simple" to keep it mostly under control. I also keep each file under 1000 lines and do a full scan of code and docs for cruft every 20-30 task cycles. Been working on the same project for six montha and glad to say there is minimal bloat.
denkmoon 6mo ago
>asymptotically approach 100% debt What to do if you're just one dev in an org of 50? Who are all pushing more and more code every PR? I'm gonna have to leave aren't I :(
- bigstrat2003 6mo ago
  Pretty much, unfortunately. I was recently told at my job that I need to stop being so critical of AI, and encouraged to at least pretend to use it. Never mind that I've pointed out that my disuse is not because of being stuck in my ways, but because it slows me down rather than speeds me up. I guess management wants AI use no matter whether it pays off. It's clear that my options are to embrace the clanker, or find a new job.
godelski 6mo ago
> let's take 3 hours to handhold you through simplifying it until nothing more can be removed. This is why I'm unconvinced that AI code makes me faster. Sure, I could produce a million lines an hour but are we running a sprint or a marathon? I don't know about you but I can't sprint a marathon. I think much of the world of software has become incredibly myopic. I get it, it's a lot harder to win a war than it is to win a battle but just usually taking the easy way out is just deferring the costs to your future. Problem is that those costs accrue interest... Personally? I'm lazy and a cheapskate. When did programmers stop becoming lazy and start becoming lazy? More importantly, why?
- yarn_ 6mo ago
  > I think much of the world of software has become incredibly myopic. > usually taking the easy way out is just deferring the costs to your future. Problem is that those costs accrue interest. This sums up my thoughts perfectly lately, that is a great way to put it all. Programmers have never been any good at measuring or estimating their own productivity, there is no reason to assume that has changed (one could argue theres ample reason to assume the opposite). Part of the problem as well is that there is some unseen/unnamable "spaghettiness"/"sloppiness"/"whatever" factor, that scales very very poorly. At the beginning it can seem fine, especially when you have some constant speed multiplier like an LLM spitting out code - but the larger exponent of the function that results from this factor being "worse" will eventually outpace that constant multiplier. You will only see it once its too late, or will never see it all because of our myopia as you say.
zrn900 6mo ago
> Every problem you want it to solve, it translates into "more code" rather than "less code" Try Deepseek or Xiaomi's Mimo. They produce very lean code.
KurSix 6mo ago
[dead]
eric_cc 6mo ago
Multiple rounds of specialized sub agent peer reviews that are prompted to counter this works really well. Once you have the right pipeline in place you should not be needing to do the simplifying yourself very often. Claude -> specialized sub agents peer review -> specialized sub agents peer review -> repeat as many times as needed It’s not worth your time until you’ve run through such a pipeline.

tailscaler2026 6mo ago

Of course it writes a lot of code. It gets paid per token. That's guaranteed future income every additional line of technical debt.

HoldOnAMinute 6mo ago
Periodically you can also ask it to review the recent changes and see if there is a risk-free way to streamline them. You can also tell it to periodically summarize the "lessons learned" from the recent session(s)
embedding-shape 6mo ago
Then local models shouldn't suffer from the same problems, but they do. They just aren't trained in the direction of "less code == better long-term maintainability" I'd say, rather than some grand "increased-token-usage" conspiracy. You can certainly steer them a bit to reduce the issue parent talks about, but they still go into that direction whenever they can, adding stuff on top of stuff, piling hacks/shim on top of other hacks/shims, just like many human developers :)
- bonesss 6mo ago
  Training data is the masses of code from everyone. Restrict that data to just the best of the best, the tersest of the tersest, and we’d see better output. I don’t think people are sharing that kinda stuff (Jane Street’s gems stay locked up), and even if they did my presumption is that it’d be too narrow and demanding for general audiences. Big hopes for the long future, damned to some degree of mediocrity in the near term mass product.
layer8 6mo ago
At some point they’ll introduce “deletion” tokens that cost ten times the regular token price. ;)
enraged_camel 6mo ago
>> Of course it writes a lot of code. It gets paid per token. I don't buy it. I think a much more likely reason it leans towards adding code is because deleting code carries inherent risk: it can break things in major ways or minor ways or very visibly or invisibly. Adding new code, on the other hand, is a lot safer: the only parts that can break are those the AI touched inside its own working context. So it doesn't have to go down rabbit holes and potentially create bigger and bigger messes.

operatingthetan 6mo ago

A lot of people seem to think if you give the agent a framework and clear plans that it spews "good" code. I doubt it though.

wccrawford 6mo ago

I haven't used Claude, just Sweep, Copilot and whatever Jetbrains has. But they've definitely deleted code, not just added it. I know, because they have deleted code that I definitely still needed, and I had to reject those changes and start over on the prompt.

HoldOnAMinute 6mo ago

Here's what I do Tell it "Do not change any files yet, just listen." Then we discuss the problem. Then I have it write to a file it's understanding of the change. I review that carefully. Then I let it implement. I approve each change after manually looking at it. I already know what it should be doing. Make smaller changes and check each one carefully before and after.

dvfjsdhgfv 6mo ago
This is a reasonable approach but has nothing to do with what is being pushed on us from all sides.

joebates 6mo ago

Same. Luckily I enjoy the process of refactoring and deleting code is nearly arousing, so I get the initial dopamine rush of wow this works, followed by the dopamine rush of "wow now this is cleaner and works so much better". Keeps me in touch with the codebase too.

pixelready 6mo ago
Pruning code is to software engineers what cancelling plans is to introverts :) I think I need to work up a Claude skill named marie-kondo, so that when it breathlessly presents its triumphant solution, I can go “yes, but does it spark joy?” And have it go into an aggressive refactor loop with me.
- fragmede 6mo ago
  Sounded like fun so had Claude do one up here: https://github.com/fragmede/marie-kondo-ai-skill https://github.com/fragmede/marie-kondo-ai-skill
  - nostrebored 6mo ago
    Hypothetical future callers, "for extensibility" abstractions, single-use helpers, ceremonial try/except blocks, and options dicts with one key all get culled. — But this is never the problem. Claude WILL NOT abstract and WILL NOT use your abstractions. It finds them all “ceremonial” and the idea that you could add something that might seem indirect that actually dramatically reduces the problem space is almost impossible to convey. You can watch this in action for any API whose design you’re familiar with in a domain you understand well. If you attempt to design the same API with Claude, your will invariably get a mess of flat, insane types and no reuse. I’m talking an array of tuples of maps of set to map type insanity. What has been helping is a mandatory pass of “Claudisms”, but even then it can only find the problem and never the solution. It is so frustrating.
suzzer99 6mo ago
I question any dev who doesn't get aroused by deleting code. I just removed an entire graphql endpoint - 500 lines of front and back-end code. I may need to be hosed down.

notarobot123 6mo ago

At this point, it's worth asking whether lots of relatively straightforward verbose code is actually significantly worse than the least code necessary for the problem. Obviously, architecture matters. What might matter less is verbosity. The reason we aimed for minimal "accidental complexity" up to now was directly related to the cost/pain of changing and maintaining that code. Hasn't the economics of maintenance and change shifted so much that accidental complexity isn't actually all that expensive/painful? I think a bit of refactoring, renaming and restructuring has been helpful for maintainability but recently I've been a little less inclined to worry about the easy readability of function bodies and fine implementation details. It still feels wrong but I can't justify the effort anymore.

Trasmatta 6mo ago
> Hasn't the economics of maintenance and change shifted so much that accidental complexity isn't actually all that expensive/painful? I sincerely believe that extensive accidental complexity will ALSO be bad for AI agents. Their quality will diminish as their context windows get filled up with endless amounts of spaghetti and accidental complexity. I feel like we won't fully start feeling those effects for another year or so.
- panflute 6mo ago
  True, yet they have a Moore's Law like growth going for properties like their context windows.. I think the larger problem with letting them be verbose is Occam's razor. The more verbose they are the more variant behavior they will have where any variation that is not strictly necessary is likely to include incorrect behavior.
  - deleted 6mo ago
    [deleted]
  - pona-a 6mo ago
    Attention is an O(n^2) algorithm. Combined with Moore's doubling, it will at best produce linear growth (assuming Moore's law is still remotely close to alive)

ddesotto 6mo ago

I think this is more a by product of the way these models are architected. “One more token” i usually much more likely than a “STOP”. Knowing when to stop and doing more with less is something also very hard for human developers. For me what throws me off most of the time is the structure on the mid-level. It usually makes sense in the loc and maybe project level, but on the file and folder level it just loses reference on what it already has or what it does not need to be too verbose about.

monkpit 6mo ago
> I think this is more a by product of the way these models are architected. “One more token” i usually much more likely than a “STOP”. That’s not really how it works. An agent wouldn’t get halfway through _any_ implementation and just stop abruptly - it’s not as simple as rolling the dice until you land on “stop”. It will stop when it believes, for whatever reason, the output has achieved whatever task was laid out. You’re welcome to refine what the definition of that task may be, or you can let it go off.

runeb 6mo ago

A particularly pronounced version of this can often be seen by letting 2 agents review and code in a loop. One agent will find some problems with the code, the other agent will address the review by adding more code. A good human developer might see that the better way to address the review is to backtrack and pick a different approach. The ai agents seem more prone to getting stuck down bad branches of the decision tree.

fragmede 6mo ago

Try codex.

ok_dad 6mo ago

Hey that’s my exact experience. I started coding the interfaces by hand which helps with the architecture but you still have to say, “don’t add a bunch of helpers and stuff, stick to filling in the stubs.” Then I only have to spend one hour handholding the clanker to get it perfect. I usually do a lot of manual refactoring as well during that time.

layoric 6mo ago

This was a large part of my problem with Claude code, it is far too eager to get to the code writing. Matt Pocock's skills and Codex I have found to work together quite well. You still have to ensure design/architecture is being followed, and review carefully obviously, but Codex by default seems to look for minimal change approach a lot more than Claude does/ever did.

fhub 6mo ago

I'm curious how much you have tuned your CLAUDE.md file. You can get very specific and direct about what your expectations/desires are. You can also have another agent do a critical review with your expectations/desires and feed that back.

joquarky 6mo ago
Just be careful to not put too much in there or it won't have enough attention left over for the tasks. Look at the doc hub pattern if your {agent}.md file is getting more than ~100 lines.

borski 6mo ago

You can also tell it to specifically focus on removing unnecessary code as a pass, and it does that pretty well.

joquarky 6mo ago
I do one of these occasionally and it usually finds redundancies and/or inconsistencies to clean up. It's very effective and should be part of any process involving agentic coding.

joquarky 6mo ago

It really does want to make everything overcomplicated. I end most of my pre-plan prompts with "KISS - Keep it simple" to keep it mostly under control. I also keep each file under 1000 lines and do a full scan of code and docs for cruft every 20-30 task cycles. Been working on the same project for six montha and glad to say there is minimal bloat.

denkmoon 6mo ago

>asymptotically approach 100% debt What to do if you're just one dev in an org of 50? Who are all pushing more and more code every PR? I'm gonna have to leave aren't I :(

bigstrat2003 6mo ago
Pretty much, unfortunately. I was recently told at my job that I need to stop being so critical of AI, and encouraged to at least pretend to use it. Never mind that I've pointed out that my disuse is not because of being stuck in my ways, but because it slows me down rather than speeds me up. I guess management wants AI use no matter whether it pays off. It's clear that my options are to embrace the clanker, or find a new job.

godelski 6mo ago

> let's take 3 hours to handhold you through simplifying it until nothing more can be removed. This is why I'm unconvinced that AI code makes me faster. Sure, I could produce a million lines an hour but are we running a sprint or a marathon? I don't know about you but I can't sprint a marathon. I think much of the world of software has become incredibly myopic. I get it, it's a lot harder to win a war than it is to win a battle but just usually taking the easy way out is just deferring the costs to your future. Problem is that those costs accrue interest... Personally? I'm lazy and a cheapskate. When did programmers stop becoming lazy and start becoming lazy? More importantly, why?

yarn_ 6mo ago
> I think much of the world of software has become incredibly myopic. > usually taking the easy way out is just deferring the costs to your future. Problem is that those costs accrue interest. This sums up my thoughts perfectly lately, that is a great way to put it all. Programmers have never been any good at measuring or estimating their own productivity, there is no reason to assume that has changed (one could argue theres ample reason to assume the opposite). Part of the problem as well is that there is some unseen/unnamable "spaghettiness"/"sloppiness"/"whatever" factor, that scales very very poorly. At the beginning it can seem fine, especially when you have some constant speed multiplier like an LLM spitting out code - but the larger exponent of the function that results from this factor being "worse" will eventually outpace that constant multiplier. You will only see it once its too late, or will never see it all because of our myopia as you say.

zrn900 6mo ago

> Every problem you want it to solve, it translates into "more code" rather than "less code" Try Deepseek or Xiaomi's Mimo. They produce very lean code.

KurSix 6mo ago

[dead]

eric_cc 6mo ago

Multiple rounds of specialized sub agent peer reviews that are prompted to counter this works really well. Once you have the right pipeline in place you should not be needing to do the simplifying yourself very often. Claude -> specialized sub agents peer review -> specialized sub agents peer review -> repeat as many times as needed It’s not worth your time until you’ve run through such a pipeline.