It is almost structurally impossible for this to happen in a team that follows an agile model like scrum, since the whole system is designed around user stories, wireframes/mockups created by UX people (or product owners if the team can't afford a usability person), graphic design, coding, testing (multiple layers: unit, acceptance, alpha, beta), compiling of user feedback, rinse and repeat.

In this kind of environment, developers should be demanding more UX talent on the team, not resisting it, since they typically don't like doing it themselves. In fact the iteration loop can't really work without someone doing UX systematically.

If you really are facing a team that works the way you describe, I can think of several potential diagnoses, but without further data it is hard to tell what's going on, and the solution is different in each case:

1. It is an older, non-agile s/w team that is not used to iterative development (coming from waterfall Java work or something), and not used to frameworks where UX work fits naturally. In this case the solution may be to champion adoption of agile processes and iterative development, and leave if you don't get a hearing (you do not want to work with dinosaurs).
2. It is a product for programmers, by programmers, and they actually DO know better than you, since they are the customers. In this case, there isn't a problem.
3. As Xianhang says, you are letting yourself get caught in he-said-she-said type arguments instead of using data (or if they don't let you get the data, good design comps etc. to illustrate your points to the audience)
4. You are working with incremental improvements to old, legacy software where the programmers do in fact know a lot already from past experiences (happens often in enterprise s/w), and the relevant data is in things like bureaucratic processes.
5. The situation is full of complete idiots (which is what you make it sound like, but this is a rare enough situation that I am not inclined to believe you)