Rails, Phoenix, and similar web frameworks are seemingly designed with this as an underlying goal. They make an attempt to help you organize your web service into conceptually separate slices of domain logic ("resources"), and to organize each piece of each slice into a purpose-specific area of the codebase (model, view, migration, controller, services, script, stylesheet, etc). They also create homes for code that must be shared, for cross-cutting concerns (literally called "concerns" in Rails). So when you're working on a particular problem, you can think of it in terms of "I need to make a change that will affect just models", or "... a change that affects just the Users resource" and clearly identify which parts of the code need to be changed, and which don't. Of course, this falls apart in the real world, because resources are often tightly interdependent and it's hard to draw clear boundaries.

Elm does a little bit of this by using static types to enforce automatic semantic versioning, but that only really helps at the library level, not within a single codebase.

Rich Hickey gave a talk about safely evolving software and what the semantics around it are, but his recommendations were pretty controversial. Here's the HN discussion, so that you can get some meta commentary along with the talk itself if you'd like. https://news.ycombinator.com/item?id=13085952

Maybe I linked the wrong talk

I was thinking of the one where he proposed never making breaking changes. If you need to make a breaking change, make a new thing with a different name instead.

TBH I’m not sure a new language that replaces all other languages will truly transform the industry. IMO a new level of programming (call it top-level or cloud-native) should just be glue for polyglot microservices+functions+openapi+graphql+etc. — I’m still in shock that we (as a community) think a new one-size-fits-all language with an attitude of throw everything else out will resonate. It’s Smalltalk all over.