People Matters 另外報道，Chesky 警告「pure people managers」以及唔願意適應新科技嘅員工，喺 AI 改變公司運作方式之下，可能會被拋離 。換言之，Airbnb 呢次 AI 轉向唔只係「開發效率提升」故事，亦係技術領導力標準嘅重新調整。

而 AI 喺 Airbnb 嘅角色亦唔限於軟件開發。The Motley Fool 刊登嘅 Q4 2025 業績電話會議逐字稿顯示，Airbnb 自家 AI 支援代理已經喺北美解決三分之一客服支援問題，並處理接近 30% 工單，公司亦計劃將其擴展至全球同語音場景 。同一份逐字稿亦提到，Airbnb 正建構更「AI-native」嘅體驗，幫旅客規劃旅程，同時提升公司大規模營運效率 。

工程師唔係消失，而係角色變重

當 AI 可以草擬大量 implementation，工程師嘅價值唔再只係「打咗幾多行 code」。更重要係：你有冇能力令正確、穩定、可維護嘅軟件真正出現。

喺 AI 輔助開發環境入面，工程師要更強嘅能力包括：

• 講清楚問題。 AI 工具越強，越需要人類定義目標、限制、預期行為同相關背景。
• 提供系統脈絡。 生成出嚟嘅 code 要配合現有 codebase、ownership、資料假設同產品要求。
• 審核輸出。 AI 寫到第一版，唔代表可以直接 ship；工程師仍然要讀 code、理解 trade-off、判斷風險。
• 測試邊界情況。 起 draft 快咗，唔等於可以跳過測試、debug 同 failure mode 思考。
• 守住架構。 生成 code 越容易，長遠維護成本越可能上升；邊界、依賴、簡潔度反而更關鍵。
• 為 production 結果負責。 系統可靠性、可維護性、用戶影響，最後仍然係人類團隊要承擔。

所以，AI 時代嘅強工程師，唔係最會叫 AI 寫嘢嗰個，而係最識判斷：咩應該叫 AI 做、咩要拒絕、咩要重構、甚至咩根本唔應該做。

Code review 會變得更值錢

AI-assisted coding 令第一版 code 變平、變快。結果係，真正稀缺嘅能力會轉去「把關」。

一個好工程師唔應該只係 prompt 完模型，然後照單全收。更理想嘅角色有啲似編輯、系統設計師同 operator 嘅混合體：將 AI 生成嘅 code 變成可靠軟件。佢要睇 implementation 係咪符合產品意圖、有冇踩中隱藏假設、同現有架構夾唔夾、日後其他團隊係咪維護到。

換句話講，如果團隊產 code 更快，瓶頸往往會由「寫唔寫得切」變成「邊啲 code 值得存在」。資深工程判斷，反而更重要。

經理都要識技術，唔可以只做協調層

Chesky 對經理嘅講法，同近 60% code 數字一樣值得留意。Airbnb 被報道嘅方向係：經理要同工作保持足夠貼近，自己懂得寫 code 或使用 AI coding 工具 。People Matters 關於「pure people managers」可能難以適應 AI 時代嘅報道，亦指向同一個趨勢：如果管理角色只係排會、追 status、做中間協調，壓力會越來越大 。

當然，呢個唔等於每個 engineering manager 都要變成團隊最強 individual contributor。但技術流暢度會越來越難逃避。

AI-heavy 團隊入面，經理至少要能夠：

• 明白 AI 工具有咩做到、有咩做唔到；
• 評估技術 trade-off，而唔係只睇進度表；
• 挑戰估算、設計、生成 code 入面嘅薄弱假設；
• 為 review、測試、安全、可靠性設定清晰 quality gate；
• 用已交付價值同系統健康度衡量團隊，而唔係用「人手打咗幾多 code」做指標。

經理仍然要招聘、教練式管理、定優先次序、照顧團隊健康。但喺 Airbnb 呢類走向 AI-native workflow 嘅公司，呢啲管理責任會同「親身理解工具同技術工作」綁埋一齊。

最大壓力唔係某個職銜，而係過窄嘅工作定義

真正高危嘅未必係「software engineer」或者「manager」呢個 title，而係角色內容只圍繞重複產出。

壓力較大嘅人，通常有以下特徵：

• 只寫 code，但唔理解背後系統；
• 接受 AI 生成結果，卻冇仔細 review；
• 用 task 數量衡量影響，而唔係產品價值；
• 只協調工作，但唔明技術本質；
• 迴避學習已經成為團隊流程一部分嘅工具。

相對安全嘅定位，是有判斷力嘅 technical operator：識用 AI 加速，但同時守得住質量、架構同結果。

而家應該點做？

對工程師嚟講，最實際唔係抗拒 AI，亦唔係盲信 AI，而係練成「AI-assisted delivery」能力：寫更清晰 specification、提供更完整背景、認真睇 diff、補足 test coverage，並持續投資架構、可靠性、安全同產品 sense。

對經理嚟講，重點係唔好離開手藝太遠。你未必要每日落場寫最多 code，但要實際用過工具，知道佢強弱位；要參與 design 同 review 對話；要將質量標準講清楚；亦要獎勵長期穩陣嘅產品成果，而唔係獎勵人手輸入量。

最後要留神：Airbnb 係訊號，唔係全市場標準

Airbnb 近 60% 呢個數字，是 Airbnb 自己嘅數據點，唔應該被解讀成所有軟件公司都已經去到同一階段。

Chesky 對 AI 嘅觀點其實同時包含加速同耐性。2024 年，他曾表示 AI 將會比好多人的想像更大幅改變世界，但亦會比很多人預期用更長時間發生 。用呢個框架睇，會比較準確：AI 可能深刻改寫軟件工作，但轉型一定唔會平均、唔會一夜之間完成。

結論係，AI 未必簡單地「取代」工程師或經理；它正在改變兩者嘅貢獻單位。工程師要由單純生產者，變成 AI 產出嘅導演、審稿人同負責人；經理要有足夠技術流暢度，先帶到每日使用 AI 嘅團隊。喺 Airbnb 呢個案例入面，長遠優勢正由手動產出，轉向判斷、ownership，以及將 AI output 變成可靠產品嘅能力 。

People Matters 另外報道，Chesky 警告「pure people managers」以及唔願意適應新科技嘅員工，喺 AI 改變公司運作方式之下，可能會被拋離 。換言之，Airbnb 呢次 AI 轉向唔只係「開發效率提升」故事，亦係技術領導力標準嘅重新調整。

而 AI 喺 Airbnb 嘅角色亦唔限於軟件開發。The Motley Fool 刊登嘅 Q4 2025 業績電話會議逐字稿顯示，Airbnb 自家 AI 支援代理已經喺北美解決三分之一客服支援問題，並處理接近 30% 工單，公司亦計劃將其擴展至全球同語音場景 。同一份逐字稿亦提到，Airbnb 正建構更「AI-native」嘅體驗，幫旅客規劃旅程，同時提升公司大規模營運效率 。

工程師唔係消失，而係角色變重

當 AI 可以草擬大量 implementation，工程師嘅價值唔再只係「打咗幾多行 code」。更重要係：你有冇能力令正確、穩定、可維護嘅軟件真正出現。

喺 AI 輔助開發環境入面，工程師要更強嘅能力包括：

• 講清楚問題。 AI 工具越強，越需要人類定義目標、限制、預期行為同相關背景。
• 提供系統脈絡。 生成出嚟嘅 code 要配合現有 codebase、ownership、資料假設同產品要求。
• 審核輸出。 AI 寫到第一版，唔代表可以直接 ship；工程師仍然要讀 code、理解 trade-off、判斷風險。
• 測試邊界情況。 起 draft 快咗，唔等於可以跳過測試、debug 同 failure mode 思考。
• 守住架構。 生成 code 越容易，長遠維護成本越可能上升；邊界、依賴、簡潔度反而更關鍵。
• 為 production 結果負責。 系統可靠性、可維護性、用戶影響，最後仍然係人類團隊要承擔。

所以，AI 時代嘅強工程師，唔係最會叫 AI 寫嘢嗰個，而係最識判斷：咩應該叫 AI 做、咩要拒絕、咩要重構、甚至咩根本唔應該做。

Code review 會變得更值錢

AI-assisted coding 令第一版 code 變平、變快。結果係，真正稀缺嘅能力會轉去「把關」。

一個好工程師唔應該只係 prompt 完模型，然後照單全收。更理想嘅角色有啲似編輯、系統設計師同 operator 嘅混合體：將 AI 生成嘅 code 變成可靠軟件。佢要睇 implementation 係咪符合產品意圖、有冇踩中隱藏假設、同現有架構夾唔夾、日後其他團隊係咪維護到。

換句話講，如果團隊產 code 更快，瓶頸往往會由「寫唔寫得切」變成「邊啲 code 值得存在」。資深工程判斷，反而更重要。

經理都要識技術，唔可以只做協調層

Chesky 對經理嘅講法，同近 60% code 數字一樣值得留意。Airbnb 被報道嘅方向係：經理要同工作保持足夠貼近，自己懂得寫 code 或使用 AI coding 工具 。People Matters 關於「pure people managers」可能難以適應 AI 時代嘅報道，亦指向同一個趨勢：如果管理角色只係排會、追 status、做中間協調，壓力會越來越大 。

當然，呢個唔等於每個 engineering manager 都要變成團隊最強 individual contributor。但技術流暢度會越來越難逃避。

AI-heavy 團隊入面，經理至少要能夠：

• 明白 AI 工具有咩做到、有咩做唔到；
• 評估技術 trade-off，而唔係只睇進度表；
• 挑戰估算、設計、生成 code 入面嘅薄弱假設；
• 為 review、測試、安全、可靠性設定清晰 quality gate；
• 用已交付價值同系統健康度衡量團隊，而唔係用「人手打咗幾多 code」做指標。

經理仍然要招聘、教練式管理、定優先次序、照顧團隊健康。但喺 Airbnb 呢類走向 AI-native workflow 嘅公司，呢啲管理責任會同「親身理解工具同技術工作」綁埋一齊。

最大壓力唔係某個職銜，而係過窄嘅工作定義

真正高危嘅未必係「software engineer」或者「manager」呢個 title，而係角色內容只圍繞重複產出。

壓力較大嘅人，通常有以下特徵：

• 只寫 code，但唔理解背後系統；
• 接受 AI 生成結果，卻冇仔細 review；
• 用 task 數量衡量影響，而唔係產品價值；
• 只協調工作，但唔明技術本質；
• 迴避學習已經成為團隊流程一部分嘅工具。

相對安全嘅定位，是有判斷力嘅 technical operator：識用 AI 加速，但同時守得住質量、架構同結果。

而家應該點做？

對工程師嚟講，最實際唔係抗拒 AI，亦唔係盲信 AI，而係練成「AI-assisted delivery」能力：寫更清晰 specification、提供更完整背景、認真睇 diff、補足 test coverage，並持續投資架構、可靠性、安全同產品 sense。

對經理嚟講，重點係唔好離開手藝太遠。你未必要每日落場寫最多 code，但要實際用過工具，知道佢強弱位；要參與 design 同 review 對話；要將質量標準講清楚；亦要獎勵長期穩陣嘅產品成果，而唔係獎勵人手輸入量。

最後要留神：Airbnb 係訊號，唔係全市場標準

Airbnb 近 60% 呢個數字，是 Airbnb 自己嘅數據點，唔應該被解讀成所有軟件公司都已經去到同一階段。

Chesky 對 AI 嘅觀點其實同時包含加速同耐性。2024 年，他曾表示 AI 將會比好多人的想像更大幅改變世界，但亦會比很多人預期用更長時間發生 。用呢個框架睇，會比較準確：AI 可能深刻改寫軟件工作，但轉型一定唔會平均、唔會一夜之間完成。

結論係，AI 未必簡單地「取代」工程師或經理；它正在改變兩者嘅貢獻單位。工程師要由單純生產者，變成 AI 產出嘅導演、審稿人同負責人；經理要有足夠技術流暢度，先帶到每日使用 AI 嘅團隊。喺 Airbnb 呢個案例入面，長遠優勢正由手動產出，轉向判斷、ownership，以及將 AI output 變成可靠產品嘅能力 。