Graphite 公司專門從事程式碼審查工具業務，由 Tomas Reimers（前 Facebook 員工）、Greg Foster（前Google 員工）和 Meril Lutsky（前市場調查公司 Posmetrics 員工）於 2020 年創立。
Graphite 解決的核心問題與大型拉取請求 (PR) 有關，這些請求太大而無法正確審查，建議的解決方案是堆疊，將程式碼分支分解為多個拉取請求，然後單獨進行審查。這可能會在將上游更改合併到當前工作時帶來棘手的問題。
Graphite（以及其他工具）透過其 Graphite CLI（命令列介面）和 Visual Studio Code（VS Code）擴充套件解決了這個問題。
程式碼審查是人工智慧輔助的一個明顯目標，現在已成為 GitHub Copilot、Amazon Q Developer、Google Gemini 等許多工具的功能。該公司在去年 10 月推出了 Graphite Reviewer，其目的是讓開發人員在將 PR 提交給其他團隊成員進行審查之前發現其中的問題。
Graphite 現已將 Graphite Reviewer 打造成一款獨立產品，名為Diamond，並宣佈進一步獲得風險投資資金。Diamond 的功能包括檢測錯誤、樣式不一致和安全漏洞、效能問題、文件問題、可自定義規則、基於應用程式整個程式碼庫的上下文感知以及可能意外提交的程式碼（例如，為方便編寫其他程式碼而硬編碼為返回 true 的函式）。Diamond 將建議修復。
Diamond 的侷限性包括它目前僅與 GitHub 組織整合，並且 IDE 整合僅適用於 VS Code。
儘管 Graphite 正在向人工智慧邁進，但 Foster表示，“人工智慧無法完全取代人工程式碼審查……我從未看到它們成為實際人類工程師簽署拉取請求的替代品。”
Foster 描述了背景的重要性，他指的不僅是程式碼，還有業務背景。“AI 可能不知道在與客戶舉行大型會議後，你的產品路線圖發生了怎樣的變化，”他寫道。其他方面包括團隊內部的個人因素，例如對特定編碼實踐的偏愛或反對，這可能會導致程式碼不理想。“真正的程式碼審查需要領域專業知識。”
他強調的另一個問題是人工智慧不負責任。如果存在導致安全事故的漏洞，人工智慧不能承擔責任，尤其是考慮到所有人工智慧輔助有時都會出錯的警告。
Anthropic 執行長 Dario Amodei最近預測，人工智慧將在 3 到 6 個月內編寫 90% 的程式碼，但即使事實證明如此，Foster 表示“如果我們釋出的程式碼從未被人類真正閱讀或理解，人類將面臨巨大的風險。”
Foster的話相信會引起廣大開發人員的共鳴，他們擔心沒有人完全理解的人工智慧生成的程式碼可能會在投入生產時出現錯誤，從而導致無法預料的後果。
難題在於企業如何在利用 Diamond 等人工智慧工具的生產力與確保熟練的人類不會被排除在外之間取得平衡；如果開發人員讓人工智慧為他們編寫程式碼，以至於他們自己的技能受到削弱，這個問題可能會變得更加嚴重。
相關閱讀：