Theo Browne, @t3dotgg · 16:01

這支影片在講：AI 之後，工程師該做更寬的產品

Theo Browne 在 AIEWF2026 closing keynote 的核心提醒是：不要只把既有開發流程用 AI 跑快一點。模型能力已經從 tool-calling 走到長任務執行與 orchestration，產品想像也該從「做更深的一個 feature」改成「覆蓋更寬的問題空間」。

Published: 2026-07-08Video ID: xUnRQ9vLXxo

01 / 問題

舊心智模型太重

很多 AI 產品仍在模仿 Git、terminal、傳統 IDE 或 SaaS workflow；熟悉感很高，但未必符合 AI agent 真正能做的事。

02 / 反轉

難度分層被改寫

side project、startup、too big 這些舊分類正在移動。原本要一隊人做的產品，可能變成一個 cron job 管一份 Markdown。

03 / 解法

想更寬，不只更大

重點不是盲目膨脹 scope，而是把產品設計成可擴展、可被使用者延伸，讓 agent 承擔更多實作與編排成本。

Watch for this

影片裡最值得抓的四個訊號

Runtime

16:01

短 keynote，但主題直接指向 AI 工程師接下來該重新選的產品邊界。

Model shift

3 stages

從 Sonnet 3.5 的 tool-calling，到 Opus 4.5 的長任務，再到 Mythos 式 orchestration。

Design analogy

iOS 7

Theo 用 skeuomorphism 類比說明：我們還在用舊物件的形狀想新介面。

Product tier

Markdown

一份 Markdown 加 cron job 就能承擔過去像 startup 的任務，代表門檻已被壓低。

Core story

這場 keynote 的三個轉向

轉 1

從「讓 AI 使用舊工具」轉向「重新設計工具」

如果 AI 只是被塞進 Git、terminal、issue tracker 與傳統部署流程，它會被人類熟悉的 interface 限制。Theo 把這稱為軟體開發的 skeuomorphic phase：新能力被包在舊形狀裡。

轉 2

從「做小 side project」轉向「重估 too big」

AI agent 能處理更多 implementation detail 之後，原本「這太大了」的判斷不再可靠。工程師要重新校準：哪些任務只是被舊成本結構嚇住，哪些才是真的難。

轉 3

從「深挖單點」轉向「覆蓋更寬的產品面」

Theo 鼓勵 builders 不只在一個狹窄 feature 裡做更深，而是設計能跨更大範圍運作的平台，甚至挑戰過去看起來像 AWS 或 Salesforce 才能做的寬產品。

Decision map

這不是「做更大夢」，而是重算工程成本

不要把 familiarity 當成 utility使用者熟悉 Git 或 terminal，不代表那是 AI-native workflow 的最佳形狀。熟悉感有時只是遷移期的安慰。

把產品切分層級重新畫一次side project、startup、platform 的邊界正在移動；自動化與 agent orchestration 會把部分中間層壓扁。

寬度要靠 extensibility 支撐寬產品不是把所有功能都手刻完，而是讓系統能被使用者、agent 或第三方 extension 持續延伸。

野心要跟架構一起長如果要挑戰更寬的市場，架構要先允許配置、擴充、工作流編排與長任務監控；否則只會變成 scope creep。

Chapters