舊程式庫重構值不值得做

092Denys Linkov（Wisedocs）18:072026-08-08 上架

Benchmarking Coding Agents on New vs Legacy Codebases — Denys Linkov, Wisedocs

Wisedocs 把超過 10 個舊 repo 併成 monorepo，Denys Linkov 用新一代模型重跑當年的任務，回頭檢查這次重構到底划不划算。

這場講了什麼

• 三個痛點逼出重構：2025 年業務擴張，Denys Linkov 的團隊碰上處理速度跟不上需求、AI pipeline 太複雜，以及程式碼散在超過 10 個 repo、沒人想碰。公司決定花六個月重構。
• 同一個任務，新模型快很多：當年把一段 Temporal 的重構交給 o3，在 Cursor 裡來回聊了三小時，出了 10 個重大錯誤。重跑之後，Sonnet 4.6 多一輪疊代就解掉，Opus 4.8 基本上一次到位。照 Denys 的估計，現在重做這次重構，時間約是當時的五分之一。
• 看成功率要看高準確率：常見的任務時長圖用的是 50% 準確率，Denys 認為要看 80% 以上，最好是 90% 或 99%，因為交出計畫和規格之後，需要的是很有把握它做得完。
• 重構之後出貨變快：合併成 monorepo 後，六個月內追平舊系統，之後持續加功能也沒有慢下來。pipeline 的時間與成本都降了，能處理更大的檔案，原本要好幾個月的功能現在一週內出貨。
• GPT-5.5 還不能一次重構：Denys 把這次 monorepo 重構當目標交給 GPT-5.5 extra high，10 分 22 秒就宣告完成，但只寫了 2,000 行，實際上是一堆 scaffolding，pipeline 裡的模型都沒有實作。
• 結論是值得做，但要留護欄：被問到「是不是該再等一年」，Denys 的答案是這次重構值得。也提醒 AI 大量產出的程式碼同樣可能變成沒人看得懂的舊程式碼，不管全面還是局部重構，都要有護欄。

影片從哪一段開始看13 段

1. 00:12開場與公司背景2025 年業務成長，處理速度跟不上、pipeline 太複雜、舊 repo 沒人想動，所以決定重構。Wisedocs 處理的是超過 10,000 頁的複雜醫療理賠 PDF。
2. 01:45技術債與品質下滑Denys 把技術債比成財務債，要算投資報酬；也指出大家出貨越來越快，產品的可靠度與程式碼的可維護性反而退步。
3. 03:46評估 orchestrator當年花約兩個月評估五個開源專案，用 17 項準則比較。Denys 有把握現在的工具能快 90%，用 deep research 加 sub-agent 來做，但品質把關照樣要有。
4. 05:09新舊模型重跑 Temporal 重構o3 花三小時、犯 10 個重大錯誤；Sonnet 4.6 多一輪疊代、Opus 4.8 一次到位。模型的做法也從要人手動介入，變成會用 sub-agent、計畫與驗證。
5. 07:00規格與開發流程的變化2025 年還在餵模型一小段程式碼，現在給一份寫得好的規格，模型多半能高水準執行；現場很多人都有過啟動 agent 後才發現 prompt、計畫或需求不完整的經驗。
6. 07:50任務時長與成功率Denys 拿 METR 的圖說明，主張看 80% 以上的準確率；METR 評估的 Mythos preview 成功率在四小時附近明顯下滑，更短的任務也有做不穩的。
7. 10:13十個 repo 併成 monorepo舊 repo 存在超過六年，進度一直很慢。合併後六個月追平，之後加新功能也沒慢下來，現在幾乎每位開發者都會提交。
8. 11:44GPT-5.5 能否一次重構GPT-5.5 extra high 10 分 22 秒就完成目標，但只寫了 2,000 行 scaffolding，沒有實作模型；Denys 說模型還不能自我驗證，但已經接近了。
9. 12:20該不該再等一年Denys 預期六個月內大型重構就能穩定完成；先講反方：模型與基礎設施一直進步，之後重構只會更容易。但 AI 產出的程式碼也可能變成沒人懂的舊程式碼，仍須有護欄。
10. 13:33結論與取捨Denys 認為值得：pipeline 更快更省、能處理更大的檔案、開發者願意進來，做法也擴散到公司其他 repo。
11. 14:51問答：monorepo 與多 repo有聽眾問 monorepo。Denys 說模型現在更會在多個 repo 間導覽，但端到端測試、驗證與部署還是多 repo 比較難，建 sandbox 時 clone repo 也花時間。
12. 16:02問答：需求驗證與 PR 審查17 項需求中，重構時判斷對了 15 項；Claude Code 剛有 plan mode 時就納入流程。重構期間 PR 全部人工審查，藉此讓大家理解改了什麼。
13. 17:07問答：影響成果的因素Denys 認為交給模型的任務複雜度會變，研究、POC、檢查隱藏假設（例如以為開源函式庫有某功能，其實還在 beta）這些工作也會快很多。

值得記的話5 句

• we're going faster and faster through the technology life cycle, but we've lost something我們在技術生命週期裡越走越快，卻也失去了某些東西02:52

• and with Opus, it was basically able to one-shot this problem用 Opus 的話，基本上一次就解掉這個問題05:58

• You don't want to be creating a plan or a spec and then have a 50-50 chance of coming back你不會想做好計畫或規格交出去，回來時卻只有一半機率做完08:37

• we're still not there where models can self-validate and just one-shot these kinds of problems我們還沒到模型能自我驗證、一次解決這類問題的地步11:59

• we can ship features that would take multiple months in under a week原本要花好幾個月的功能，我們現在一週內就能出貨13:48

名詞與人物10 個

Wisedocs

Denys Linkov 任職的公司，處理超過 10,000 頁的複雜醫療理賠 PDF

orchestrator

編排 AI pipeline 的框架，當年評估了五個開源專案

Temporal

Denys 做重構研究時用的工具，拿它的 activities 與 workflow 重現舊程式碼的行為

o3

當年交付 Temporal 重構任務的模型，來回三小時，犯了 10 個重大錯誤

Sonnet 4.6 / Opus 4.8

重跑同一任務的新模型，前者多一輪疊代解決，後者基本上一次到位

harness

包住模型的工具環境，現在的版本有 sub-agent、計畫、shell 指令與驗證

METR

發表模型任務時長與成功率圖的機構，Denys 建議看 80% 以上的準確率那條線

Mythos preview

METR 約一個月前評估的前沿模型，成功率在四小時附近明顯下降

monorepo

把 10 個舊 repo 併在一起的新程式庫，現在幾乎每位開發者都會提交

GPT-5.5 extra high

Denys 用來試一次重構的模型設定，只做出 scaffolding

提到但沒有展開

• Denys 提到 Anthropic 發表的兩個案例研究，分別來自 Spotify 與 Stripe，講的是出貨速度與重構程式碼的能力。
• 如果現在重做 orchestrator 評估，Denys 的做法是先用 deep research 對照問題陳述，再為每項準則與每個產品開 sub-agent，最後做 POC 並評估。

Agent開發工具評估產業觀察

在 YouTube 看原片 ↗