Stripe 工程師已經不寫程式了：每週 1300 個 AI PR，瓶頸後移到審查、部署與開發者體驗
Stripe 工程師已經不寫程式了：每週 1300 個 AI PR，瓶頸後移到審查、部署與開發者體驗
title: "Stripe 工程師已經不寫程式了：每週 1300 個 AI PR，瓶頸後移到審查、部署與開發者體驗" date: 2026-03-29 author: kordan.ou source: https://www.threads.com/@kordan.ou/post/DWabe6REqf7 category: threads tags:
- Stripe
- AI 開發
- Developer Experience
- 軟體工程
- 瓶頸後移 created: 2026-03-29 updated: 2026-03-29
Stripe 工程師已經不寫程式了：每週 1300 個 AI PR，瓶頸後移到審查、部署與開發者體驗
原文摘要
Stripe 的工程案例已經把「AI 會不會取代工程師」的問題往前推了一步：每週有 1,300 個 PR 是由 AI 產生，人類只負責審核。
核心論點：瓶頸後移
當寫程式這件事本身越來越便宜，瓶頸自然會往後移——移到審查、想法形成、以及成果如何被部署與採用。
真正的槓桿不在 Prompt
從來不在提示詞，而在開發者體驗（Developer Experience）、雲端基礎設施與工具設計。
為什麼 DX 這麼重要？
- 大型程式碼庫本來就不可能 run local dev
- 如果沒有好的 tooling，大模型很快就會把 context 耗盡
- 工程師又得把時間花在不完整的基礎設施上
- 雲端與虛擬化環境是讓 AI 順利工作的必要條件
最有趣的觀點
當生成變得便宜，軟體本身也開始變得可以被丟棄。 也許有一天，我們不再問「這段 code 能用多久」，而是問：「這段 code，值得存在多久？」
參考影片
How Stripe deploys 1,300 AI-written PRs per week
核心觀點
1. 和 Karpathy 部署那篇完美互補
Karpathy 說「AI 寫程式不難，部署才是地獄」。Stripe 的案例證明：即使解決了部署，瓶頸又會移到審查和 DX。瓶頸永遠存在，只是不斷往後移。
2. 1,300 PRs/week 的規模驗證了 Multi-Agent Orchestration 的必要性
前面整理的 oh-my-claudecode、DeerFlow、Paperclip 等 orchestration 框架，在 Stripe 這種規模下就是剛需——你不可能手動管理每週 1,300 個 AI 生成的 PR。
3. 「可丟棄的軟體」是個深刻的觀念轉變
傳統思維：寫好 code、維護好 code、code 的壽命越長越好。AI 時代：生成成本趨近零，code 變成消耗品。這會根本改變軟體架構的設計哲學。