They just want to build because they already just know what they should build.
Is that an assumption on your part? Isn't it our job to help challenge the assumptions people make about other people, particularly why they do what they do, and what motivates their behavior? How do you know their "gut" isn't right?
User research is supposed to be about understanding the behaviors, needs and motivations of users, but I don't often see that applied that to the people we work with.
Yes, developers and engineers and builders often have strong opinions about what will be better or worse for users. Knee-jerk resistance to UX testing is sometimes due to perceptions what we're doing as this heavy, hand-wavy departmental concern that can only slow the work down, and for dubious benefit.
Ever sat through a mandatory 2-hour meeting about sitting up straight at your keyboard? That's how some developers think about UX testing.
Skepticism is nothing personal, fortunately, and I would argue it's actually a good opportunity to get better at your craft. One part of that is studying the people you work and taking their needs seriously.
They often have the same motives as you: they just want to see their work come to life. They are the immediate customers of UX testing efforts, so progress depends on their contributions.
Help them help you. Dig into their hypotheses, and use their assumptions as the basis for your UX testing. You'll find that when you make a case with reason and involve them in the research, they not only lighten up but may actually loop you in and defer more of the research questions your way. You never know - maybe they're tired of defending decisions to one another and would welcome some help from an objective approach.
Make a point of understanding how early UX testing applies to what they're doing, and be able to explain that in layman' terms. Don't carpet-bomb the same generic explanations some UX professionals give each other, i.e "better and more usable products" or "greater empathy" or something equally subjective and non-falsifiable. Tailor the story to the audience.
For example, project managers' ability to deliver on deadlines is only as good as their ability to accurately size effort. Early UX testing helps reduce project uncertainty by focusing project scope around work which has been validated with customers.
With developers, you can strike the same nerve a different way. Good programmers make disciplined reuse of patterns, and in my experience they don't want to make code additions or changes without a compelling business case and pressure from management. UX testing designs with customers before actually building them can help take some of the pressure off developers so they can just code without fear they're "building the wrong thing."
UX testing is not a silver bullet of course, but unless they're eating the dog food it is a lot better than guessing.
Ultimately, we all work for the customer and are on the same team. It's not enough to know about testing, doing this work well is about understanding people. Find a way to defuse some of those tense conversations that happen during push-back, you may find uncover some great opportunities.