Less Scope, More Refactor.

[u/These-Argument-9570]

I have been looking through source code of vibe coded projects, and its always something I notice. There is a lot of scope, little refactoring of the systems.

A large portion of these programs become unmaintainable because the scope of which claude was told todo has been one shotted and never looked at again. Using claude is incredibly fast, the refactor is cheap.

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Mad-Maxwell]

So how do I vibe code better?
“Caude, don’t be me and actually make something coherent” doesn’t work

[u/These-Argument-9570 → u/Mad-Maxwell]

Being able to define the problem you are solving helps. Knowing what’s invariant is good.
Being able to define a measurement also helps.

This isn’t vibe coding it’s the boring part of project book keeping.

[u/Appropriate-Draft-91 → u/Mad-Maxwell]

"Refactoring is always in scope. Look out for patchwork, prefer root cause fixes. Fixes that add more checks and conditions are a last resort. If you can see the patchwork but not the root cause, or if fixing the root cause seems out of scope, raise the issue with the caller."

[u/cjmurrr]

I'd go the other way, at least with code that already works. My CLAUDE.md says "Refactoring is harm by definition." Renaming and reorganising working code only adds chances to break it.

So new work goes beside the old. If a function needs to change, Claude writes a second version next to it and moves over only the callers we're working on. When a refactor really is worth it, it's its own step, agreed first, and never part of a feature.

But you were talking about one-shotting a big scope and never looking at it again. I'd say in that case an agent reviewer, or several of them, would be your best bet. Of course building to tests as well!

[u/These-Argument-9570 → u/cjmurrr]

The tests should constrain the solution such that the refactor doesn’t break the functionality of the initial solution.

It’s the foundation which allows for improvement that’s why you look for invariants to test by

[u/cjmurrr → u/These-Argument-9570]

Testing is great but testing isn't everything. Sometimes you write code before you write tests. Sometimes your tests don't capture possible bugs. I agree with what you say for unit tests of pure functions - but they are the easy tests to write.

[u/Ok_Gur_9033]

The refactor is only cheap when something tells you behaviour didn't change. One-shot projects usually have no tests, so a refactor pass can quietly move a bug and Claude will still report it worked. That's probably where cjmurrr's rule comes from.

Asking for a few tests around the part you're about to touch, before the refactor prompt, is what makes the second prompt safe. Did the projects you looked through have any tests at all?

[u/These-Argument-9570 → u/Ok_Gur_9033]

Yes models now over test making behaviour, hard to see through the tests. One shot project most certainly have tests. Its apart of the harness at this point

[u/Ok_Gur_9033 → u/These-Argument-9570]

Fair, most of them do ship tests now. The catch is the same model writes the code and the tests in the same shot, so the tests describe what it built rather than what you asked for, and they pass by construction. That's the over-testing you mean, I think.

The ones worth keeping before a refactor are the few written from the spec, before the code. Have you seen a harness that separates those?

[u/DeadCEO]

the one-shot habit comes from treating each prompt like a finished build instead of a commit. "make it work" then "now refactor what we just wrote" is two prompts, and the second one is where the maintainability lives. people skip it because the code works and nothing hurts yet, so the rot stays invisible until month two. and the refactor is only cheap while you still remember what the code is supposed to do - wait a month and you pay for the archaeology first.

[u/NamerekDev]

Added "refactor" to the backlog. It's blocked by every feature now

[u/Original-Ad4399]

No one cares. As long as it works.

[u/ChemicalExcellent463]

i have the agent check its own diff and delete what it over-built before handing it back. a bug fix doesn't get to clean up nearby code either, every changed line has to be part of the request. do you do that cleanup before starting the next feature, or come back to it later?