直覺式開發(vide coding)時代來臨,軟體架構重要性與日俱增

直覺式開發(vide coding)時代來臨,軟體架構重要性與日俱增

最近兩個月,同溫層中興起一陣直覺式開發(vibe coding)的風潮,鼓勵大家用自然語言進行軟體開發。短時間內我就看到許多非技術背景的朋友們紛紛跳下來嘗試,也有些人真的做出一些有趣的東西。

我認為這種讓沒有技術基礎的人,也能開發軟體的概念,其實跟早些年 Windows 95 的圖形化介面,讓不懂得命令列(command line)的人也能使用電腦是相似的概念。

這是資訊科技進步的必然。再往下一階段,腦機介面的突破,還會進一步讓那些語言表達能力沒那麼好的人,也能透過腦袋中的想像來跟電腦互動,讓電腦幫忙完成程式開發。這很可能是下一波人機介面的革命。

但在這種革命發生的早期,許多的配套工具還未完善,但已經開始有大量的人投入使用。這些人寫出了一大堆無法維護,甚至無人能清楚解釋,但又運作正常的程式碼,這等同於創造了大量的技術債務。所以也有另一派人在討論,vibe coding 產出大量難以維護的程式碼,未來維護這套軟體的人將會身受其害。

從前寫程式的進入門檻較高,所以寫出來的程式再怎麼糟糕可能都還有人知道怎麼維護,所以 junior engineer 可能會寫出一些爛 code,但數量不多,且還能維護。

但現在進入門檻幾乎消失,重點是大家根本也不知道自己寫的 code 到底是怎麼運作的,更不用說要維護了。加上這些 code 其實也不大需要動腦筋,所以大家都放心的產生一大堆無法維護的程式碼。

人人都能輕易入門,這件事很棒,但輕易入門的代價則是大家會瘋狂寫出一大堆難以維護的程式碼。以前技術債的堆疊速度假設是 1,現在有可能變成 10,本來要花上 10 年才能堆出的技術債,現在可能只需要一年。

如果中間創造的價值也有 10 倍,那企業主也能心甘情願承受,可一般沒有那麼好的事情。

以砌牆為例,砌一面牆時,我們需要先明確幾件事:

  • 這面牆的目的是什麼?(防風、防盜、裝飾?)
  • 成品標準?(高度、寬度、承重力、外觀平整度)
  • 牆體結構要怎麼設計?(直線、弧形、厚度、留孔洞?)
  • 地基需不需要加強?(承載力?濕地 or 乾地?)

如果砌這面牆時,我們需要與他人協作,那我們還要進一步確認幾件事:

  • 砌磚的方式要統一(橫砌、交錯砌)
  • 磚與磚的間隙寬度、砂漿比例
  • 每一層磚的水平與垂直校正方式
  • 誰負責打地基?誰負責砌磚?誰負責監工?
  • 若有多人同時砌牆,接縫處誰負責對齊?
  • 每砌一段,要不要即時校正(level check)?

你可以想像一下,如果蓋一棟大樓時,沒有先畫好藍圖,也沒有先針對上述問題做好規劃,開工後每個人都按自己的方法去施工,最後會出什麼樣的結果?

  • 不同牆面的材質不同、承重能力不同
  • 不同牆面的高度不同、連結處不對齊也不平整

上述問題,如果是在施工過程發現,那就像 bug 在開發過程被抓出來一般,只是增加了重工的成本,不至於造成過大的風險。但如果是在蓋好後,因為地震或其他因素發現當初施工的問題,那很可能是以人命為代價。(參考:測試左移,我們該關注的是需求的 bug 數還是程式的 bug 數)

AI Coding 需要留意的事項

Cursor 的設計主管在 X 上分享過他認為使用 AI Coding 時需要注意的 12 件事

  1. 預先設置 5-10 個清晰的專案規則,以便 Cursor 瞭解您的結構和約束。簡單的說就是先設定好團隊在進行系統開發時的一些基本原則,例如 coding style。
  2. 提示要具體。像撰寫規格一樣闡明技術堆疊、行為和約束。
  3. by file 生成、測試和 review,關鍵是在「較小的範圍」內進行
  4. 首先編寫測試,鎖定測試,然後生成代碼,直到所有測試都通過。
  5. 檢查 AI 輸出並修復任何錯誤的內容,然後告訴 Cursor 原因,將這些錯誤修復作為與 Cursor 協作的範例
  6. 使用 @ file、@ folders、@ git 協助 Cursor 的注意力定位到 codebase 的正確部分
  7. 設計文件和清單保存在 .cursor/ 中,以便 AI 代理能在具有清楚脈絡的狀態下知道下一步該做什麼。
  8. 如果 Cursor 給出的代碼錯誤,就自己寫吧。Cursor 從編輯中學習的速度比從解釋中學習的速度要快
  9. 使用聊天記錄迭代舊提示,而無需重新開始。
  10. 有意識地選擇模型。要精確性用 Gemini,要廣度用 Claude。
  11. 在新的或不熟悉的堆疊中,將完整內容貼上。讓 Cursor 逐行解釋所有錯誤並修復。
  12. 讓大型專案在夜間編製索引,並限制上下文範圍以保持性能敏捷。

許多內容就是一語帶過,但我們可以推敲其背後的意涵。

規範化、明確而具體定義、小範圍、持續迭代、足夠資訊、測試先行,這些都算是軟體開發一直以來的管理重點,即便在 AI 時代,這些觀念也仍舊重要。

而這些其實都與軟體開發過程的軟體架構與開發規範有關。

在 Vibe coding 年代,人人都有能力寫些小程式,軟體功能的發展將會以飛快的速度推進,而在這樣的年代裡。

那些能做軟體架構設計,能定義開發規範的資深工程師與架構師的身價,將會水漲船高。

如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

當 vibe coding 已成必然,軟體開發會有什麼變化?

當 vibe coding 已成必然,軟體開發會有什麼變化?

當 Vibe coding 興起後,有愈來愈多的資深工程師的工作重點轉換到修復 AI 寫出的各種 bug。因這個現象,有些資深工程師們打趣地說,他們現在的任務像是專門處理這些 vibe coder 寫出來的爛 code。而這個職務稱為 Vibe Coding Cleanup Specialist。 我個人絕對支持 vibe coding,因為這是軟體開發的典範轉移,用得好的話可以大幅提升生產力,加上 AI 顛覆職場的趨勢幾乎不可逆。擁抱變化會比抗拒變化更明智。 這讓我回想起 2005 年剛出社會時,因為我起步的程式領域是 C#.net,使用的開發工具是 Visual Studio。C# 的好與壞我就不提了,但在當年,Visual Studio 這工具被稱為地表最強 IDE 應該是沒問題的。 它有多方便呢?所見即所得,元件直接拉到畫面上,出來的畫面就長那樣,

By gipi
主動改變或被動被改變

主動改變或被動被改變

「像恆溫器(thermostat)一樣改變環境,而不是像溫度計(thermometer)一樣被動測量環境」 如果環境不好,但你又想繼續待在這個環境,那你能做些什麼? 分享兩個以前團隊中年輕夥伴的故事,一個剛畢業,另一個則只有兩年工作經驗。 第一位是當時公司招募的儲備幹部,剛進公司月薪就有兩萬人民幣,這薪資高過公司內最少 80% 以上的員工。公司對這些人有著高期待,也為他們安排了一系列入職培訓,希望將他們培養成公司未來的骨幹。 而在計畫開始時我也擔任了面試官的角色,在面試過程我聊到一位很適合做產品的年輕夥伴,他在幾家網路公司都有實習經驗,而且能清楚的說明他負責的工作項目,針對我的提問「如何優化數字」、「如何做計畫」、「如何修正錯誤」等問題都能回答得很好。 面試後我跟 HR 說,我想跟這位談談能否放棄儲備幹部計畫直接到我們部門任職。HR 說只要對方同意就沒問題。 我找這位年輕夥伴聊,清楚地跟他說我為什麼希望他能加入我們團隊,可同時也跟他說我們給的薪資肯定不如儲備幹部,而少了這個光環,他要被看見就得靠自己的表現了。但我能跟他保證的是我們部門這個職務能讓他成長得更快。 他跟我說:「

By gipi
大語言模型對軟體開發的影響

大語言模型對軟體開發的影響

近期閱讀了一份文件,內容是關於大語言模型對軟體開發工作的影響,文件的連結在這:Assessing and Advancing Benchmarks for Evaluating Large Language Models in Software Engineering Tasks 這份文件聚焦於大型語言模型(LLMs)應用於軟體工程(SE)領域的效能評估。這是個有趣的題目,所謂的效能,簡單的說就是能直接在該工作任務中大幅增進效能的比例。 大家都知道現在的 AI 寫 code 已經不是什麼大不了的事,但透過 vibe coding 寫出來的 code 真的可以用嗎?符合需求嗎?品質可以嗎?能被維護嗎? 關於這些問題,我們要如何衡量 AI 的有效性呢?目前的答案是透過 Benchmark(基準)。 舉例來說,之前有的 benchmark 叫 SWE-bench,

By gipi
溝通,不是把能說服自己的話拿來說服他人

溝通,不是把能說服自己的話拿來說服他人

還記得幾年前有個朋友私訊給我說了一段趣事。 他說公司有個同事援引了我在演講中提到的一句話:「敏捷走不出研發,就不能真正敏捷。」 他試圖用這句話來告訴業務團隊們「業務必須要參與到敏捷中,開發團隊必須要更了解業務狀態,我們才能真正發揮敏捷的效益。」 我那句話的本質跟他說出來的話,在意義上其實毫無分歧。 但他獲得的結果卻是被業務部門修理了一頓。業務部門告訴他:「這不是你該管的範圍,你應該專注把你的任務搞定。」 這邊姑且不論誰的想法才是對的,但我想跟大家分享一個我在溝通過程很重要的體悟。 「所謂的溝通,不是把能說服自己的話拿來說服他人。」 「所謂的溝通,不是把能說服自己的話拿來說服他人。」 「所謂的溝通,不是把能說服自己的話拿來說服他人。」 很重要,所以得說三遍。 我們讀書總會讀到很多很有道理的話,並且被這句話說服了。但千萬要記得,這句話能說服自己,不意味著能說服他人。因為我們的立場不同,遭遇的挑戰不同,先備知識也不同。所以一段自己覺得非常有道理的話,我們必須加以轉換後,才有可能說服他人。 舉個例子來說,做研發的會希望根本的理解一個需求背後的商務價值,因為這

By gipi