Not really. User Experience typically applies to the frontend. What the user sees and experiences.

That said, you could,in an abstract way, say Understandablity is the UX for the development team. Works for me ;)

> What the user sees and experiences

Eh, depends how you define "experiences" and "sees".

A lot of people think UX is about aesthetics and animations which is mostly false.

UX is more about usability and testing a product with real users.

UX is User Experience (external to the product).

This would be DX, Dev Experience (internal to the product).

Not saying you're wrong, but DX to me is more related to writing code, using commands, etc, not so much the understanding of how the project works.

Also, developers using something are also users, no?

It gets blurry. The bigger question is: can you reason about changes to the system. You need enough overall project and code-local context to do that. Nothing fixes spaghetti code, but tooling can improve you ability to model what is going on. IDEs can give live context inferred via static analysis, or pull together definitions from different files. REPL for introspection can be a big boon. Frameworks forcing conventions help with the principle of least surprise. Good CI/CD practices, create strong feedback loops that improve code quality rather than letting deadlines allow for not fully-understood code to slip through due to aggregate complexity, etc ...