Hard to Change doesn't mean Hard to Break

Recently at work I was presented with the goal of fairly drastically changing our build and code organization process, which includes but was not limited to:

1) Changing from a single repo to multiple repos

2) Moving code into packages to use across multiple repos

3) Large changes to processes that are currently working, around branching and other workflows.

4) Changes to how we are organizing code

It should be understood that as it stands today I am the only person that is working in this code base, and our simple approach has been effective and at least at the current time there is no major reason to change this. So, of course I pushed back a little - asking why did we feel like we needed to change a process that isn't broken, and has lead to a largely stable and highly productive product (just in the last year, I have been able to deploy dozens of mission-critical services, each composed of between one and up to a dozen features).

The response was that, yes while things are working now, when we grow they might not work great, so we should change things somewhat to make them work for when we grow.

My response was that we should wait until we have a problem before fixing it - the proposed changes will, even if done perfectly (and what is done perfectly?) reduce productivity by making the project much harder to work on in some cases (in the case of multiple repos, you have to change projects to change code, and in the case of the packages, editing and deploying a package, never mind keeping your current packages up to date locally, on your services, etc.. is a pain that will eat into time as you want to quickly get features deployed - and don't get me started on the proposed workflow changes, which I don't even want to think about again because I already have a headache - this just smells all around to me).

The feedback I received was amazing: it was the goal of these changes was to make things harder to change in parts of the code, because if they are harder to change, they are harder to break!

Let that sink in. The goal of this would be to make it hard to change certain things, like code that is shared among multiple projects, and to make it harder to deploy certain things to certain projects. I asked a few times. Harder to change? Are you sure? You don't mean something else - you mean you want people to struggle to change code that drives business logic, in a fast-paced startup?

The answer was yes, because if it is hard to change, it will be hard for new developers to introduce errors .. !!

Of course, little to no thought was put into the fact that we will want to fix current, existing problems quickly without having to jump through a bunch of hoops. After all, the code is working right? So it must work forever.

Is anyone hiring?