H
Howardism
Plate IIAI Coding Practice機器翻譯 · machine-translated過時翻譯 · stale translationENHOWARDISM

AI 作為主要作者

PublishedJune 17, 2026FiledConceptDomainAI Coding PracticeTagsAI Coding WorkflowAgent EngineeringCode AuthorshipReading7 minSourceAI-synthesised

Faros 2026：助理→作者的門檻在沒有刻意決策的情況下跨越；AI 程式碼接受率從 20%→60% 上升；「不是助理，而是作者」；人類從創作轉向監督，使問題成為作者問題，而非審查問題

AI 作為主要作者的插圖

資料來源#

摘要#

Faros AI 對其 2026 年遙測資料所記錄之結構性轉變的描述：AI 已從助理跨越為作者——「大多數組織都沒有刻意做出這項決定」。其標誌是接受率：AI 生成的程式碼被接受並納入程式碼庫的比例，從 20% 上升至 60%（Faros 的兩組資料集）；主要推動力是 Cursor 與 Claude Code 在 agent mode 中執行，讓 agent 直接套用變更。「助理與作者的區別在實務中已經消失。不是助理，而是作者。」

vendor-claim 來源——證據上的注意事項請見 Acceleration Whiplash。60% 是承載整個論述的數字，來源歸因於 Faros 的平台遙測資料。

是門檻，而非斜率#

之所以這是一個概念而不只是指標，是因為轉變悄無聲息且具有結構性地發生了。最初的承諾是「人類掌控全局，AI 提出建議，人類做決定」。隨著模型進步、供應商野心擴大，「副駕駛變成了同儕」，而接受率逐漸超過人類仍具有實質作者角色的程度。沒有任何組織召集會議決定「AI 應該撰寫我們大部分的程式碼」；使用率只是上升了（授權早已購買——改變的是使用方式，而非席位），直到某一天，60% 被接受的程式碼都有 AI 作為作者。轉變在於由誰／什麼來完成工作，人類「日益處於審查與監督角色，而非創作角色」。

這與 Fiona Fung 在 Anthropic 內部所描述的角色倒置相同，也與 Karpathy 將其框定為代理式工程的觀點一致——但 Faros 提供了整體產業層級的數字，說明這項轉變在更廣泛的產業中走了多遠，並將其視為問題，而不是能力。

「是作者問題，而非審查問題」#

報告最尖銳的後果。因為 AI 是作者，品質落差源自生成階段，無法在審查階段補救：

「品質落差並沒有在審查階段被發現……要說清楚，問題不在於誰審查程式碼，而在於送來審查的程式碼本來就沒準備好。這是作者問題，而非審查問題。」

這重新界定了整套補救策略（見 Acceleration Whiplash）：增加審查者或收緊門檻，只是在處理症狀。修正方式是提升作者產出的品質——在 AI 作者開始撰寫之前，就為它提供程式碼庫標準、架構意圖、安全限制與測試要求，讓輸出從一開始就更接近可發布狀態。這是 shift-left 在作者身分上的對應版本：把品質投資一路左移到作者行為本身。

作者身分／責任落差#

作者身分轉移給了 AI；責任卻沒有轉移。「你仍然要為自己的軟體負責」（Karpathy），然而產出 60% 程式碼的實體無法被追究責任，沒有對意圖的持久記憶，也不是根據程式碼庫的演進方式，而是從「某個時間點」推測架構。結果就是工業規模的複合債務機制：每次工作階段都重新推導意圖的作者。Faros 的第 10 項建議——提供「context engine」，從歷史中傳遞意圖——試圖賦予 AI 作者人類作者默默持有的那項能力。

邊界：作者行為與代理式作者行為#

Faros 劃出清楚界線。AI 是主要作者，且人類仍在迴圈中——但代理式作者行為（agent 獨立撰寫、提交，並在沒有任何人類啟動的情況下送出 PR）目前仍只占 PR 的 <1%。Faros 認為這個 <1%「目前是件好事」，並警告完全移除人類會讓每項品質壓力都「放大一個數量級」。因此，這裡的「主要作者」是指人類接受大部分由 AI 撰寫的程式碼，而不是agent 在無人監督下發布。與此同時，代理式審查已從 PR 的 0%→25%——監督層的自動化速度，比作者層走向自主化的速度更快。

相關連結#

  • Acceleration Whiplash — 下游後果：接受率達 60% 的 AI 作者，正是淹沒人類節奏系統的來源
  • Vibe Coding 與代理式工程 — Karpathy 所說的「你仍然要為自己的軟體負責」，正是作者身分／責任落差中的責任部分
  • 驗證成為新瓶頸 — 人類作為審查者而非創作者，正是 Fiona Fung 所指出的瓶頸轉移；Faros 補充：「但你無法在審查階段修正作者行為」
  • 代理式技術債 — 沒有持久意圖的作者會在每次工作階段重新推導架構；「context engine」就是組織規模的 CLAUDE.md
  • Software 3.0 — 以英文程式設計，是 AI 能夠成為作者的基本範式
  • Claude Code — agent mode（直接套用變更）被點名為接受率從 20%→60% 飆升的主要推動力
  • 印刷機式軟體民主化 — 作者身分轉移給機器，是同一場民主化的供給面
  • Compute Allocator — 如果人類不再是作者，其殘餘角色就是決定作者應該把精力花在哪裡
  • 規劃／執行分工 — 表面上的矛盾可以如此化解：Faros 的 60% 程式碼行作者身分與 Anthropic 約 70% 的人類規劃決策比例，衡量的是不同層次——Claude 撰寫大部分程式碼行（執行），而人類仍掌握大部分規劃。「沒有刻意做出決定」與「人類仍決定要建造什麼」兩者都是真的
  • 代理式編碼的工作組成轉移 — 更多端到端的代理式使用（操作／分析／撰寫），是作者身分向 agent 移動的使用面；作者如何工作，工作就如何轉移
  • 從對話到委派的轉移 — 委派生產本身就是作者身分轉移給 agent；Codex 的輸出 token 占比（16.5% / 63.3% / 99.8%）呈現這項轉移在不同群體中走了多遠
  • 對話產物 — 產物是作者身分轉移給模型，並以每次對話為單位變得可測量；閱讀程度提升（Claude 的回答約比提示高出一個教育年級）是衡量輸出有多少來自模型的一項指標
  • 審查作為控制點 — 該理論的驅動因素，正是從作為審查輸入的作者身分轉移中看到的現象：數量／速度、表面可信度，以及程式碼不透明性（意圖遺失）。其中「啟動 agent 的開發者，是獨立審查者，還是審查自己作品的作者？」這項模糊性——它會翻轉獨立審查趨勢的方向——正是本頁「當 agent 直接套用變更時，接受究竟代表什麼？」在審查面向的對應問題

開放問題#

  • 60% 這個數字彙總了非常不同的工具與模式（自動完成接受與 agent 套用的差異）。當 agent 直接套用變更，而人類的「接受」只是沒有還原變更時，「接受」究竟代表什麼？審查作為控制點讓問題更加尖銳：在 GitHub 上，agent PR 最常見的情況是只有啟動 agent 的開發者進行檢查（僅作者審查占 40.1%，人類 PR 則為 21.5%）。這是否算審查，本身就是定義上的選擇（agent 作為作者 ⇒ 另一雙眼睛；agent 作為工具 ⇒ 自我審查），而且會直接翻轉趨勢方向——因此「接受」與「審查」逐漸模糊成同一個尚未解決的構念。
  • 如果代理式作者行為從 <1% 跨向兩位數，在 context-engine 工具成熟之前，whiplash 是否會先變得無法管理——還是工具會因為這股壓力而成熟？

資料來源#

§ end
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Cited by 24
Related articles