看影片（在新分頁開啟原站）連到 AI Native Dev
其他版本：Podcast 版（在新分頁開啟）
摘要
Liz Fong-Jones 分享 Honeycomb 如何從 30 次日增 PR 躍升至 70 次，但自動化審查成為瓶頸。她解釋 AI 放大了現有組織的缺陷，並提出 Jev 決策模型以篩選安全合並的 PR。同時強調 AI 應僅處理測試而非生產事故，並指出「誰命名誰負責」的開源維護原則。
Liz Fong-Jones shares how Honeycomb scaled PRs from 30 to 70 daily, but automated review became the bottleneck. She explains AI amplifies existing organizational flaws and introduces the Jev model for safe auto-merging. She emphasizes AI should handle testing, not production incidents, and stresses…
重點
- Honeycomb 自動化審查從 30 次 PR/日增至 70 次，但人工審查仍是主要瓶頸。
- 使用 Jev 模型決定哪些 PR 可安全自動合並，避免過度依賴 AI。
- AI 應專注於測試而非生產事故，生產事故需人工介入。
章節
依話題轉折切分，標題由 AI 產生
- 00:00AI 原生開發者：PR 數量翻倍，事故率上升 1.5 倍
- 02:31從個體貢獻者到行業大使：我的可靠性旅程
- 07:06定義功能型組織：AI 如何加速組織惡化？
- 13:41機器人能幹嗎？Honeycomb 的自動合併資料
- 24:52從資料到理解：AI 如何改變系統觀察
- 28:21可觀測性與可控制性：AI 決策的雙刃劍
- 30:31安全邊界：最小許可權與合閘 CI/CD 的必要性
- 32:52不要過度信任：人類與機器人的責任分界
- 36:03AI 署名即所有權：誰該為錯誤負責？
- 38:30手動介入的必要性：即使 AI 署名也需人工審視
- 46:02未來 50 年：可觀測性工程師的角色演變
- 49:11社群結尾：Tesla 與 AI 原生開發者社群
提到的工具與公司
- Autobot
- Jev
- Honeycomb
- DevRel
- SRE
- Observability
適合誰看
AI 開發者、工程經理、SRE 團隊負責人。
摘要依據
- 依據
- 節目逐字稿
為什麼排在這裡
- 人氣
- 0.38
- 新鮮
- 0.99
在主題頁與搜尋結果裡，名次由相關、人氣、新鮮三個分數決定；這一頁沒有搜尋的關鍵字，所以沒有相關分數。排序怎麼算
相關內容
- How Warp ships 2,000 PRs a month with AI factories | Zach Lloyd (CEO, Warp)Podcast ・ How I AI ・ 47 分鐘（在新分頁開啟原站）
- AI 时代到底该怎么管一个工程团队文章 ・ 寶玉
- 850 PRs a Week: How Tessl Runs a Software Factory影片 ・ AI Native Dev ・ 51 分鐘
- How Warp ships 2,000 PRs a month with AI factories | Zach Lloyd (CEO, Warp)文章 ・ Lenny's Newsletter
- Why software factories fail without humans | HumanLayer, Warp & LinearBPodcast ・ Dev Interrupted ・ 59 分鐘（在新分頁開啟原站）
- How People Are Actually Using Jev影片 ・ The AI Daily Brief: Artificial Intelligence News ・ 22 分鐘（在新分頁開啟原站）
摘要由 AI 根據原文產生，可能有誤；完整內容請看原站。看影片（在新分頁開啟原站）