BTW, you can avoid your comments being flagged and killed by writing them yourself! I know it’s tempting to offshore it to AI (especially after you’ve vibe-coded a whole project) but some genuine human communication goes a long way.
BTW, you can avoid your comments being flagged and killed by writing them yourself! I know it’s tempting to offshore it to AI (especially after you’ve vibe-coded a whole project) but some genuine human communication goes a long way.
The only thing is that these issues seem like human code problems and IME LLMs don’t really write code like this anymore. It’s almost the opposite in python, actually, where Claude leans on writing lots of 2-3 liner private utils which is a separate kind of complexity and organization problem.
I still find it useful specifically for React where it’s frustratingly normalized to write many branches in your JSX though.
Instead of focusing solely on the complexity of the thing you change. Include the context around what you are changing also.
This allows the Change Impact formula to differentiate between two different files of the same length. One is a complex god class with high CC. The other is an entity module that is simple but just has a lot of methods due to properties. Adding to the god class really should warrant a refactor. Adding to the entity class is just another field to store for the entity. The Change Impact formula can differentiate and point to the god classes.