The real question is whether “debugging” the LLM is going to be as effective as debugging the code.

IME it pays dividends but it can be really painful. I’ve run into a situation multiple times where I’m using Claude Code to write something, then a week later while working it’ll come up with something like “Oh wait! Half the binaries are in .Net and not Delphi, I can just decompile them with ilspy”, effectively showing the way to a better rewrite that works better with fewer bugs that gets done in a few hours because I’ve got more experience from the v1. Either way it’s tens of thousands of lines of code that I could never have completed myself in that amount of time (which, given problems of motivation, means “at all”).

▲

ilc 4 hours ago | parent [-]

LLMs are where you need the most tests.

You want them writing tests especially in critical sections, I'll push to 100% coverage. (Not all code goes there, but thing that MUST work or everything crumbles. Yeah I do it.)

There was one time I was doing the classic: Pull a bug find 2 more thing. And I just told the LLM. "100% test coverage on the thing giving me problems." it found 4 bugs, fixed them, and that functionality has been rock solid since.

100% coverage is not a normal tool. But when you need it. Man does it help.

	▲	chrisjj an hour ago \| parent [-]
		> You want them writing tests especially in critical sections, I'll push to 100% coverage. But how do you know if you got it? I've seen no LLM that can even verify execution pathway coverage.