Design and code are one job.
Design is about patterns, and a pattern only exists in code. When the person who makes a decision also sees what was built, the intent does not get lost.
Most teams are organised around two roles, because design and engineering have traditionally been separate jobs. A designer makes the UI, and an engineer builds from it. People say that design and engineering pull against each other, but both sides want the same result. The friction comes from how the work was divided.
Most of the design never reaches an engineer, because design is really about patterns. A pattern is a problem that recurs, with a known solution, such as how a product moves, how it answers a person, and what happens when a person goes back and forth between two screens. The UI that a designer hands over is static. It does not move, it does not show context, and nobody can use it or test it as it is. A prototype can imitate a pattern, but it is a second copy of work that the code must do again. In the end, the patterns get decided again in code, often by someone who does not know they are design decisions, and design has to continue there, all the way to production.
At Womp, I design and maintain Womp's Design System, and the interface gets all of its components from it. A change goes into the package as a new version, and the app moves to that version. Specialists in geometry and rendering write the 3D engine, and the package is the boundary between their work and the interface.
Intent gets lost between people. The reason for a decision stays with whoever made it, and it rarely survives the trip to whoever builds it. When the same person makes a decision and sees what was built, nothing has to travel, and the next decision gets better.