In general, is it worth trying to improve this interaction with developers at all? Why should the customer also think about it? The customer pays, so let the developers think about how to improve this interaction, right? Incorrect.

Why it is BENEFICIAL for the customer to have effective interaction and good relations with developers.

If the relationship is good and the interaction is built competently:

will work faster, more accurately (the developer will not constantly cover his .opu from the customer's sanctions);
developers will offer solutions that the customer himself is not able to take into account;
The developer will not play it safe in estimates of budget and deadline (in case the customer starts throwing out tricks on changes in requirements in the process of work).
If the relationship is bad:

programmers are re-mortgaged (they understand that the customer will squeeze out the maximum);
they begin to do strictly according to the technical specifications, and not as best for the project;
constantly be on the safe side, coordinate every sneeze with the customer, so that later, in case of problems, they will poke at "you agreed on it yourself";
avoid unnecessary interaction (reducing communication to a minimum, long feedback);
Do not offer anything at all for the project in terms of improvements.
Next, we'll break down the elements that allow you to improve this interaction. This should come from both the developer and the customer.

Conflict, loudness, hysterics in communication and the search for the guilty or honest open relationships
This greatly simplifies the life of the programmer, when there is no need to constantly unravel the client's half-hints in terms of negativity. In our practice, there were clients who constantly keep you in semi-tension without any constructive solutions. Usually this is the frame of the problem (who is to blame, why it happened, etc.). That is, the task is not to move forward quickly, but to sort things out and find those to blame. Working on such projects is very uncomfortable and completely inefficient. Instead of writing code for a project and working through tasks, time is wasted on endless calls about nothing.

If the relationship is normal, constructive and all the innuendos are said immediately and kindly - everything is much simplified, there is no such oppressive emotional background. Mistakes happen. There is no getting away from it. It is they who often become the subject of such micro-conflicts.

If every mistake turns into a conflict with the topic of who is to blame, the programmer will simply look for a way out of such a project.

It is important to agree on normal interaction to quickly solve problems and minimize such errors.

Some people like to squat on the ears of a manager or developer. Instead of writing code for the customer's project, the developer listens to the economic situation in the country. For a programmer, their resource is time. There is no need to squander this resource in vain.

If you give a task to a programmer, immediately indicate the significant details: screenshots, addresses, logins. They will ask for it anyway to solve the problem - there is no point in forcing him to do it. Give everything in one bag at once.

Level the complexity of the programmer's work ("it's very easy to do") or respect the work of the programmer
Some customers try to manipulate the assessment of the task, saying that it is very easy to do. They think that the programmer cannot admit "this is a difficult task for me and I can only do it in 3 hours", and he will agree to do it in 1 conditional hour. This manipulation is obvious and unpleasant, and it spoils the relationship.

Immediately there is a desire to say: "If you are so smart, then why don't you do this task yourself during this time, at the same time you will save a little."
It is better to do the opposite - emphasize the importance and complexity of the work. Praise for a good result. Give specific adequate feedback in case of inaccuracies.

What if the programmer still winds up the grade? In these situations, you need to request a detailed description of the task.
He estimated, for example, the task at 30 hours. It seems to you that it is too much - request the details of the task in parts. Also compare this to other estimates in the project. Another option is to have an internal technician who can adequately assess the complexity of the work and the time required.

Give idiotic advice when you don't understand the field of development at all or entrust the developer with the solution of technical issues
Often the client gives his "sensible" technical advice with the best intentions. But most of such advice is inappropriate, detached from reality and does not bring any benefit. It is much better to act at your level. At the customer level. Namely, to accurately formulate your business needs. Justify their importance for business. Make informed decisions on complex issues.

If you climb into the territory of the program, then it is like a passenger of an airplane begins to give recommendations to the pilot or, worse, climbs into the onboard equipment.
A dangerous consequence for the project can be the loss of a developer. When they start giving you stupid advice on your specialization from an amateur - the sensations are below the baseboard. That is, it negatively affects the developer's self-esteem. He can get a little discouraged and just leave the project (in our practice, this happened - the client began to give valuable comments on SQL queries, although he did not have even basic knowledge on this topic.

Push through the will in the project (try to circumvent objective restrictions at the expense of who knows what) or listen to reasonable arguments
If a solution allows you to do something flexibly, this does not mean that you need to constantly make hyper-complex decisions under the slogan "I want it this way". The public loves stories about Steve Jobs and his manial pursuit of perfection. But this is a survivor's mistake. And how many of these jobs never launched? 99% Why didn't they launch - there was simply not enough money, or the solution is too complex and not particularly necessary.

Any system has its own objective limitations. Bypassing them through crutches is a bad idea. Sooner or later, these crutches will break off and everything will fall. Or it will be a living hell to support such a decision.
When the system is highly sophisticated for everyone, a new implementation is more and more difficult and expensive. Prioritize simplicity and organicness. If a new feature doesn't fit neatly into your system, don't implement it.

And it is very important to listen to the arguments of experts. A strong will is good, but without brains, it will simply ruin the project.

Constantly bargain or take the right approach to budget optimization
A programmer is usually an introvert. It is the internal orientation of the programmer that allows him to concentrate on tasks for a long time. They don't like to bargain. If they are constantly pressed, they will either find a simpler customer (who can't stand the brain for every little thing), or find a way to reduce costs at the expense of the quality of the project.

If you need a discount, then it must be given for something. The customer can offer something and ask for a discount for it.

For example, write an article about working on a project or post a link on your website (advertising the developer's services). Or the customer can take on part of the work (in theory it is beautiful, in practice it does not work very well).

The cost and terms can always be reduced. This is done at the expense of volume.
Need a smaller budget? Let's remove some of the work. The main thing is that the estimate should be sufficiently detailed.

What if the other party shows the negative signals described above?
First, you need to understand how it happened that you work with such a person. That is, you need to improve your filtration system, otherwise history will repeat itself in the future.

Secondly, it is necessary to try to clarify relations, build new expectations, and agree on the observance of certain agreements. Basically, the problem arises in different expectations and approaches. It is important to understand in which aspects you differ.

Thirdly, if you are fundamentally dissatisfied with something, there is always a way out of interaction. But the way out should be environmentally friendly, so that your partner gets out of them with minimal losses and discomfort.

Everyone has their own principles of work. It's normal when you're not ready to sacrifice them for the next client or performer.

Findings
By fixing these points, your interaction with the developers (and other performers) will reach a new level. Monitor the appearance of negative factors in time (both on your part and on the part of your partner) and uproot them immediately. In this case, your garden will always give a good harvest.