Linus Torvalds 也開始 Vibe Coding，軟體工程師就玩完了嗎?

今天要來跟大家聊一個最近在社群當中討論度非常高的話題。Linux 作業系統的作者 Linus Torvalds 發布了一個新的開源專案，在這個開源專案當中，他使用 Google 的 AI IDE Antigravity 搭配 Vibe Coding 做了一個 Python 的視覺化工具。這件事情之所以會成為討論的核心焦點，是因為在過去一年自從 Vibe Coding 被提出之後，有非常多的軟體工程師對 Vibe Coding 感到嗤之以鼻，覺得 Vibe Coding 只是給那些不懂程式的人來用的。但沒想到在軟體工程業界當中的頂尖人物 Linus 竟然也開始 Vibe Coding 了。

當大家看到 Linus 開始 Vibe Coding 後，社群中就隨之出現軟體工程師要玩完了的言論。如果你到 X 上面可以找到非常多類似的言論。但真的是這樣嗎?在這支影片當中，我們想跟大家聊聊這個主題，包含 Linus Torvalds 開始用 Vibe Coding，他究竟是怎麼看待 AI 來做軟體開發的，以及 Linus 開始做 Vibe Coding，那其他的軟體工程師就完蛋了嗎?難道現在大家都要開始做 Vibe Coding?以及最後在 AI 時代下，傳統軟體工程的角色在哪裡?

Linus Torvalds 如何看待 AI 輔助軟體開發

事實上我們可以先回顧一下，在 2023 年也就是 ChatGPT 推出了一年之後，Linus 在 Linux Foundation 的對談當中，其實有提到他是用非常正面樂觀的態度來看 AI 工具。因為他認為這些 AI 工具是能夠幫助工程師去把眼前的任務做得更好的。

他有進一步提到，他在他的職業生涯當中寫過非常多的 bug，也看過其他人寫非常多的 bug。而在這些眾多的 bug 當中，絕大多數都不是一些非常微妙的、需要去注重非常多細節跟極端案例的 bug，多數的都是一些大家可能只是沒有想到的愚蠢的 bug。在過去其實是可以透過像編譯器之類的工具去幫忙找出一些明顯的錯誤然後發出警告。而在現在有了大型語言模型、有了 AI 之後，除了這些編譯器已經能夠去幫忙抓出的明顯的問題之外，他認為 AI 是可以去幫忙抓出一些不是這麼顯而易見的問題。也因此他是用一個非常正面的態度來看待 AI 工具的。

而讓我們快轉到 2025 年年末，因為 Vibe Coding 這個詞是在 2025 年初被提出的。到了 2025 年末，在 Linux Foundation 的對談當中，Linus 不免俗的會被問到他對於 Vibe Coding 的想法。而在當時他其實有提到，他覺得 Vibe Coding 很好也很糟。這聽起來好像有一點矛盾，我們進一步來看一下他怎麼說。

首先他覺得 Vibe Coding 很好，因為他認為 Vibe Coding 能夠用來做一些個人的小專案，這件事情其實是很不錯的。他認為撇除那些希望靠 Vibe Coding 可以做出 10 億美元估值公司的人，他覺得 Vibe Coding 是個讓人興奮的、新的、好的事情。他有進一步在對談當中提到，在他的那一個年代，大家要去上手程式其實是有一個門檻在的。而隨著技術的演進，其實這個門檻會隨著技術變得更複雜而變得更高。但是現在有 Vibe Coding 這樣子的工具，是可以讓想要跨過這個門檻的人能夠用一個更輕易、更簡單的方式。所以他是持著一個非常正面的態度去看 Vibe Coding 的。

所以看到他在 2025 年末的對談提了這樣的觀點，其實也不意外他在 2026 年年初 1 月的最開始，就用 Vibe Coding 發了一個新的開源專案。而也因為這樣子，很多人就提到 Linus 也開始 Vibe Coding 了，所以軟體工程師就完蛋了，現在大家 Vibe Coding 就好。但真的是這樣嗎?

Vibe Coding 的侷限性

還記得我們剛剛有提到，他在這個對談當中有提到 Vibe Coding 很好也很糟。那好的地方我們講過了，糟的部分又是什麼呢?事實上這個很好跟很糟的區別，其實是看情境的。還記得他前面講到，他認為 Vibe Coding 拿來做一些小的專案，或者用來跨過學程式的這道門檻，他認為是很好的。但是假設就一個開發產品從長期維護的角度來看，他覺得 Vibe Coding 可能是一個糟糕透頂的主意。

他在那個對談有談到，真正有影響力的大型複雜的專案當中，多數人最後會發現 Vibe Coding 是沒有辦法被長期使用的。他做 Linux 這個作業系統已經快 35 年了，這 35 年的歷程當中，真正的工作、最重要的那些工作，其實都是在維護跟持續的支援上。舉例來講，今天某一個新的硬體被推出了，Kernel 就需要去做相對應的改動去更新。他做 Linux 已經做了 35 年，但是還是持續地跟著開源的貢獻者們一起去修正核心的程式，讓核心的程式碼變得更漂亮、更容易維護以及更穩定。

所以從這個角度來看，是可以理解為什麼他認為從長期維護的角度來講，Vibe Coding 是沒有辦法派上用場，而且是一個糟透的主意。事實上也不只是 Linus 提了相關的觀點，在開源社群當中也有非常多人有提過類似的觀點。

舉例來說，Mitchell Hashimoto 也是在開源界中非常有名的一個人，是 HashiCorp 的創辦人，也是現在非常熱門的一個開源專案 Ghostty 的作者。他就有提到，他認為那些盲目的使用 AI 然後去提交一些垃圾程式碼的人應該要被公開出來，然後讓開源專案的維護者知道他們然後封鎖他們。假如你有關注 Hashimoto 的話，可以發現他在過去一年當中其實是非常非常的提倡使用 AI 來協助軟體開發的。但即使作為一個 AI 的擁護者，他看到了這些被提交出來的 AI 垃圾，他還是感到非常的生氣。

因為當今天這些人沒有去嚴格的檢視他提交的東西，會導致的問題就是這些專案的維護者，他們需要花更多的心力去讀那些垃圾的程式碼，然後去拒絕，然後浪費時間，不能把時間花在更重要的事情上面。

所以總結一下，假設今天你是在一個企業等級的專案，或者是在 Linux Kernel 這種等級的大型開源專案當中用 Vibe Coding，一來會浪費其他開發者、維護者的時間，二來假設真的 Vibe Coding 出來沒有被嚴謹檢視過的成果被合併進去，就會導致整體的程式碼品質下降，長期的維護成本更高。

軟體工程師會玩完了嗎?

所以回到我們這一段想要跟大家聊的，今天 Linus 開始 Vibe Coding，軟體工程師就玩完了嗎?我們並不這麼認為。至少 Linus 他本人就說了，在寫 Linux Kernel 基本上是不會看到 Vibe Coding 的。假如前面這一段有說服你，即使 Linus 開始 Vibe Coding，軟體工程師也不會玩完。

相信大家可能還是會有一個問題，在 AI 時代下，傳統的軟體工程的角色又在哪?這邊我們截了一張，也是在社群當中非常有名的 The Pragmatic Engineer 過去發的一個貼文。在這個貼文當中，他談到一個他認為可能是不太受歡迎的觀點，是隨著 AI 工具的普及，傳統的軟體工程的最佳實踐會變得更有價值，舉例來講測試、可觀測性或者持續交付等等。

雖然他非常謙虛的說這可能是一個不受歡迎的觀點，但是我們看到這個是覺得點頭如搗蒜，覺得非常的認同。舉例來講，假設今天在一個大型複雜的專案當中，但是這個專案當中沒有測試，然後你請 AI 去幫你改了某一段程式碼，你要如何確保 AI 改的東西不會導致其他的程式碼被影響到，不會導致改了這邊另一邊炸了?假設專案當中沒有測試，其實你很難有這樣的信心。而假設今天你想要讓 AI 更大幅度地幫你自動化，你是應該要有信心確保 AI 做的改動不會影響其他的部分。

所以從這個例子可以看到，假設今天一個專案有測試跟另一個專案沒有測試，有測試的那一個專案其實是更適合讓 AI 來協作的。所以傳統的軟體工程的價值，其實是能夠去協助讓 AI 把我們交付給 AI 的事情做更好的一個非常重要的元素存在。

軟體工程師的守門人角色

而除了傳統的軟體工程的這些最佳實踐之外，傳統軟體工程師在做的把關，在 AI 時代也是同樣的會顯得更加的重要。事實上在 2025 年，Linus 在 The Linux Foundation 的那場對談當中，他有提到他其實已經不當程式設計師長達 20 年了。他提到他在過去 20 年的角色，主要是技術的領導跟系統的維護者，而實際寫程式的是來自全世界各地的開源的貢獻者，他不是實際去寫程式的那一個人。

大家有沒有覺得他的這段描述有一種似曾相識的感覺?因為現在多數人在使用 AI 來幫自己做軟體開發，也是類似這樣子的關係。AI 是那一個去幫我們實作的角色，而我們做的角色更像是一個技術的領導跟系統的維護者，是負責去把關的。

假設大家有印象的話，在 2025 年中的時候，Linus 他曾經拒絕一個前 Google 工程師提交的某一段程式，而這個拒絕在社群當中也引起很大的討論。Linus 他去拒絕這一個程式碼的貢獻，最核心的點是因為這位工程師他提交的程式碼多拉了一層不必要的抽象。而今天 Linus 他之所以能夠去拒絕，是因為他有技術觀點，他對於模組化、對於抽象化有掌握，他知道多了這一層不必要的抽象，對於 Linux Kernel 的整體的可維護性是有害的。

所以即使在過去 20 年 Linus 他不是實際去寫程式的那一個人，他仍然是在整個系統當中扮演非常非常重要的角色，作為一個守門人的存在。而我們認為在現在以及在未來，當軟體工程師跟 AI 互動的時候，也是必須要扮演好這樣子守門人的角色，才能確保在放大生產力的同時，品質不會下降。

以上希望透過最近在社群當中討論度非常高的這個話題，來跟大家聊聊軟體工程師與 AI 之間的關係。假如你想要更加的善用 AI 在做軟體工程，我們過去有做了一門 Cursor 入門到實戰課程，也有把所有的教材免費的放在網路上。你只要在 Google 上面搜尋 Cursor 入門就可以找到，在 Google 的 SEO 排名上甚至是高於 Cursor 的官方教學。

除此之外，如果你想鍛鍊能夠把關 AI 產出的技術觀點，我們在我們的 YouTube 頻道當中也有一些影片，推薦大家有空的時候可以觀看。最後如果你是軟體前後端的工程師，想要在職涯中持續的成長，打好技術的基礎，培養技術觀點，歡迎加入 Eplus 成長計畫。我們有完整的前後端的知識路徑以及線上課程，還有專屬的 Discord 成長社群。大家可以在 Google 上搜尋 Eplus 成長計畫就可以找到，我們也會把相關的資訊放在下方的資訊欄。

以上，感謝大家的收看，我們下支影片見。