This is the main thing that raises my eyebrow.
If you are constantly churning your codebase to the point that you need to invent a system that handles your churn... then you must at least be admitting that the previous 6 refactors you wrote were not good, but NOW you have it right.
I feel that good, well designed code change by accretion, not by rewrites. Code that remains stable for a long period of time was likely better than code that needs be continuously rewritten (at least with humans writers).
But maybe this is just a human-centric view of what good code means? That LLM "slop it until it works" approach to development will have a different measure of what quality looks like?
idk, over the past 2 weekends i have a repo for hacking on fujifilm camera firmware that's gone from zero to tens of gigabytes: i've got an emulator for older arm cpus like the one in the X70 (2016), a Hypervisor.framework VM for running their newest AArch64 software for X100VI (2024), a complete C re-implementation of the x70 source, many tools for injecting code and executing on live camera RAM over USB. the emulator has gone through 3 rewrites: first it was python and naive, then it was python with hot parts in rust with a more mature device interface, and now it's rust with some cold or experimental devices still python.
i really don't want to brick my camera, so the deterministic emulator stack lets me do integration tests end-to-end. if i was doing this by hand with no ai, i'd probably have to run stuff on the camera just to test it. but because ai, i get deterministic simulation testing, at the cost of needing to burn $100 of subscription on it.
ai code is more like clay you gotta continuously keep shaping over time, but you can also get very very far, very quickly if you decide the code itself doesn't matter and all you care about is results.