A practitioner's single-project experiment suggests verification, not generation, is becoming the expensive half of software work
When an engineer at IBM used an AI coding agent to build Task Viewer — a small, non-critical convenience plug-in for an internal assistant called IBM Bob — the goal was not to ship a production system. It was to run a real-world experiment: find out how much of the engineering effort a coding agent actually absorbs, and where the effort ends up instead.
The account, published as analysis on O'Reilly Radar, is explicit about its own limits: it is one practitioner's experience on one low-stakes project, with no hard numbers on hours saved or defects introduced. Even so, its conclusion is worth taking seriously. The effort does not disappear when agents accelerate code generation. It moves. Code generation, long the slow, expensive part of building software, becomes comparatively cheap. What grows more expensive is the work of proving that the generated code does what it is supposed to do.
From writing code to earning confidence
The framing matters because it inverts a common assumption about AI-assisted development. The prevailing narrative treats coding agents as labour-saving devices: fewer hours at the keyboard, faster delivery, smaller teams. The O'Reilly piece argues the reality is more subtle. Agents lower the cost of producing a first draft of almost anything — a function, a module, a whole plug-in — and in doing so they raise the stakes on everything downstream.
If producing code is nearly free, the scarce resource becomes confidence: the assurance that the code is correct, safe, maintainable, and fit for the context it was written for. Verification activities — reading the diff, reasoning about edge cases, testing, reviewing, and simply understanding what the agent produced — start to dominate the engineering schedule.
Task Viewer was a deliberately forgiving test case. It has no critical production role, which meant the cost of a subtle defect was low. That is precisely what makes it a useful lens: even on a low-stakes internal tool, the author found the balancing point shifted toward checking rather than writing. On systems where failure carries real consequences, that imbalance intensifies.
Why it lands with testing teams
For teams responsible for quality assurance, the argument reframes existing debates. Test automation, review capacity, and code-quality tooling stop looking like back-office overhead and start looking like the primary line item in an AI-augmented workflow. Organisations that budget for agent licences but not for the review capacity to absorb the agent's output may find they have automated the cheap half of the job — while the expensive half scales unmanaged.
This is a broadly relevant observation for IT professionals in Hong Kong and elsewhere scaling AI tooling across development teams — not because the source addresses any local initiative, but because the underlying dynamic is universal: tooling that accelerates generation will pressure whatever sits between the generated code and a confident ship decision.
The takeaway: budget for confidence
The practical recommendation is to treat confidence as an explicit budget line rather than an invisible tax. Teams should ask, before adopting an agent, how much verification capacity they will need to support the volume of code it produces — and whether their current review and testing practices are sized for that volume.
The absence of hard metrics in the O'Reilly analysis is itself instructive. The field is early enough that practitioners are still measuring the trade-off empirically, one project like Task Viewer at a time — and that candour about the evidence is more useful than premature precision. What is already clear is the shape of the trade: cheap code, expensive confidence.
The engineering question going forward is not how much code an agent can write, but how a team organises itself to trust what comes out.
Analysis based on "Cheap Code, Expensive Confidence," a first-person practitioner account published by O'Reilly Radar. Full credit to O'Reilly and IBM for the original work.
一項由實務工作者進行的單一項目實驗顯示，軟件工作之中變得昂貴的不是生成代碼，而是驗證
一名 IBM 工程師使用 AI 編碼代理為內部助理 IBM Bob 建構 Task Viewer —— 一個小型、非關鍵的便利插件 —— 其目標並非推出一套生產系統，而是進行一項真實環境實驗：找出編碼代理實際上吸收了多少工程工作量，以及剩餘的工作量轉移到了哪裡。
這篇刊載於 O'Reilly Radar 的分析文章明確指出自身的局限：這只是單一實務工作者在單一低風險項目的經驗，沒有關於節省工時或引入缺陷的硬性數據。儘管如此，其結論仍然值得認真看待。當代理加速代碼生成，工作量並沒有消失，而是轉移了。長期以來作為建構軟件中最緩慢、最昂貴部分的代碼生成，相對變得廉價。變得更昂貴的是證明生成的代碼確實按預期運作的工作。
從撰寫代碼到贏取信心
這個論述框架意義重大，因為它顛覆了關於 AI 輔助開發的一個普遍假設。主流敘事將編碼代理視為節省人力的工具：鍵盤前的工時減少、交付更快、團隊更精簡。O'Reilly 的文章指出，現實更為微妙。代理降低了為幾乎任何事物製作初稿的成本 —— 一個函數、一個模組、整個插件 —— 而正因如此，它提高了下游所有環節的風險。
如果生產代碼近乎零成本，稀缺資源就變成了信心：即代碼正確、安全、可維護，並適合其撰寫情境的保證。驗證活動 —— 閱讀 diff、推演邊界情況、測試、審查，以及單純理解代理產出了什麼 —— 開始主導工程進度表。
Task Viewer 是一個刻意寬鬆的測試案例。它在生產環境中沒有關鍵角色，這意味著細微缺陷的代碼成本很低。正因如此，它成為一個有用的觀察角度：即使在低風險的內部工具上，作者發現天平已傾向檢查而非撰寫。在失敗會帶來真實後果的系統上，這種失衡會更為嚴重。
為何測試團隊尤其受啟發
對於負責品質保證的團隊而言，這項論述重新框定了現有的爭論。測試自動化、審查能力和代碼品質工具不再像後台開支，反而開始成為 AI 輔助工作流程中的首要預算項目。一些機構為代理授權費編列預算，卻沒有為吸收代理產出所需的審查能力預留資源，結果可能是自動化了工作中廉價的一半 —— 而昂貴的一半則在缺乏管理的情況下不斷膨脹。
對於正在開發團隊中擴展 AI 工具的香港及其他地區 IT 專業人士而言，這是一項廣泛相關的觀察 —— 並非因為原文涉及任何本地項目，而是因為其背後的動態具有普遍性：加速生成的工具，必然會對生成的代碼與有信心上線之間的一切環節構成壓力。
結論：為信心編列預算
務實的建議是把信心視為一項明確的預算項目，而非隱形稅項。團隊在採用代理之前，應先問：要支撐代理所產出的代碼量，需要多少驗證能力 —— 以及現有的審查和測試實踐是否具備足以應對該代碼量的規模。
O'Reilly 分析中缺乏硬性數據這一點本身亦具啟發性。這個領域尚處早期，實務工作者仍在以實證方式衡量這項權衡 —— 一次一個類似 Task Viewer 的項目 —— 而這種對證據的坦誠，比過早追求精確更有價值。目前已經清楚的是這場交易的輪廓：代碼廉價，信心昂貴。
往後的工程問題，並非代理能寫多少代碼，而是團隊如何組織自身，去信任產出的結果。
本文分析基於 O'Reilly Radar 刊載的第一人稱實務工作者記述《Cheap Code, Expensive Confidence》。原文功勞全歸 O'Reilly 及 IBM。