「不是我寫的，但我要負責」：AI Coding 正在改寫軟體工程的責任邊界

假設你叫 AI 幫忙完成一個學生註冊系統的新功能。

LLM 很快產生修改內容。

你看了一遍 diff。

看起來沒什麼大問題。

Approve。

Merge。

Deploy。

幾天後，新生開始註冊。

程式執行到其中一行：

1 / 0

系統直接拋出未處理例外。

學生註冊失敗。

接下來真正麻煩的問題才開始。

那一行 Code 到底是誰寫的？

是提出需求的工程師？

是產生 implementation 的 LLM？

是批准 Pull Request 的 reviewer？

還是部署這套系統的公司？

2026 年 9 月，巴西聖保羅大學 Institute of Mathematics, Statistics and Computer Science 的 Augusto Camargo 發表研究筆記《It Is Not My Code Anymore》。

它不是一篇測量 AI Coding Bug Rate 的實驗論文，也沒有宣稱 AI 產生的程式一定比較危險。

作者在論文首頁就明確指出：

這是一篇討論 authorship、responsibility 與 evaluation 的研究筆記，使用的是一個假想失敗案例以及對既有研究的選擇性整理，沒有新的 empirical results。

真正的問題不是：

「AI 會不會寫 Bug？」

因為人類本來也會寫 Bug。

作者真正想問的是：

當 implementation 的實際生產者不再一定是人類工程師時，我們原本建立在『工程師寫 Code』這個前提上的責任制度，還合理嗎？

一行 1 / 0，把四個不同問題全部拆開

論文一開始故意選擇了一個極端簡單的錯誤。

LLM 在實作某項功能時產生：

1 / 0

工程師指定目標、選擇模型、可能經過幾輪 prompt 與 revision，最後閱讀 diff 並批准修改。

但是作者指出：

真正產生那個 expression 的仍然是模型。

Reviewer 看過這行程式，不會因此改變它最初由誰產生。

這個看似語意上的小區別，其實會讓現代 AI Coding 出現至少四個完全不同的問題。

第一個問題：

Authorship — 誰產生了程式碼？

第二個問題：

Ownership — 誰把這份程式視為『我的 Code』或『我們的 Code』？

第三個問題：

Release Responsibility — 誰有權批准它進 production？

第四個問題：

Operational Responsibility — 系統真的壞掉後，誰必須修復服務？

在傳統軟體開發裡，這幾個角色經常高度重疊。

一個工程師可能：

自己寫 Code ↓ 自己測試 ↓ 自己 Review ↓ 自己 Deploy ↓ 自己 On-call

所以「誰寫的」和「誰負責」很容易被當成同一件事。

但 AI Coding 開始把它們拆開。

Human → 定義 Intent

LLM → 產生 Implementation

Reviewer → 接受或拒絕修改

CI / Test → 驗證部分行為

Organization → 部署與維運

於是問題變成：

同一個 failure 可以有很多參與者，但每個人的責任並不相同。

「My Code」本身其實一直是一個很模糊的詞

Camargo 用了一個很生活化的類比。

如果有人說：

「This is my ride。」

那可能只是代表：

這是我平常搭的車。

不代表他：

設計了這台車

製造了這台車

甚至不一定擁有這台車。

同樣地，工程師說：

「這是我的 Code。」

可能至少代表幾種不同意思：

我親手寫的。

我負責維護的。

我從別人手上接手的。

我所在團隊擁有的。

出了問題我要修的。

Generative AI 只是讓這個原本就存在的模糊性突然變得非常明顯。

因為現在真的可能出現：

我負責這份 Code，但大部分 implementation 不是我產生的。

AI 寫得越多，人類的 Ownership 感可能真的越低

論文引用 Seo、Deldari 與 Mentis 在 2026 年發表的《Whose Code Is It?》研究。

那項研究有 30 名參與者。

研究結果顯示，隨著 AI 在程式產生中的自主程度與貢獻增加，受試者對程式的 perceived possession，也就是「這是我的東西」的心理感受會下降。

同時，他們更傾向把 authorship 歸給 AI。

但有一件事情沒有同步下降得那麼明顯：

對 production system 承擔 accountability 的意願仍然相對穩定。

這形成一種非常有 AI Coding 時代特色的心理狀態：

這不是我寫的。

我甚至不太覺得它是『我的 Code』。

但是：

出了問題還是我要處理。

Camargo 同時引用另一項 AI 文字生成研究。

研究發現，人們甚至可能對 AI 生成的文字缺乏強烈 psychological ownership，但在公開場合仍然把自己描述為作者。

因此至少有三件事情不能混為一談：

Feeling ownership

Claiming authorship

Accepting responsibility

它們可以同時存在，也可以彼此分離。

Review 過 AI Code，不會自動讓你變成作者

這是整篇論文最尖銳的一個觀點。

現在很多 AI Coding 工作流程其實建立在一個隱含假設上：

AI 寫 Code沒關係。

反正 Human Review 最後會看。

因此：

AI generates ↓ Human reviews ↓ Human approves ↓ 就還是『Human-written software』

但 Camargo 不接受這種描述。

他認為 review 一段已經存在的 diff，可以構成 release responsibility，卻不會改變那段 implementation 最初由誰產生。

換句話說：

Review 可以改變這段 Code 能不能進 Production，但不能改寫它的生產歷史。

這就是標題《It Is Not My Code Anymore》真正的意思。

作者並不是主張把法律上的 Code Ownership 交給 AI。

也不是說：

「不是我寫的，所以我不用負責。」

反而恰好相反。

他的核心主張是：

Authorship 與 Responsibility 必須被拆開分析。

你可以不是某行 Code 的 producer，卻仍然因為你的角色、權限與 duty，而必須為它進入 production 負責。

「AI 幻覺」其實不是最重要的問題

如果 LLM 產生 1 / 0，我們很容易說：

「AI hallucinated。」

但 Camargo 認為，對事故調查而言，這個描述幫助其實有限。

因為一旦 expression 已經寫進程式：

1 / 0

它執行時的行為就是完全 deterministic 的。

Generator 也許是 probabilistic。

但是：

它可以產生一個百分之百 reproducible 的 Bug。

所以事故發生後真正該問的是：

這行 expression 怎麼進入系統？

Review 為什麼沒抓到？

Test 為什麼沒抓到？

Release process 為什麼允許它部署？

為什麼 failure 最後真的影響學生？

這和單純把問題標記成「LLM hallucination」是完全不同層級的工程問題。

「我們共同創造的」其實也沒有回答責任問題

另一個常見說法是：

「Human + AI co-created this software。」

這在描述生產過程時或許合理。

但作者認為，它對事故處理仍然太模糊。

因為 production failure 發生後，需要的是具體問題：

誰可以阻止 Release？

誰應該質疑 Acceptance Evidence？

誰負責 Incident Investigation？

誰負責 Repair？

誰要對使用者說明？

誰欠使用者一個正常運作的服務？

一句：

「我們共同創造的。」

沒有回答任何一題。

小心人類變成 AI 的「Moral Crumple Zone」

論文引用 Madeleine Clare Elish 提出的 Moral Crumple Zone 概念。

這個詞借用了汽車的 crumple zone，也就是撞擊時先潰縮吸收能量的車體結構。

套到自動化系統裡，它描述一種很危險的責任現象：

高度複雜的 automated system 做出決策。

但出事時：

責任全部集中到離事故最近的那個人類身上。

例如操作員可能實際只有極短時間確認 AI 建議，也沒有能力理解整個模型，但最後卻成為事故唯一被追究的人。

AI Coding 也可能出現同樣問題。

如果公司建立的 production pipeline 是：

大量 AI generation ↓ 高速 merge ↓ Human reviewer 每天看幾十個 diff

然後事故發生後只說：

「Reviewer 按了 Approve，所以都是他的責任。」

這可能只是把 Human Reviewer 變成一個 moral crumple zone。

真正合理的事故分析必須檢查：

LLM

Prompt / Context

Harness

Tools

Dependencies

Review Process

Tests

Release Controls

Organization Policies

以及每個參與者真正擁有多少控制權。

作者認為真正被改寫的不是 Programming，而是 Production Process

這也是這篇 paper 開始變得特別有意思的地方。

很多人把 AI Coding 描述成：

以前： Human writes code

現在： AI writes code

但 Camargo 認為這樣看太簡單。

真正發生的事情比較接近：

Human → Specification / Intent

Model → Implementation generation

Harness → Tool coordination

Human → Review

Tests → Verification

Pipeline → Integration / Release

Organization → Operation

也就是說：

Implementation Production 本身被重新分工了。

作者甚至認為，與其一直問：

「Human 要怎麼放回 AI 的 Loop？」

不如換個角度。

因為軟體工程本來就是人類建立的 production process。

現在發生的是：

We put the machine in the loop.

機器被放進原本由人類控制的生產流程，並開始成為 implementation producer。

所以真正需要重新設計的，是整個 production control system。

這很像工業化後 Quality Control 被迫重新發明

Camargo 接著做了一個很有意思的歷史類比。

傳統工匠可能一個人完成：

設計 ↓ 製造 ↓ 檢查 ↓ 修理

但工業化之後，工作開始分工：

Designer

Machine operator

Production worker

Inspector

Manager

Quality engineer

產品品質沒有因此變得不重要。

相反地，因為生產者與檢查者開始分離，Quality Assurance 必須變成一套更正式的制度。

作者引用品質工程歷史，包括 Walter Shewhart 在 1920 年代發展的 statistical process control 思想。

核心變化是：

品質不能只靠：

「最後看一下產品有沒有壞。」

而是必須理解：

生產過程本身是否穩定、可控、可以重複產生合格結果。

Camargo 認為 AI-generated software 正在面臨相似問題。

如果 LLM 是 Implementation Producer，那 Quality Engineering 就不能只在最後讀一次 diff。

還需要觀察：

Model version

Configuration

Context

Prompt

Harness

Tools

Dependencies

Human intervention

甚至 production run 之間的 variability。

看一個 Diff，只能證明那一個 Diff

這點尤其重要。

假設今天使用 GPT-X：

Prompt A ↓ 產生 implementation A ↓ Review ↓ Test PASS

這只能提供 evidence：

implementation A 在這次測試條件下通過。

它不能直接證明：

下一次用同一個模型、同一個 prompt，就一定產生同樣品質的 implementation。

因為生成式模型的 production process 是 probabilistic 的。

因此如果企業真的大量使用 Agent 自動產生 Code，品質工程未來可能必須開始評估：

同一個 Task ↓ Repeated Generation ↓ Implementation A Implementation B Implementation C Implementation D ↓ 都使用相同 Acceptance Criteria 驗證

也就是從：

Code Review

逐漸增加：

Generation Process Evaluation。

這是傳統軟體工程很少需要大量處理的新問題。

論文最重要的概念：Inside-out vs Outside-in

到這裡，Camargo 把問題再往前推一步。

即使 AI 產生的 Code 每次都很穩定，也不代表服務真的符合需求。

假設學生註冊系統所有 unit tests 都通過。

Service API 也回傳 HTTP 200。

UI 顯示：

Enrollment Successful

但是後端 Academic Record 根本沒有寫入。

從 component 的角度：

Everything PASS。

但從學生的角度：

他根本沒有完成註冊。

作者因此區分兩種 evaluation 方向。

Inside-out Evaluation

從 implementation 開始。

Producer ↓ Code ↓ Unit Test ↓ Integration Test ↓ Release ↓ Service

核心問題是：

「這份 implementation 是否正確？」

Outside-in Evaluation

則從真正的 Demand 開始。

Demand：

符合資格的學生必須能在要求條件下完成有效註冊。

然後往回問：

要證明這件事，我需要哪些 Evidence？

於是 QA 不再只問：

Function 有沒有 Pass？

而是：

學生資料是否真的建立？

權限是否真的生效？

付款是否正確？

Retry 是否會造成重複扣款？

服務中斷後能不能恢復？

這就是作者稱為：

The demand is the oracle.

真正的 Oracle 不是 Implementation。

是使用者需要達成的結果。

一張表就能看出差異

論文給了一個非常實際的例子。

Component Evidence：

Generated change passes its tests

真正的 Acceptance Evidence：

Eligible student obtains a valid enrollment

Component Evidence：

Service responds under load

Acceptance Evidence：

Enrollment 在要求的時間與條件內真的完成

Component Evidence：

Retry handler executes

Acceptance Evidence：

Retry 不會產生 Duplicate Enrollment 或 Duplicate Charge

Component Evidence：

UI reports success

Acceptance Evidence：

Academic Record 與相關 Access 真的確認成功

這就是 AI Coding 時代特別容易出現的陷阱。

AI 很可能非常擅長讓：

local implementation

unit tests

type checks

lint

全部變綠。

但：

Green CI 不等於 Green User Journey。

Software Proving Ground：不要只測零件，要把整台車開出去撞一圈

作者用汽車做了一個很好理解的比喻。

測試汽車車身使用的鋼材，是有價值的。

但鋼材測試通過，不代表整台車一定安全。

所以汽車還需要：

Proving Ground

也就是讓組裝完成的車輛在不同實際條件下接受測試。

軟體也可以有類似概念。

例如學生註冊系統的 Software Proving Ground 可以模擬：

不同合法註冊流程

多人同時註冊

網路中斷

付款失敗

Retry

資料庫暫時不可用

服務重啟

權限延遲

然後 Oracle 不只是：

API 還活著嗎？

而是：

學生最後到底有沒有得到合法而完整的 Enrollment？

甚至模擬 1,000 個 user 也不一定代表測試充分。

作者特別提醒：

如果 1,000 個 simulated users 全部只是重複同一種 synthetic behavior，那並不能證明它代表真實 operating conditions。

測試量很多，不代表測試範圍正確。

Artifact Quality 和 Production Process Quality 也要分開

這又是另一個容易混淆的概念。

今天 AI 產生一份 Implementation。

測試結果很好。

這代表：

Artifact Evaluation PASS。

也就是：

這一次 delivery 看起來可接受。

但如果你想知道：

「這套 AI Coding Pipeline 長期可靠嗎？」

那要測的是：

Process Evaluation。

做法可能是：

固定 Task

固定 Model / Harness / Configuration

Repeated Production Runs

產生多個 implementation

全部用相同、由外部需求推導的 Acceptance Criteria 測試

最後才能評估這套 production setup 有多穩定。

這和傳統 benchmark 看一次 generated code 完全不同。

這其實直接打到 Vibe Coding 最容易忽略的地方

Vibe Coding 最大的魅力之一就是：

我描述需求 ↓ AI 改 Code ↓ 畫面動了 ↓ Done

在 Prototype 或個人小工具上，這可能非常有效率。

但到了 Production，問題就變了。

如果工程師不再深入理解每一段 implementation，那品質不能再只依賴：

「作者本人知道自己寫了什麼。」

因為作者本人可能根本不存在於傳統意義上。

因此未來成熟的 AI Coding Pipeline 可能會變成：

Human → Define Demand

Agent → Generate Implementation

Quality System → Define Acceptance Evidence

Tests / Simulation → Evaluate Artifact

Repeated Runs → Evaluate Production Process

Human → Make Release Decision

Monitoring → Observe Real Operation

Incident System → Feedback into Acceptance Criteria

這不是把 Human Engineer 消滅。

反而是讓人的角色從：

每一行 Code 的直接生產者

逐漸轉變成：

Intent Director、System Designer、Quality Authority 與 Operational Owner。

然後作者問了一個更瘋狂的問題：真的還需要『另一份 Program』嗎？

文章最後開始離開一般 AI Coding 討論，進入更前衛的 AI-native software engineering。

假設真正的 Demand 是：

「讓學生完成合法註冊。」

我們現在習慣的流程是：

Demand ↓ 寫一個 Program ↓ Program 執行註冊

Generative Coding 則可能變成：

Demand ↓ LLM 動態產生 Program ↓ Program 執行

但作者問：

為什麼一定要為每一個 Task 再產生一個獨立 Program？

未來甚至可能是：

Demand ↓ Existing Trained System ↓ 直接完成 Task

沒有額外產生 task-specific source code。

這個想法與近年出現的 AI-native software engineering、intent-centric development，以及 Matt Welsh 著名的《The End of Programming》觀點相呼應。

但作者也特別澄清：

這不代表 Software 消失了。

底層仍然存在：

Model

Runtime

Infrastructure

Dependencies

Operating System

Distributed Services

只是使用者的每一個需求，不一定都需要生成一份新的程式。

Code 消失，Responsibility 還是不會消失

這其實是全文最後最重要的一刀。

假設未來真的出現：

User Intent ↓ AI System ↓ 直接完成工作

沒有新 Code 可以問：

「這到底是誰寫的？」

Authorship 問題似乎消失了。

但學生最後如果還是沒辦法註冊：

Responsibility 完全沒有消失。

仍然有人必須回答：

服務為什麼失敗？

誰負責恢復？

哪些 Dependency 出問題？

為什麼 Release Criteria 沒抓到？

下一次如何避免？

因此論文最後把問題重新拉回最開始那個非常樸素的要求：

The student must be able to enroll.

最後真正重要的，不是 Code 是誰打出來的。

而是：

你承諾提供的服務，到底有沒有完成它應該完成的工作。

但這篇不是在證明 AI Coding 已經造成責任崩潰

這裡一定要把研究限制講清楚。

Camargo 自己在結論明確指出：

1 / 0 是假想案例，不是真實事故報告。

引用的研究沒有證明團隊在失敗後一定會失去 Collective Ownership。

那些研究也沒有證明 AI Coding Pipeline 已經達到或無法達到安全 Production 的標準。

Software Proving Ground 也不可能包含所有真實使用情境。

即使測試非常完整，部署後仍然需要 Observation 與 Monitoring，因為實際環境永遠可能出現沒有被預想到的條件。

所以《It Is Not My Code Anymore》真正提供的不是：

「AI Coding 很危險」的實驗證據。

它比較像在提出一個工程制度問題：

如果 implementation producer 已經改變，我們是不是也應該重新設計責任與品質制度？

AI Coding 真正改變的，也許不是誰打鍵盤

這篇論文最值得留下來的觀點，並不是那句很有梗的：

「It is not my code anymore。」

而是它後面隱藏的第二句：

但它仍然可能是我的系統、我的服務、我的責任。

未來工程師可能越來越少親手輸入每一行 implementation。

但這不代表工程責任會一起被 AI 接走。

反而可能迫使整個產業重新回答一些過去被『寫 Code 的人就是負責的人』掩蓋掉的問題：

誰定義需求？

誰控制生成流程？

誰設定 Acceptance Criteria？

誰有 Release Authority？

誰監控 Production？

出了問題誰能停止系統？

誰負責向使用者說明？

如果 AI Coding 真的成為軟體開發的主流，那未來最重要的工程能力，也許不只是 Prompt 寫得多漂亮。

而是建立一套即使沒有人親手寫完所有 Code，仍然能證明：

這個系統真的做了它承諾要做的事情。

Tech English 專有名詞

Authorship（作者身分／程式產生者）：指某段程式或內容實際由誰產生。AI-assisted programming 中，提出需求、review 程式與實際生成 implementation 可能由不同角色完成，因此 authorship 不再自然等同 responsibility。

Psychological Ownership（心理所有權）：個人主觀感覺某個產品、程式或成果『是自己的』程度。研究顯示，AI 自主貢獻增加時，開發者對程式碼的這種 ownership 感可能降低。

Accountability（問責責任）：某個角色因其職務、決策權或控制能力，而需要為系統結果提供解釋並承擔相應責任。它與誰實際輸入或生成程式碼並不是同一概念。

Moral Crumple Zone（道德潰縮區）：描述複雜自動化系統出錯時，責任被不成比例地集中到最靠近事故的人類身上的現象，即使該人實際控制權非常有限。

Outside-in Evaluation（由外而內評估）：從使用者真正需要達成的結果與使用條件出發，再反向定義程式、模型、測試與營運系統需要提供哪些證據，而不是只從 implementation 本身判斷品質。

Acceptance Criteria（驗收標準）：定義一個產品或服務在什麼條件下才可以被視為符合需求的具體標準。AI-generated software 中，作者主張這些標準應由外部需求推導，而不能完全由被測試的 implementation 本身決定。