The way around this, and again you have to get management and customer support, is to bring maintenance activities into every iteration. Create systems that can detect issues and errors early (more comprehensive testing, new testing styles like fuzzing and property-based testings; moving critical portions to statically typed languages or adding type annotations; etc.). Make addressing those issues a priority, some portion of your time in each iteration should be spent addressing concerns or increasing the ability to detect issues. Over time, when I've seen this done, it's made making changes much faster, even for larger changes. But without this, even "trivial" changes can end up taking months, instead of days or weeks.
[0] https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....
[1] https://www.systemdynamics.org/assets/conferences/2017/proce...
I think she’s the one that gave me the phrase “capability trap” and Google found these and other articles.
In this case it's generally an attractive nuisance for business logic, aggregation, data transformation etc, which means that after a while
1) extracting the proxying is hard and
2) you can't understand a service without reading the code in multiple layers, since some of it's business logic is in the proxy layer. Big balls of mud can be big, distributed balls of mud.