I ended up doing this when switching our 50k-LOC codebase to pnpm workspaces, and it was such a good experience. It still took me a day or two of moulding that script to get it to handle the dozens of edge cases, but it would have taken me far longer to split things up by hand.

I still feel like I am under-using the ability of LLMs to spit out custom scripts to handle one-off use-cases.

I run LLMs against a 500k LoC poker engine and they do well because the engine is modularized into many small parts with a focus on good naming schemes and DRY.

If it doesn't require a lot of context for an LLM to figure out how to direct effort then the codebase size is irrelevant -- what becomes relevant in those scenarios is module size and the amount of modules implicated with any change or problem-solving. The LLM codebase 'navigation' becomes near-free with good naming and structure. If you code in a style that allows an LLM to navigate the codebase via just an `ls` output it can handle things deftly.

The LLMification of things has definitely made me embrace the concept of program-as-plugin-loader more-so than ever before.

> The LLM codebase 'navigation' becomes near-free with good naming and structure

I have not found this to be true. They seem to break badly if you have a lot of files with similar-ish names even if they're descriptive.

And I would never want to use a piece of software written by you ever.

If you think that writing the code was the hard part, your code was probably always shite.

I'm sure there's a lot of poorly tested code I use, that doesn't mean I want to use it. :)

In fact, I see a lot of broken things in the wild, frequently.