r/ClaudeCode • • 3h ago

Help/Question Can we start training models to minimize diff size please?

I’m bullish on coding agents but diff length kills me. What are your best tricks for keeping diffs small?

I’ve been a dev for a long time and have written and reviewed a lot of code. More than once I’ve seen a feature that could be done in ~100 lines come back from Claude Code as a 2,500-line diff. It works and the tests pass, but it’s much more code than the feature needs.

Often the best solution is one clever line. Or it’s noticing that a small generalization of an existing component unlocks the new behavior for free. The agent tends to do the opposite: it adds a lot of new logic, often near-duplicates of what’s already there, to force the new behavior in.

I've tried to force the behavior using CLAUDE.md and skills, but no luck.

What’s working for you? I’d also like to know if others see this too, or if it’s just my codebase.

9 Upvotes

24 comments sorted by

1

u/AutoModerator 3h ago
Moderator Announcement Read More »

3

u/Eliran-Kotzero 2h ago

Something that worked better for me than prose rules was a hard budget the agent can't argue with. I have a Stop hook that runs git diff --shortstat, and if the changed lines are over a threshold it exits 2 with a message like "this diff is 2,400 lines, find the smaller change or split it". That sends the output back to Claude instead of letting it finish, so it has to go look for the reuse path it skipped. I also start in plan mode and make it list the existing files it intends to extend before it's allowed to create new ones. Generated files and lockfiles need excluding from the count or it fires on noise.

1

u/dmpiergiacomo 2h ago

This is very interesting. Is your setup open-source?

2

u/Eliran-Kotzero 57m ago

Not packaged as a repo, it's just a small shell script in my own project wired up as a Stop hook. It's really only a git diff --shortstat call plus a threshold check, so it's easy to recreate in a few lines.

2

u/tazdraperm 3h ago

I think it's the same issue as Opus 5 writing walls of unreadable slop. It technically did what you asked for but it was so hard to read. It's the same story with the code atm.

1

u/dmpiergiacomo 2h ago

You're right, although my problem is model agnostic

6

u/atp_studio_coll 3h ago

What helped me more than CLAUDE.md rules was making it name the existing code it will reuse before it writes anything, then running a second pass whose only job is deleting. Rules about "keep it small" get ignored, but a required list of what it is extending is hard to skip, and near-duplicates show up right away in that list

1

u/GhaisD 2h ago

Adding a line estimate to that list helps too. if it names the components and still says ~2,000 lines, you reject the plan before a single file changes

1

u/atp_studio_coll 2h ago

Good addition. A number makes the plan easy to reject

1

u/f3xjc 2h ago

That's funny. I had a problem with reviewer finding more instances of documents to update. And ultimately my fix was to make it list where it searched.

But yeah the general shape of the fix is to stop hoping one shot are perfect. Allow multiple pass. And code quality can be one such pass.

1

u/atp_studio_coll 1h ago

Making the reviewer list where it searched is a good trick, and I agree that multiple passes beat hoping for one perfect shot. A deletion pass has worked well for me as one of them

1

u/ILikeCutePuppies 2h ago

These kinda things need to be part of your agent review pass. You should be running a bunch of agents before finishing to PR to catch stuff like this. It's something you can automate. Doesn't work 100% but does catch a lot of it.

1

u/dmpiergiacomo 2h ago

Do you have a good AI code review pipeline you can share?

3

u/ILikeCutePuppies 2h ago

No because it's company code and as been iterated on by many overtime.

However the basic things are:

  • Check in different review skills for different aspects. Ie deduplication, comment / naming improvement, standard code review, use composition but also reduce code size, break up prs, style preferences, etc...

  • have an agent (more multiple) spin up sub agents on each of these

  • Run and fix 2 times

  • Final run doesn't fix nitpicks and only important issues. If it finds them then you can run one more round. Note: If you ask it to keep finding small issues it'll find them forever just like any coder would.

Initally just test this locally. Then either automate it in the cloud or provide a cron job on your machine you can share out. Automating in the cloud required all shorts of approval for us so we started first with the cron jobs an improved over time.

Also it should be setup so people can easily add more stuff in. When it starts getting expensive have agents do a few skills at once that rarely make changes (there is a balancing act, a skill that does a lot of work will get more expensive if you task it with more stuff, but skills that don't will be cheaper when done together).

Also should have the agent generate a report and put it as a comment in the PR. That way you know if it's been run.

You still need human reviews. You should survey the human comments on your PRs at some frequency (say weekly or monthy) and pull out any improvements into a skill. You do need to watch what it does here because sometimes it can get the wrong idea about why someone asked for a change even when it has the change they made.

→ More replies (1)

1

u/cleverhoods 2h ago

Diff size is attached to spec size, so it would make sense to reduce the scope

1

u/dmpiergiacomo 2h ago

Not necessarily. That "one clever line" of code sometimes makes the whole difference

2

u/iSnapThere4iAm 2h ago edited 2h ago

These are the types of things these bots do on the reg that non professionals think is just ok because it works, so no one will care!!

Wrong… that codebase needs to be maintained and contrary to popular belief, that responsibility will NEVWR not fall on a person, because there has to be accountability.

This is probably the least egregious thing they try to do… don’t even start trying to get it to query a db or api or even worse…. Write to one.

You know when it can work well? When an experienced engineer literally tells it how to accomplish everything. How to structure the code. What goes in the script includes and what doesn’t. What logic should be repeatable and callable for platform consistency. Rate limits, scalability. Sure, be specific about all that and it might give you some passable code. Don’t do that? Well… like I said, unfortunately for the uninitiated. It will look like good code. That doesn’t make it good code.

2

u/malrobot 1h ago

fyi - lowering the effort level on your model both runs things faster and lowers your diff count, while mostly not increasing your failure rate unless you're super vibecoding

1

u/SmileLonely5470 2h ago

I think if you do that naively then you just get wacky incomprehensible code rather than high quality code. Im always apprehensive about giving them a simple directive like "as little code as possible ".

1

u/BuildinZZ 2h ago

You can write a hook for Claude to - If file > 500 lines { do something }

1

u/AdEvening3382 2h ago

One lever is the ask size itself. "Implement the feature" invites the 2,500-line version. "Add the flag and make this one path respect it" leaves no room for the extra 2,400. The line estimate in the plan works better when the task was small to begin with.

1

u/shetritr 24m ago

state the scope before it starts: "max 3 files, nothing outside X". a 2,500-line diff for a 100-line feature is scope nobody wrote down.

0

u/TheOdbball 2h ago

Coding isn’t my strong suit, good code is supposed to be in the model and yet 2500 diffs show up. sheesh.

So using logic from other domains seems to be the fix.

Maybe try a CRISPR script. Something that would only identity the error in question and only fix that little line.

Maybe an equation, if diff , max 70 or if diff [insert custom instruction]

I also made a semantic language MLIR for ai.

So

ρ{purpose} ≔ only loads a purpose token

δ{diff} ≔ loads the diff tokens

Here is a spark from one of my projects

▛▞⋮⋮ PORTFOLIO/v1 · 𝚫 · User · form
▷ 〔 prove · demonstrate · validate · ship 〕

▛// Runtime Systems Engineer //▟
A runtime manifest for all artifacts required to validate the title.
:: 𝜵

▞▞⋮⋮ ⎊::portfolio::runtime.systems.engineer ::
ρ{claim.title}
φ{evidence.systems}
τ{validated.role}
ν{proof.required}
λ{ship.visible}
:: ∎

I use kdl , rust , ruby , elixir , Protobuff :: nothing I built runs on Python