這份報告記錄了八個案例研究,主要集中在生物學領域,研究團隊在其中使用了 Codex 和 Claude Code 等程式碼代理。這些專案涵蓋了從基礎維護、針對性優化到使用現代程式語言進行全面重寫等不同範疇。
這些程式碼代理在多個專案中展現了顯著的效率提升,有些甚至達到了超過 60 倍的速度。
其中一個較為簡單的專案是現代化 cyvcf2,這是一個用於讀取遺傳數據的 Python 函式庫。GPT-5.5 將其過時的建置和安裝流程替換為現代化的方式。
MHCflurry 的遷移工作則複雜得多。MHCflurry 是一個免疫學模型,用於預測免疫細胞將識別哪些目標。Claude Code 和 Codex 在將約一萬行程式碼從 TensorFlow 移植到 PyTorch 的過程中,輪流扮演開發者和審閱者的角色。
rustar-aligner 專案則更具野心,它使用 Rust 從頭開始重建了 STAR。STAR 是一種將細胞測序讀數對應到基因組中相應位置的工具。原始版本包含超過兩萬行 C 和 C++ 程式碼,且已不再積極維護,儘管它仍是許多研究流程的一部分。
為了檢查重寫後的工具是否與原始版本行為一致,團隊使用來自酵母細胞的一萬個短測序讀數對兩種工具進行了測試。對於單端讀數,rustar-aligner 在 99.815% 的情況下產生了與 STAR 相同的結果。對於配對端讀數,一致率為 99.883%。
這項比較不僅涵蓋了基因組中的映射位置,還包括了兩個程式為每個讀數產生的其他幾個關鍵欄位。兩種工具都沒有映射出對方未能映射的任何讀數。
RustQC 透過將 15 個獨立的品質控制工具整合到一個程式中,實現了最大的速度提升。在一個大型數據集上,運行時間從 15 小時 34 分鐘縮短到 14 分鐘 54 秒,速度提升了 60 多倍。
另一個專案 HelixForge 則將一個用於生成合成基因組數據的工具,替換為可在 GPU 上運行的版本。在一項使用單一捐贈者數據和一千萬個鹼基對基因組片段的測試中,HelixForge 完成整個流程的速度比 BamSurgeon 快了 59.6 倍。僅主要計算步驟就快了 98.6 倍。
儘管程式碼代理能大幅提升速度,但快速的程式碼仍可能產生錯誤的科學結果。綜合這些案例研究,程式碼代理能快速完成定義明確的任務,但卻無法可靠地判斷其工作是否在科學上正確。即使程式碼中包含錯誤,這些系統也經常以十足的信心呈現結果。
cyvcf2 的開發者 Brent Pedersen 寫道:「有了程式碼代理,要快速推進工作非常容易;但就目前而言,要在科學領域走得更遠,仍然需要專家的指導、理解、判斷力和細心。」
領導 RustQC 專案的 Philip Ewels 形容程式碼代理「能言善道、具說服力,並且自信滿滿地犯錯,而這些錯誤卻很容易被忽略」。他從不允許模型判斷自己工作的準確性,而是建立了一個獨立的測試框架。
bayesm 的案例研究顯示了這些錯誤有多難以察覺。其 Rust 重寫版本的運行速度比原始版本快了兩到二十倍,但其中兩種進階方法的第一個版本包含的錯誤,僅從輸出結果很難發現。
在其中一種方法中,代理程式顛倒了一個關鍵的控制參數,導致程式使用了預期值的倒數。另一個錯誤則影響了計算本身。研究人員僅在針對數千個已知結果的合成數據集進行詳細校準測試後才發現這些問題。
另一種名為 HART 的方法,儘管整體產生了看似合理的結果,但仍包含數個缺陷。這些缺陷包括不必要的昂貴計算,以及一個比例不正確的校正因子。單憑看似合理的測試結果,並不足以證明程式碼是正確的。
2025 年初,MHCflurry 移植到 PyTorch 的早期嘗試曾以失敗告終。開發者 Sergey Feldman 現在將失敗歸因於當時可用的模型,而非程式碼工具本身。他認為,只有較新的模型世代才變得足夠可靠,能夠獨立處理大部分這類工作。
這些專案遵循了一致的分工模式。人類負責定義目標、成功標準和驗證方法,而代理程式則負責實作。
hifiasm 專案展示了這種模式在實踐中如何運作。Hifiasm 從許多短片段組裝出完整的基因組。在要求 GPT-5.5 進行優化之前,研究人員建立了一個包含獨立訓練和驗證數據集的測試環境。模型隨後找到了將真實人類基因組數據運行時間縮短近 15% 的改進。
HI.SIM 是一個用於模擬遺傳數據的函式庫,所需的人工參與甚至更少。GPT-5.2 在一次運行中就找到了優化程式各個部分的方法。使用更新的模型進行第二次運行則發現了更多改進。這些改動總共將運行時間減少了約 31%,同時沒有改變輸出結果。
低成本的重寫也帶來了維護問題。作者們也提供了潛在節省的粗略估計。如果程式碼代理能夠解決影響研究軟體的所有安裝問題的四分之一到一半,那麼在 100 個套件中節省的研究時間價值將在 60 萬美元到近 500 萬美元之間。僅 NumPy 一項,報告估計代理程式每年可節省約 650 小時的維護工作。
長期維護與驗證和科學準確性一樣,仍然是一個重大的未解決問題。低成本的重寫可能會分散使用者社群,並進一步稀釋經驗豐富維護者本已有限的時間。
各團隊對於所有權和維護採取了不同的方法。有些改動直接整合到原始專案中。由於 STAR 已不再維護,rustar-aligner 轉移到了 scverse 研究聯盟。FastQC 的作者拒絕用 Rust 重寫版本替換原始工具。相反地,團隊將其發現的改進添加到了原始 Java 版本中,同樣實現了三倍的速度提升。
這份實地報告回顧了已完成的專案,並依賴於相關人員的敘述。作者們強調,這些發現並非來自具代表性的研究。他們仍然認為,主要瓶頸已從程式碼本身轉移到驗證、科學審查以及對維護和未來發展的明確責任。
相同的模式也出現在研究領域之外的軟體開發中。METR 的一項研究發現,實際的專案維護者會拒絕約一半被廣泛使用的 SWE-bench Verified 基準測試評為通過的解決方案。
一項關於開發者對 AI 生成程式碼感到沮喪的研究也發現了類似的權衡。生成程式碼所節省的時間,可能反而花費在審查上。curl 專案在 AI 生成的漏洞報告耗費了維護者大量時間卻未產生有用結果後,關閉了其錯誤獎勵計畫。
這份實地報告是 OpenAI 拓展科學領域的更廣泛努力的一部分。該公司成立了一個由 Kevin Weil 領導的專門科學團隊,他預計 2026 年對科學領域而言,將如同 2025 年對軟體工程領域一樣重要。今年四月,OpenAI 推出了用於生命科學研究的模型 GPT-Rosalind,並發布了一個免費的生命科學 Codex 外掛程式,該外掛程式將模型連接到 50 多個公共數據庫和生物學工具。
