Experts outside the code
Your domain experts don't write the software, so implementing what they know needs to pass by an engineer.
Where it goes wrong
Both sides are right, which is why nobody wins the argument. An engineer reads the code against what production will do to it. What the expert wants to know is whether the science is correct, and neither question contains the other.
AI does not settle that. It removes the excuse that the expert cannot write code, and leaves the disagreement standing exactly where it was, with the hand-off still in the middle of it.
How I'd handle it
I have sat in the engineering seat and in the science seat, and can be taken seriously in either, which is usually enough to get the conversation moving. From there we design the on-ramp: what an expert can own end to end, and what has to be true before their work lands safely.
Encoding the domain workflow as agent skills is one approach that works, and the right one depends on your stack. After that comes the coaching, on both sides, until real commits are landing from people who were not writing code before.
Where I've done this
At an early-stage biotech predicting antibiotic resistance from mass-spectrometry data, I turned the domain workflow into agent skills and wrapped the pipeline in a CLI a non-developer could run. Then I coached a biochemist and a data scientist until each was landing real commits.
Ultima's software engineers, ML people and bioinformaticians each had a working vocabulary the others did not share. Being partway through a life sciences degree is what let me stand on both sides of it, and the work that came out of that sat on the seams: rustfrecord, which I published to PyPI, let the ML team's PyTorch code open training data written in TensorFlow's own format.
Recognize this on your team?
Let's talk