>Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions.

Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?

Lemme guess, you cargo culted some "best practices" to offload risk awareness, so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.

> Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?

I guess the answer (if you're really asking seriously) is that previously when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension.

So if a change was implemented, the developer would deliver it as a functional unit that might cut across several lines of risk (low risk changes like updating some CSS sitting along side higher risk like a database migration, all bundled together). Because this was what made it fastest for the developer to implement the code.

Now if AI is doing it, screw how easy or fast it is to make the change. Deliver it in review chunks.

Was the original method cargo culted? I think most of what we do is cargo culted regardless. Virtually the entire software industry is built that way. So probably.