A paradigm shift, perhaps. Possibly, a notion of "changeset" which is more coherent with the actual code changes. For example, Unison language (https://www.unis

A paradigm shift, perhaps. Possibly, a notion of "changeset" which is more coherent with the actual code changes. For example, Unison language (https://www.unisonweb.org/ https://www.unisonweb.org/) is a good candidate. I would also like to have the following workflow (in functional language like Haskell, in more imperative language it would be trickier): Before I start working on a code change, I mark the functions and types that are to be modified. A tool then calculates a "change boundary", a set of function calls that potentially have a different semantics in the new code. After I am happy with the boundary, I will start working on a replacement code inside the boundary. The old code will still be available alongside to run and inspect during the whole development process. An automatic test suite generator will run the tests on the old code and by observing the boundary, it will automatically create a regression test suite for the replacement code. Once I am done with the new code, and it is tested, I will let the tool replace it in the defined boundary as a new change. So I will have a guarantee (through types) that I am only changing things that have to be changed, nothing else.