OpenAI 發表了一份實地報告，整理研究人員運用程式設計代理（coding agent）改造科學運算軟體的 8 個專案[1]。這些專案集中在基因體學等資料量龐大的領域，其中 5 個只使用 Codex，另外 3 個則搭配 Codex 與 Claude Code。長期因人力不足而被擱置的研究用軟體維護工作，究竟能交給代理處理到什麼程度，這份報告做了實地檢驗。
論文附帶的程式碼，就這樣成了研究基礎設施
科學運算是學術界與產業界共同的支柱，但報告的出發點相當直接：軟體的演進速度跟不上資料產生的速度[1]。許多被廣泛使用的研究工具，最初只是隨論文附上的程式碼，撰寫者是不具軟體工程背景的小型學術團隊，能投入打包、測試、最佳化與長期支援的時間相當有限。
留下來的，是緩慢、脆弱且需要不斷修補的研究基礎設施。OpenAI 在報告中引用了針對已發表研究程式碼與體學工具的先行研究，指出這類軟體經常無法在全新的運算環境中順利安裝，或是無法照著說明文件運作[1]。研究人員因此把大量時間花在設定與除錯上，發現的步調也跟著變慢。
8 個案例，5 個僅用 Codex、3 個搭配 Claude Code
這份實地報告收錄以生命科學為主的 8 個專案，每則案例都由負責的團隊自行撰寫[1]。內容從日常維護、局部加速，一路涵蓋到大規模的語言遷移與以 GPU 為前提的重新設計。
其中一個具體例子，是用來讀寫基因體變異資料的 Python 函式庫 cyvcf2 的現代化。GPT-5.5 將其老舊的建置與打包機制，換成能一併處理安裝、測試與發布的新做法[1]。cyvcf2 是以 Cython 包裝 htslib 的高速 VCF 解析器，由猶他大學的 Brent Pedersen 與 Aaron Quinlan 開發，並以 MIT 授權公開[2][3]。它的起點是一個很實際的問題：面對動輒數千萬筆變異的研究，既有函式庫的速度並不夠用[2]。
cyvcf2 的作者 Pedersen 在報告中表示：有了程式設計代理，要走得快很容易；但就目前來說，要在科學上走得遠，仍然需要專家的引導與理解、品味與細心[1]。
瓶頸已從實作轉移到驗證
各團隊的共同感受之一，是研究人員的角色從實作轉向驗證與統籌[1]。決定要做什麼、定義如何衡量正確性、判斷何時算完成。科學方向與品質標準仍握在人手上，代理負責的是把速度拉起來。
另一方面，代理雖然能把範圍明確的委託處理得不錯，卻無法自行判斷成果在科學上是否站得住腳[1]。即使成果中含有明顯錯誤，它們也經常表現得很有把握。因此人工驗證必須仰賴外部基準或可量測的驗收標準，例如輸出與既有工具完全一致、統計行為是否合理，或是否吻合事先以模擬資料備妥的答案。
推進方式也不是一次到位，而是分階段反覆修正。團隊把大目標拆成較小的變更，透過中途的基準測試與測試環境逐步收斂。初版實作往往很快就能產出，但處理邊界情況與細微的數值差異卻費時許多，所謂的最後一哩路成了最吃重的階段[1]。
由誰接手維護
實作成本一旦下降，相似的重寫就容易大量出現。使用者被分散，用來維持單一工具可靠性的專家心力也被稀釋，這是報告點出的風險[1]。成熟的軟體之中，藏著未寫進文件的慣例、相容性要求，以及長年累積的使用者信任，光是移植原始碼並無法重現。
8 個專案的做法各有不同。MHCflurry 與 cyvcf2 的變更被併回原本的專案主線，而 rustar-aligner 則因原專案已遭棄置，轉由新的社群接手管理[1]。報告的結論是：只要還能與既有維護者協調，就應盡早展開；若確實需要另做一套實作，就必須有明確的負責人與可信的維護計畫。否則，今天的現代化重寫，只會變成明天的棄置程式碼。
總結
OpenAI 公開的這份實地報告，以 8 則案例說明 Codex 等程式設計代理確實正在降低科學軟體的維護、遷移與最佳化成本。但判斷成果在科學上是否成立，仍舊是人的工作，瓶頸已從實作轉移到驗證。代理越快，誰要長期持有這些工具的問題就越沉重。
來源[1]: https://openai.com/index/scientific-computing-agentic-ai
來源[2]: https://academic.oup.com/bioinformatics/article/33/12/1867/2971439
