一覺醒來20個PR自己合進了主幹，SpaceXAI工程師：我基本不看代碼了

清晨打開電腦，原本預期要先泡杯咖啡、慢慢檢視前一晚堆積的程式碼變更，結果畫面顯示的卻是二十個 Pull Request 已經被自動合併進主幹。這是 SpaceX 一位 AI 工程師的真實日常。他近期透露，自己如今「基本不看代碼了」，因為從程式碼生成、提交審查請求，到測試通過後直接合併，整個流程都已經交由 AI 自動完成。AI 寫程式早已不是新聞，從程式碼補完、錯誤修正到單元測試生成，開發工具鏈中的 AI 應用越來越普及。但 SpaceX 這個案例的關鍵差異在於，AI 不只是「寫」程式碼，而是連程式碼審查與合併流程都一起包辦。

換句話說，AI 的角色已經從輔助人類開發者完成片段工作的工具，升級為能獨立完成整個開發循環的主動執行者。這名工程師表示，自己睡一覺醒來，二十個 PR 就已通過測試並合併進主幹，整個過程他幾乎沒有介入。對旁觀者來說，這或許聽起來像科幻情節，但對這名工程師而言，這已經是他的日常工作狀態。他坦言，自己現在「基本不看代碼了」，因為 AI 不但能產出程式碼，還會自動提交 PR，並在跑完測試後直接合併，他作為工程師的例行性工作因此大幅減少。這種「無感開發」的體驗，聽起來像是開發者的終極夢想：不用再盯著 diff 逐行檢查，不用反覆在 CI 失敗的 log 裡找原因，也不用為了合併衝突傷腦筋。

當 AI 把這些繁雜的例行工作承接過去，開發者確實能騰出更多時間與心力，專注在更有價值的架構設計、系統規劃與產品思考上。從這個角度來看，自動化的價值不僅是節省時間，更是在重新分配工程師的注意力。不過，這也並非 SpaceX 內部單一的偶發案例。這名工程師強調，會有這樣的結果，是因為團隊持續導入自動化開發流程的長期累積。從他描述的工作方式來看，AI 已經融入開發流程的每一個環節，從程式碼生成到最終合併，形成一條完整的自動化鏈路。這背後代表的不只是工具的成熟，更是團隊對自動化流程建立的信心。然而，高自動化也伴隨著不容忽視的隱憂。

程式碼品質與安全性是軟體開發中永遠的核心議題，而人工審查一直被視為把關的最後一道防線。當 AI 自動生成程式碼、自動提交、自動合併，如果 AI 生成的邏輯有誤，而人工審查又被省略，那麼錯誤就可能在不經意間被悄悄帶入生產環境。尤其在某些關鍵系統中，一個看似無害的邏輯疏漏，可能造成的後果遠比開發效率的損失來得嚴重。這也正是這起事件引發討論的原因。一方面，自動化的效率提升顯而易見，二十個 PR 在一夜之間自動合併，這是過去任何開發團隊都難以想像的速度；但另一方面，當開發者坦言「不看代碼」時，許多人心中難免浮現疑問：如果連寫程式的人都不看程式碼了，那誰來為程式碼的正確性負責？

如果責任歸屬變得模糊，軟體工程的專業界線又該如何重新劃定？事實上，「不看代碼」並不代表工程師對程式碼完全放任不管。更精確地說，這意味著工程師的關注重心從「每一行程式碼的細節」轉移到「整個系統的運作邏輯」。傳統開發流程中，工程師花大量時間在檢視實作細節；而在高度自動化的流程中，工程師的價值體現在設計架構、定義規範、設定品質標準，以及判斷 AI 的行為是否符合預期。這不是對程式碼品質的放棄，而是把審查的層級從「行」提升到「系統」。但不可否認，這樣的工作方式對團隊的工程文化與基礎設施提出了更高的要求。自動化合併必須建立在足夠完善的測試覆蓋、明確的程式碼規範以及可靠的 CI/CD 管線之上。

如果缺乏這些前提，AI 自動合併帶來的恐怕不是效率，而是災難。也就是說，自動化程度越高，對工程紀律的要求其實越嚴格，而不是越鬆散。SpaceX 的這個案例，無論如何都代表了軟體工程領域一個值得關注的訊號。當工程師醒來發現二十個 PR 已自動合併，這不再只是 AI 幫人類寫程式的故事，而是 AI 開始替人類做決策的故事。程式碼哪裡要改、改了之後怎麼驗證、驗證通過後要不要合併，這些過去需要人類判斷的環節，如今都開始被自動化系統接管。從輔助工具到主動執行者，AI 在軟體開發中的定位正在快速位移。對開發者而言，這既是解放也是挑戰。

解放的是重複勞動帶來的負擔，挑戰的是如何在「把工作交給 AI」與「確保產品品質」之間找到新的平衡點。而 SpaceX 工程師那句「我基本不看代碼了」，或許聽來有些顛覆，但同時也預示著：未來軟體工程師的工作方式，可能正在從「寫程式的人」轉變為「定義程式該怎麼被寫的人」。這段時間以來，AI 對軟體開發流程的滲透速度之快，已經讓許多人開始重新思考工程師的角色定位。如果連 SpaceX 這樣的頂尖團隊都開始擁抱全自動化的程式碼合併流程，那麼「無感開發」或許不再只是實驗性的嘗試，而是一個正在成形的新常態。至於這個新常態會把軟體工程帶向更高的效率，還是潛藏著尚未被充分理解的風險，恐怕還需要時間來驗證。