- Basic style/linter rules (so you don't get 200-line functions, etc) paired w/ instructing your agent how to use them goes a long way (e.g., a sane rubocop.yml in your repo, plus a note in AGENTS.md telling the agents how to run rubocop, or whatever makes sense for your language) - I have a code review skill that specifically calls out human-readability concerns such as making sure that identifier names represent their contents and intended use
The other key IME is that you need to make readability/refactoring passes outside of a particular pull request. When working on a specific branch the LLMs will be somewhat myopic, and do stuff that looks pretty good in isolation, but when you zoom out and look at the bigger picture it's kind of a mess - for example, often they'll duplicate some code that existed elsewhere.
The LLMs are also pretty good at generating Mermaid charts and tracing execution flows, which is a great way to understand code. It doesn't help them to produce more readable code but it helps me to understand code I'm unfamiliar with.
Yep, it will generate what ever you ask for but if you want to have some sort of exploratory work, immersion, feeling of ownership and genuinely a connection with the things you are building - a part the build loop should belong to you.
Maybe this is an attachment of people who built things in other ways. Maybe the perceived value of applications will drop to near 0 and you will end up having all in one apps or voice wants like to a star trek replicator. Fun things are coming, but humanity will need to adjust hard - best case scenario.