Unfortunately we have no agreed upon metrics for simplified code.

And we have no realistic way of taking a drastically refactored application that was the result of hours of changes by an LLM and being confident that it doesn’t introduce bugs or remove load bearing bugs.

Static analysis and test suites aren’t good enough for pushing very large changes to production.

▲

ok123456 3 days ago | parent [-]

We have metrics such as cyclomatic complexity, the number of arguments, and the number of lines in a given method/function/file. These are usually fine to find the festering portions.

We also have no realistic way of being confident that letting a coworker/junior/intern make hours of changes will confidently not introduce bugs or load-bearing bugs.

	▲	sarchertech 3 days ago \| parent [-]
		Reducing cyclomatic complexity says very little about what we care about when we talk about simple code. It’s very possible, even likely to produce code with fewer branches that is much harder to reason about. Cyclomatic complexity says almost nothing about architectural complexity. There’s a reason talking about cyclomatic complexity fell out of favor 20-30 years ago. We tried using it as a software quality metric and it failed. There are no good, widely agreed upon metrics for software quality. An optimizer that tries to reduce lines of code per function or file is going to overfit to the specific version of the system at the expense of readability and maintainability. Both of these metrics will likely ensure you do the exact opposite of what you’d really want when you say you want to simplify the code. >coworker/junior/intern I would never in a million years allow anyone to go off by themselves and spend hours and hours unsupervised changing tens of thousands of lines of code with no goal but to simplify the code.