あなたの属する組織でそのルールは決まってないのでしょうか？　それはあり得ない話だと思うのですが、もしホントに決まってなければ、話し合ってルールを決めたらいかがですか。こういう所で赤の他人に聞く話ではないと思います。

そもそもが、前に書きましたように、こういう所で赤の他人に聞く話ではないと思います。

・・・が、私の個人的意見を言わせてもらえれば、「組織に属して組織の製品を開発している以上は組織のルールに従え」です。

なんのための設計書なのでしょうか？
作るもののイメージを共有するためなのか、誰かへの指示書なのか、運用・保守のための説明書なのか。

運用・保守のためなら最終的に実態と一致していれば良いのだと思います。
それが担保できるならどちらを先に修正するかはルールか、あるいは個人のスタイルではないでしょうか。

成果物として設計書も必要なら「コードか設計書か」のトレードオフではなくて「コード、設計書 > コスト」だと思います。

@SurferOnWww さんの意見に賛同です。

私個人の意見としては、ウォーターフォールにせよ、アジャイルにせよ
一度次のフェーズに移行した以上、「書類(成果物)に修正が入る」という事象が
発生すること自体がそもそも問題です。
設計書をそのままコードに落とし込めない状態なのであれば、
設計書の粒度が高すぎるので、次のフェーズに進めるべきではありません。