Thanks for your reply and book recommendation!

Quoting Accelerate book: ' Anecdotally, and based on our own experience, we hypothesize that this is because having multiple long-lived branches discourages both refactoring and intrateam communication. '

Of course, I do not mean long-lived branches. I meant an approach where developers regularly merge upstream code. Ideally, tests are also run on the merged code. I agree, long-living branches that are not regularly updated are often declined because the developer did not know how to complete them. Now, imagine if all those changes were merged into the trunk! How much efforts would be spent cleaning those up?

The ability to work in the way you specify is probably related to how competent the developers are. I have not looked into research, but the correlation may be due to the fact that experienced developers prefer to commit small changes directly while less competent teams erect "gates" so buggy code will not enter production...

I see your point. A long time ago, I also enjoyed changing scripts directly in production without tests or code reviews, and it was nearly 100% successful. There was practically zero time lost in "ceremonies." However, I can't advocate that approach to any professional programmers at least without some advanced tooling or specially built systems, which would tolerate such a way.

It may be one day we will see some AI-powered programming systems, which will perform formal code verification on the fly so one would be able to voice the wish for code change directly into production.

In that sense yes, your suggestion is nearer the magic ideal.