I like my supervisor but not how he does things; What do I do?

First, research doesn't come with a specification with all details ironed out. In most cases, many things are undefined and unknown; hence, it is called research. We could change direction at any time, especially when we realize there is a better problem or the problem at hand is rubbish. Consequently, the code in academia is pretty bad, poorly designed, and ad-hoc as compared to what you find in the industry; although codes in the industry can be one bowl of spaghetti too.

On your question, think about the problems at hand. Try to plan them out as best as you can. Collect evidence to justify the strength and weakness of a given tool/solution. Bring these pieces of evidence to your supervisor. If he/she is rational, he/she will either side with you or give you better reasons to not go a certain way.

One important part of being supervised is to learn to know when you are likely to know better than your professor. You can expect him to know the broad field better than you, and be a good judge of whether a broad strategy is likely to work, or if it has been tried before and failed.

You should be the better expert in your particular dataset, instrument, etc. You are the one working with it, you know the problems and the technologies, you are the one that calls the shots.

I have had to reject all sorts of ideas of my supervisors because the data was too noisy, too biased, the idea would solve the wrong problem, or they misunderstood something. Sometimes, this lead to a second round of ideas that corrected the original problem, or me ignoring the idea and going on with my choice. (In fairness, I have also rejected ideas that were actually good, but that is the cost of learning). With time, we all learned what each other is better at, my supervisor gives me more advise on the areas that I need, and I can judge better when the ideas are applicable.

There is one sentence that raises a concern:

having been given the green light by my supervisor, respecting his decision that it would work fine

I don't know how your workflow is, but I know that my supervisor is not familiar with the details of my code. His way of finding bugs is by looking at the results, and comparing with what he would expect. If there is a mismatch, he will ask for further analysis to either bound the problem, or convince himself that the results are correct.