Airbnb 使用 AI 的範圍也不只限於軟體開發。The Motley Fool 刊出的 Airbnb 2025 年第四季財報電話會議逐字稿稱,Airbnb 自有的 AI 客服代理已在北美解決三分之一客服問題,並處理近 30% 的工單,且公司計畫把它擴展到全球與語音場景 。同一份逐字稿也提到,Airbnb 正在打造更「AI 原生」的體驗,協助旅客規劃行程,並讓公司能更有效率地規模化運作
。
當 AI 能快速產出大量初稿,工程師的工作不會因此消失,但價值會被重新定義。
過去,許多工程價值容易被看成「寫了多少程式碼、完成多少任務」。但在 AI 輔助開發變成日常之後,更重要的是能不能創造出可靠、可維護、真正符合產品需求的軟體。工程師需要更強的能力包括:
因此,工程能力的判準會改變。速度仍然重要,但「手打了多少行程式碼」會變成比較弱的價值指標。真正拉開差距的是判斷力:知道該請 AI 做什麼、該拒絕什麼、該重構什麼,以及哪些東西根本不該被做出來。
AI 輔助寫程式會讓第一版實作變便宜。當初稿不再稀缺,能分辨「可用初稿」與「脆弱初稿」的人就更值錢。
在這樣的環境裡,強工程師不是把 prompt 丟出去、把結果照單全收的人,而更像編輯、系統設計師與營運者的混合體:能把 AI 生成的內容整理成可靠軟體。這包括確認實作是否符合產品意圖、是否破壞隱藏假設、是否契合架構,以及日後是否能被其他團隊維護。
這也是為什麼 AI 可能讓資深工程判斷更重要,而不是更不重要。當團隊能更快產出程式碼,真正的瓶頸往往會移到另一個地方:決定哪些程式碼值得存在。
Chesky 對管理者的說法,和「近 60% 程式碼由 AI 撰寫」一樣值得注意。Airbnb 被報導希望管理者保持足夠接近技術工作,能親自寫程式或使用 AI 寫程式工具 。People Matters 關於 Chesky 警告「純粹管人的管理者」的報導,也指向同一個方向:如果領導角色只剩協調層,可能會在 AI 改變工作流程時承受更大壓力
。
這不代表每位工程主管都必須變成團隊裡最強的個人貢獻者。但它意味著,技術理解力會越來越難迴避。
在 AI 高度參與的團隊中,管理者需要能夠:
管理者仍然需要招募、教練、排優先順序與維持團隊健康。但在朝 Airbnb 這個方向前進的公司裡,這些職責會與更貼近工具、技術與實作的理解綁在一起。
真正危險的未必是「軟體工程師」或「管理者」這個職稱,而是角色被定義得太窄,只剩例行產出。
壓力會更容易落在這些人身上:
相對安全的,是具備判斷力的技術型人才:能用 AI 加速,也能守住品質、架構與結果。
對工程師來說,最務實的做法不是忽視 AI,也不是盲目信任 AI,而是把「AI 輔助交付」練成真正可靠的能力。這包括寫出更清楚的規格、提供更好的背景脈絡、仔細審查 diff、擴大測試覆蓋,並持續投資在架構、可靠性、安全性與產品判斷上。
對管理者來說,關鍵是不要離技術現場太遠。實際使用工具,理解它們的長處與限制;參與設計與 review 討論;把品質標準講清楚;獎勵能帶來長期產品成果的團隊,而不是只獎勵「看起來很忙」或「手動輸入很多程式碼」。
Airbnb 被報導的近 60% 數字,是 Airbnb 自身的觀察點,不是整個產業的平均值。它不應被解讀成所有軟體組織都已達到同樣程度的 AI 採用。
Chesky 對 AI 的看法本身也包含加速與耐心兩面。2024 年,他曾說 AI 會比許多人想像中更深刻地改變世界,但也會比很多人預期花更久時間 。這或許是理解這波變化最合適的角度:AI 可能深刻重塑軟體工作,但轉型不會整齊劃一。