Quality is usually observed from a human perspective. But in my experience, codebases that humans would judge as "low quality" are actually fine for LLMs. They don't have as much trouble as we do with spaghetti code. They don't have problems with readability or obscure syntax, it's all perfectly fine for them. They don't care about indentation either.

Also it's really easy to increase the quality of the code base. You can just prompt to add unit test coverage and it will. You can prompt the LLM to handle edge cases better and it will (you don't even have to specify which, it helps, but it's optional). If you want to have better separation of concerns, just ask the LLM to have more separation of concerns and you'll have it. Documentation lacking? Just one prompt away. More robust build pipeline? You get the idea.

1. Usually the commit message is often too short to capture the "why" adequately. 2. It is very beneficial to capture the why in one single source of truth, and that usually is not the Git commit message in a business context. Hate on Jira all you want, but if you capture the "why" there, you can add comments, view history, add rich context, link dependencies, add rich context, etc. Can't do that in a Git commit message.