There is a story engineering teams tell themselves about research code: it is a prototype, it was never meant to ship, and the responsible thing is to rewrite it properly. Sometimes that is true. More often the rewrite quietly drops the details that made the result work, and nobody notices until the metric moves.
Research code and serving code optimize for different things. One is written to be changed twenty times a day by the person who wrote it; the other is written to be read at three in the morning by someone who did not. Neither is the sloppy version of the other, and treating the first as a draft of the second is how the details get lost.
The parts that are cheapest to preserve and most expensive to rediscover:
- The exact preprocessing, including the steps that look like they should not matter.
- The numerics — dtype, reduction order, and anything that was tuned to make a result stable.
- The default values somebody chose deliberately and never wrote down.
The version that has worked for us is narrower and duller: keep the research path runnable, make the serving path prove it agrees with it, and only then let the two diverge on performance. It is slower up front and it removes an entire category of argument about whether a regression is real.