Scientists writing code
Your domain experts don't write the software, so implementing what they know needs to go through an engineer.
Where it goes wrong
The engineer doesn't want the scientist to write production code that they will need to maintain. The scientist doesn't want to depend on the engineers to make a crucial change. Both sides are right, which is why nobody wins the argument: the engineer considers how the code will work in production; the expert wants to know whether the science is correct.
AI removes the excuse that the expert cannot write code. So the disagreement stays exactly where it was, with the hand-off still in the middle of it.
How I'd handle it
I've collaborated on both production and prototype code with scientists from many different disciplines. That is usually enough to get the conversation moving. From there we design the ramp-up: what an expert can own end to end, and what has to be considered for their work to land safely.
Encoding the domain workflow as agent skills is one approach that works. The right one depends on your stack. After that comes coaching, on both sides, until people who were not writing code before are landing real commits.
Where I've done this
At an early-stage biotech predicting antibiotic resistance from mass-spectrometry data, I built the domain workflow and wrapped it with agent skills behind a CLI a non-developer could run. Then I coached a biochemist and a data scientist to build with it using Claude Code until both had work of their own in the repository.
UltimaAt Ultima the software engineers, the ML people and the bioinformaticians each spoke a different language. Being partway through a life sciences degree let me stand on both sides. The work that came out of that sat on the seams, like rustfrecord, a library I published to PyPI so the ML team's PyTorch code could open training data written in TensorFlow's own format.
Recognize this on your team?
