@zenkat @dngrs so, with those qualifications about my own lack of experience out of the way, there are still things I see as potentially risky with the code-refactoring use case you describe.

first, there's a hidden cost there, which is by removing this pain, there's also less pressure to *avoid* designing big calcifying API surfaces like this, and no motivation to build other more reliable tools to handle these types of migrations when they do happen.

@zenkat @dngrs (again, in the open source library-with-multiple-clients world, this would just never be an option for me; even if I could just sledgehammer my *own* code with an LLM and it worked perfectly, we still need a migration glide path for all of our users, many of whom are similarly constrained in their ability to apply LLMs for various reasons)

@zenkat @dngrs but, the changes to the tests weren't trivial to recognize; it was specifically inverting assertions *in ways which were difficult for human reviewers to see*, particularly when reviewing lots of tedious and repetitive tests. and only *some* of the tests were changed, of course, *most* of the app code was migrated. it was like a crafted DDoS attack on the reviewers' attention span. and this is what I would expect an LLM to do based on my model of its operation