AI Engineer Europe 2026 · 演講 · 2026-04-18 · 19 分
為 agent 寫程式留一點摩擦
The Friction is Your Judgment · Armin Ronacher、Cristina Poncela Cubeiro，Earendil
Armin Ronacher 與 Cristina Poncela Cubeiro 用一年的實戰經驗，談 agent 寫程式帶來的心理陷阱與工程對策，主張摩擦是人下判斷、掌握方向的地方。
概要
- 速度變成壓力工具剛上手時省下時間又好玩，但人人都用之後，基本期待跟著拉高，多出來的自由時間變成要更快出貨的壓力。
- 上癮加上產出的錯覺下一個 prompt 可能讓產品成形，也可能是壓垮它的最後一點 slop；大量產出讓人誤以為更有效率，反而沒時間停下來想。
- 寫的人變多，扛責任的人沒變多每位工程師的產出能力遠大於審查能力，行銷人員與前 CEO 也開始出貨程式碼，責任仍落在工程團隊身上，審查因此被草草蓋章。
- agent 偏向讓程式跑得動他們觀察到 agent 為了推進與解卡，會寫出人類不會寫的容錯程式，系統變脆弱，程式庫的雜亂程度也快速累積。
- 把程式庫當成基礎設施來設計模組化、遵循既有慣例、不藏魔法，再用 lint 規則做機械式強制，讓 agent 讀得懂。
- 該讓人醒來的地方要標出來他們替 Pi 寫了審查擴充，把可交回 agent 修的問題，和必須由人判斷的變更（例如資料庫 migration、權限）分開。
原話
▶ 03:57“So this fun and free time translated into pressure.”
所以原本的樂趣與自由時間轉成了壓力
▶ 04:33“You never know if that next prompt is going to be the one that makes your product work and you've added a new feature, or if it's going to be that last drop of slop that brings your product crashing down.”
你永遠不知道下一個 prompt 會讓產品多一個功能，還是成為壓垮產品的最後一滴 slop
▶ 10:30“your code base has now become infrastructure”
程式庫現在已經變成基礎設施
▶ 17:52“Because the friction, actually, in many ways, is what's necessary on a physical level to steer.”
因為摩擦在很多意義上，是物理層面上轉向所必需的
▶ 18:07“this is really where your judgment is, this is where your experience is”
這才是你的判斷所在，也是你的經驗所在
延伸
- 談技術債累積時，其中一位講者提到 Mario 也講過同樣的問題。
- 他們認為 agent 很適合重現客戶回報的問題、探索不同的產品方向，前提是人要為它產出的程式碼負責。
章節
點時碼直接跳到原片的那一段。
- 「ship without friction」以一則資安事故貼文的社群預覽開場，上面是該公司的行銷標語「ship without friction」，他們想鼓勵大家加一點摩擦。
- 兩位講者介紹Armin 做軟體開發 20 年、創造了 Flask，去年 4 月離開 Sentry 後投入 agentic engineering；Cristina 自稱原生 AI 工程師，先前在 Bending Spoons。
- 兩個問題用 agent 做了約 12 個月，有很大的槓桿也有很大的失望；問題分成心理面（為何難以放慢）與工程面（為何有人品質更好、有人更差）。
- 從樂趣到壓力工具一開始讓人更有生產力、更好玩，但人人都用之後，期待值變成理所當然，自由時間轉為壓力。
- 上癮與效率錯覺不知道下一個 prompt 會成功還是搞垮產品，所以容易上癮；產出又多又快讓人以為更有效率，卻沒時間停下來想，agent 自己也停不下來。
- 團隊組成改變寫程式與審查的平衡被打破，參與的人與機器增多但能扛責任的沒變，審查被跳過或蓋橡皮章，5,000 行的 PR 正是最該想卻最常放棄的時候。
- agent 的寫法習性agent 被訓練成寫出能跑的程式、持續推進，例如讀不到設定檔就退回預設，製造出比人類寫的更多失敗情境，系統變脆弱、雜亂度上升。
- 函式庫與產品Cristina 說他們觀察到 agent 在函式庫上表現較好，因為問題明確、核心簡單；產品牽涉權限、feature flag、計費等交錯元件，放不進 context window，局部合理、整體失控。
- agent 讀得懂的程式庫程式庫已經是基礎設施，要設計成 agent 看得懂：模組化（含程式流程的模組化）、遵循已知慣例、核心簡單、不藏魔法。
- 機械式強制多半靠 lint 規則落實：禁止 bare catch、SQL 集中在單一查詢介面、UI 只用一套元件庫、函式名稱唯一（兼顧 token 效率），並在試 erasable syntax only 的 TypeScript 模式。
- 替人類標出該醒的地方要找方法感受到 agent 感受不到的痛；他們替 Pi 寫了審查擴充，把機械性問題與必須由人判斷的變更（資料庫 migration、權限、新依賴）分開呈現。
- 快與慢的分界速度讓人上癮，但別在不該依賴的地方依賴；系統架構與可靠性仍要放慢，技術債可能在幾週甚至幾天內堆出幾個月的量。
- 結論：摩擦就是判斷工程團隊都想去掉出貨的摩擦，但 SLO 是刻意設計的摩擦；沒有摩擦就無法轉向，摩擦是判斷與經驗介入的地方。
名詞
- Earendil
- 兩位講者共事的公司，Armin 說他們在這裡試著弄懂各種 AI 的事
- Armin Ronacher
- 講者之一，做軟體開發 20 年、多在開源領域，創造了 Flask，去年 4 月離開 Sentry
- Cristina Poncela Cubeiro
- 講者之一，自稱原生 AI 工程師，加入 Earendil 前在 Bending Spoons
- agent legible code base
- Cristina 提出的主張：程式庫要設計成 agent 讀得懂，例如模組化、依循慣例、核心簡單
- 機械式強制（mechanical enforcement）
- 多半用 lint 規則落實的約束，例如禁止 bare catch、SQL 集中、單一元件庫、函式名稱唯一
- erasable syntax only TypeScript
- 他們最近在試的模式：程式碼基本上是 JavaScript，型別標註疊在上面，不需轉譯，source of truth 只有一份
- SLO
- 其中一位講者舉為「刻意設計的摩擦」的例子，逼人思考需不需要這種可靠度、人力夠不夠
- Pi 的審查擴充
- 他們替 Pi（Mario Zechner 做的 coding agent）寫的審查擴充，把可交回 agent 修的問題與需要人判斷的變更分開；字幕寫成 pie 與 Py
