Theo 以 Karpathy 的一篇貼文為引子，深入探討當前程式設計師面臨的 AI 衝擊。他認為 AI 輔助開發已經不再是「早期嘗鮮」，而是「你已經遲到了」的階段。影片中他分享了自己如何利用 AI 工具（如 Claude Code、Cursor）完成 90% 的程式碼撰寫，並提出一套系統性的趕上策略：從找到工具極限、跳脫框架思考，到編排多個 AI Agent 協同工作，幫助開發者在這場變革中不掉隊。

原影片連結：https://www.youtube.com/watch?v=Z9UxjmNF7b0

影片重點

• Karpathy 承認自己作為程式設計師從未感到如此落後，這場 AI 變革已是不可逆的現實
• Theo 個人 90% 的程式碼由 AI 生成，他帶領的團隊至少 70% 是 AI 生成的程式碼
• 第一步：用實際工作任務測試 AI 工具，找到它們的能力極限
• 第二步：跳脫框架思考，將過去「不值得寫程式解決」的問題交給 AI
• 第三步：學習編排（Orchestration），將多個 Agent 和工具串聯起來
• Ramp 公司 AI 負責人 Rahul 的實戰建議：給 Agent 工具、投資 Agent 文件、建立 Eval
• 程式碼品質的保障：善用型別系統、Linting、Claude MD 檔案來引導 AI 輸出
• 對企業管理者的呼籲：讓工程師使用最好的 AI 工具，否則人才將會流失

詳細內容

[00:00] Karpathy 的警鐘：程式設計師正在落後

Theo 以 Andrej Karpathy 的一篇社群貼文開場。Karpathy 寫道：「作為一名程式設計師，我從未感到如此落後。這個職業正在被劇烈重構，程式設計師貢獻的程式碼在整體中佔比越來越少。」他提到有一整層新的可程式化抽象層需要掌握，包括 Agent、Sub-agent、Prompt、Context、Memory、Mode、Permission、Tool、Plugin、Skill、Hook、MCP 等等。

Theo 對此深有同感，他回憶起做 GPT-5 影片時就感受到了第一波震動——AI 不再只是幫忙自動補全和建立 API 檔案的工具，而是能真正建構完整應用程式的存在。他強調，他認識的所有聰明的開發者現在都在用 AI 做瘋狂的事情，不論是把 AI 當作產品的一部分，還是用來完成大部分開發工作。

[03:30] 你已經遲到了：AI 開發已成現實

Theo 一向主張「晚入場好過早入場」，他看過太多人 all-in 在最後證明沒用的東西上。但他明確表示：AI 輔助程式開發已經過了那個觀望期。他自己現在超過 90% 的程式碼是用 AI 寫的，團隊至少 70%，他接觸的投資公司和合作夥伴也是類似的數字。

他提到 AI 目前在做決策方面還不夠好，但在討論決策時很有幫助。他直言：「如果你覺得你做的東西太複雜、AI 處理不了，去告訴那些用它建構編譯器的人、建構程式語言的人、建構部署系統的人。」這已經會對就業市場產生實質影響，方向和程度未知，但影響是確定的。

[06:30] 步驟一：找到 AI 工具的極限

Theo 建議的第一步是：去試用目前最熱門的工具（Claude Code、Cursor、OpenCode 等），搭配最新的模型（當時是 Opus 4.5 或 GPT-5），然後把它們推到極限。具體做法是拿一個你一直想實作的功能，交給 Agent 去做，觀察它的計畫和輸出。

他推薦使用 Plan Mode——像是和同事在白板前討論如何實作一個功能。觀察 Agent 如何瀏覽程式碼庫、如何思考問題，這本身就是學習的過程。兩個核心目標是：建立對這些工具能做什麼和不能做什麼的直覺，以及在不降低品質信心的前提下增加程式碼產出量。

他建議建立自己的「偽基準測試」：把過去一週完成的任務拿出來，在任務開始前的版本上讓 AI 重做，比較你的做法和 AI 的做法，逐步提高任務難度。

[10:30] 步驟二：跳脫框架思考

Theo 分享了一個個人經歷：他有一堆大學時期 Android 手機備份的照片和影片，散落在各個資料夾中，手動整理了六個月的八年資料後放棄了。後來他讓 Claude Code 在 Windows 上處理這件事，AI 寫了一堆腳本（包括一個 30,000 行的 JavaScript 檔案），成功重新整理和轉碼了所有檔案。

這就是他說的「跳脫框架思考」——很多問題理論上可以用程式碼解決，但過去不值得花那個時間去寫。現在寫程式碼的成本大幅下降，你需要重新看待世界。他用滑板做了一個有趣的類比：滑板玩久了，你走在街上會不自覺地思考哪裡可以滑、樓梯有幾階能不能跳；學了程式設計也一樣，你看到錯誤畫面會想背後的原因。現在你需要再次重新連結大腦，開始看到「哪些問題可以用 AI 輕鬆解決」。

他舉了更多例子：花 10 分鐘用 Vibe Coding 建了一個自動比較不同 AI 模型寫作風格的工具、隨時用 Claude Code 建立 Shell 別名來自動化重複操作、為自己的魚缸遊戲 Vibe Code 了三套資產管理工具。

[18:30] 步驟三：編排（Orchestration）

Theo 坦言自己還在學習這一塊。編排指的是如何啟動不同的 Agent、將各個部分串聯起來、撰寫（或讓 AI 撰寫）將工具和功能連結在一起的膠水程式碼。

他以自己的魚缸遊戲為例，建立了一個「Fish Bible」——一個 Markdown 檔案，記錄遊戲中所有魚和寵物的資訊。他在 Claude MD 中指定這個檔案是權威參考，任何遊戲變動都要同步更新。這種做法讓他不需要時時盯著程式碼，而是通過文件來管理 AI 的行為。

他提到 Pete（Peter Steinberger）的 Clawdbot 是一個很好的編排範例——透過 Telegram 或 WhatsApp 控制一台電腦上的 AI Agent。他也提到，剛開始你需要「強迫自己」去找可以自動化的地方，但一旦找到感覺，就會發現生活中有無數瑣碎的事情以前不值得自動化，現在絕對值得。

[23:00] Ramp 的 AI 領導者實戰建議

Theo 引用了 Ramp 公司 Applied AI 負責人 Rahul（Rahul Sengottuvelu）的一篇文章，分享了一系列企業級的 AI 開發建議：

給 Agent 工具存取權：讓 Agent 能存取 Linear、GitHub、Datadog、Sentry 等開發工具。如果 Agent 因為缺乏上下文而受限，那是你的問題。Ramp 內部建了一個 Inspect Bot，能自動找出 Sentry 上最常見的 20 個錯誤，然後為每一個建立修復 PR。

投資程式碼庫專屬的 Agent 文件：不要抱怨 AI 做不好某件事，而是改善 Prompt、Agent MD 檔案、Linting 規則。Claude Code 團隊每天多次修改內部 repo 的 Claude MD 檔案。每一次你手動修改 AI 生成的程式碼，都是一次改善 Agent MD 的機會。

善用型別系統與 LSP：使用有型別的程式語言，讓型別錯誤能回饋給 Agent 自動修正。Claude Code、OpenCode、Cursor 都支援這種錯誤回饋迴路。

建立背景 Agent 基礎設施：在 VM 和沙箱中建立完整的開發環境，讓工程師能同時平行執行多個 Agent。程式碼審查很快會成為瓶頸。

[28:30] 不要逆轉，持續推進極限

Theo 提到有些開發者（如 Clawdbot 的 Pete）堅持「從不逆轉」的策略——如果 AI 的輸出不滿意，不是回到之前的版本，而是繼續 Prompt 直到修正。但 Nean（Naman Goel，Meta StyleX 的作者）在直播聊天中指出，這和模型有關：Codex 比較擅長修正自己的錯誤，而 Opus 則更適合逆轉重來。

Theo 強調，不管哪種策略，重點是持續實驗、持續推動極限。「如果你還沒看到價值，表示你還沒到那一步，繼續推進直到你看到為止。」

[30:30] 更多實戰建議與對管理者的喊話

Rahul 的文章還提到幾個重要觀點：

• 建立 Eval（評測）很重要：用 Vibe Coding 建立自己的基準測試，比較不同模型的表現
• 永遠用最新一代的模型：還在用 GPT-4.1 和 Claude 3.5 Sonnet 做 Code Review 是在浪費錢
• 用 Embedding 語意搜尋取代模糊搜尋
• Custom Fine-tuning 已死：前沿模型進步太快，花 8 週做 Fine-tune 不值得
• 不要太擔心推論費用：成本下降速度很快，按週計算而非按年

最後 Theo 對企業管理者喊話：讓你的工程師使用最好的 AI 工具。最好的工程師已經在用了，如果你不允許，他們會離開，你的公司會失敗。抵抗 AI 不是什麼高尚的立場，而是在阻止你的團隊贏得勝利。

我的想法

這支影片的核心訊息很清楚：AI 輔助開發已經從「觀望期」進入了「你已經遲到了」的階段。Theo 的三步策略（找極限、跳脫框架、學習編排）提供了一個很務實的路徑。

特別值得注意的是「Fish Bible」這個做法——用 Markdown 文件作為 AI 的權威參考來源，配合 Claude MD 來管理 AI 的行為。這其實是一種「文件驅動開發」的新範式，很適合在 AI 協作的場景下實踐。

不過我認為影片中有一個隱含的前提值得思考：Theo 的工作性質（內容創作者 + 獨立開發者）讓他有更大的自由度去實驗。對於在大型企業、受嚴格監管的產業中工作的開發者來說，「先斬後奏」的策略可能需要更謹慎。但核心觀點不變——至少要開始了解這些工具的能力邊界，否則確實會被甩在後面。

另一個有趣的觀點是關於「程式碼品質的分級」：不是所有程式碼都需要同等品質標準。個人工具、自動化腳本、原型可以接受較低品質的 AI 生成程式碼（所謂的 Slop Code），但生產環境的關鍵邏輯仍需要嚴格把關。這種分級思維對於有效運用 AI 開發很關鍵。