AI 時代的軟體開發變革-趨勢

AI 時代的軟體開發變革-趨勢

前陣子一直想寫這個題目,因為我認為未來的產品開發,將因為 AI 的出現有劃時代的改變,這變革或許不亞於當時數位時代的來到。

在往下談論主題前,我們可以先問問自己,過去一年的時間,我們對 AI 能做的事是否有了全新的改變?

以我自己為例,我半年前曾說:「AI 目前的不足之處在於處理技術債,也就是維護的難度還是很高。」半年時間過去,我現在認為這不會是很複雜的問題了,一來是因為 AI 又進化了,推理能力更強了,還懂得反問好問題;二來則是因為當時我對 AI 的期待太高了,我希望他全知全能,但其實為他做好角色設定才能發揮他最大的效果

半年前我無法想像他能直接解讀一份我給的文件或者某個架構圖,但近期我嘗試的結果卻發現他解讀正確的成功率之高,根本超乎我預料。而當我根據他的回應再補上一些資訊落差之處,他幾乎就能 100% 產出我所期待的內容。這種理解能力與產出品質,幾乎超越了 90% 以上的人類

這讓我更確信,人類在軟體開發工作的未來,絕對不會是在 AI 擅長的領域,而在於創造、設計、決策與溝通

前陣子我曾援引 Sam Altman One-Person Unicorn 的說法:「在不久的將來,可能會有一些公司只有一位 CEO,其他的工作全部都由 AI 來完成。」

One-Person Unicorn,一人獨角獸的時代來臨?
2024 年 4 月份 Sam Altman 提出 One-person unicorn 的時代來臨了,他強調的是在不久的將來,可能會有一些公司只有一位 CEO,其他的工作全部都由 AI 來完成。而且這樣的公司不見得就是傳統小規模的一人公司,而是有機會成為一家獨角獸公司。 經過這半年多對 AI 的學習之旅,自己天天用 AI 工具,並用 AI 工具來解決具體問題。也聽了許多公司如何使用 AI,並參與了一些公司的開發團隊使用 AI 做軟體開發的過程。 我想藉由這篇跟大家分享一些我對 AI 融入工作與生活的想法。 相信 AI 做得到 我相信現在還是很多人在探討 AI 「做得到什麼」與「做不到什麼」。而這種想法的背後,往往是為了找到不使用 AI 的理由。 例如透過 AI coding,

這個想法的背後,他其實在強調 AI 能做到的事將不再是單點,而是整合,也不再殘缺不全,而是能完整交付

AI 將從工具,晉升為一個個可以獨立作戰的專業人士。而且我相信,這條路應該不遠了。


前陣子看到 Sam Altman 受訪時提到:「到 2025 年底,軟體工程與 2025 年初的軟體工程會截然不同。」

因為專訪過程他只講了這句,沒有其他解釋,所以我拿這個問題去問 ChatGPT。

ChatGPT :「AI 將從「AI 助手」到「AI 共同開發者」。」

目前 AI 主要用於 代碼補全(Copilot)、程式除錯、文件生成、簡單自動化。

但到年底時,GPT-5 或其他更高階的模型推出後,AI 將能做到

  1. 自動補全大規模代碼塊(不只是幾行,而是數百行)。
  2. 根據模糊需求生成完整應用程式,降低進入門檻。
  3. 開發週期大幅縮短,以前需要數週的專案可能幾天內完成。

而工程師的角色也會從「寫程式」轉向「監督 AI 開發」。

且未來軟體開發的方式將會發生轉變:

  1. 工程師價值轉向「問題定義、需求設計、AI 驗證與優化」。
  2. 低代碼、無代碼開發更普及,非技術人員能夠利用 AI 生成應用程式。
  3. 「AI 導向開發(AI-Driven Development)」取代傳統開發模式。

簡單的說,未來的工程師,主要是做開發的最前面的需求釐清、架構設計,以及最後的測試與驗收步驟。而中間開發的工作,將會大幅交由 AI 來完成。


現階段比較難想像的還是「根據模糊需求生成完整應用程式」,但我猜測 AI 的大語言模型,應該能透過幾種方式去做到:

  1. 透過一些預先設置或已經累積的數據,試圖完善需求,並從大量數據中找尋相似性需求。
  2. 大語言模型最終應該能建構起不同行業、領域的完整 domain know-how,很可能一聽需求就能瞬間理解,甚至自行衍生。

就像開發團隊接手一個系統時,也不一定需要把所有規格都爬一次才知道某些功能怎麼設計,也是能自己爬 code,或者根據相似的系統來完善規格。

以當前 AI 展現的能力來說,我覺得補完規格這件事應該也不是完全做不到,畢竟能推理,還能主動提問,加上未來語音下 prompt 也會更簡單,手繪規格,或者提供相似網站、相似功能給 AI 參考。這些應該都能提高 AI 完成開發任務的準確性。

真的到了這個階段,那以開發能力來說真的比一般工程師更強大了。而能做到這些的 AI,我想什麼搞不懂技術債、domain know-how 的問題應該也能被解決了。


不過昨天剛好又看到 IEObserve 分享了一篇報告:https://arxiv.org/pdf/2502.12115

這個關於 AI 能搞定多少軟體開發工作的研究,覺得很有趣,其實正文也不過就 9 頁,有興趣的朋友都可以個半小時看看。

這算是拿一個較接近真實世界的軟體開發任務來直接做驗證,研究將任務分成兩大類,一類是工程師的任務,也就是偏向程式撰寫,另一類則是工程經理的任務,也就是偏決策,包含技術選擇,解決方式選擇。

對於工程類的任務,判斷的基準並不複雜,就是 AI 寫程式,然後看人類寫的單元測試能否通過,如果通過就得分,否則就 O 分。

而對工程經理的任務則是要要在多個解決方案中做出最佳選擇,驗證的方式則是看人類工程經理的選項是否跟 AI 相同,相同就得分。

幾種模型的最終結果是 Claude 3.5 Sonnet 的整體表現最佳。

從數據上直接解讀,我們可能會說:「AI 要取代工程師還早得很。」

但這麼說並不公允,因為從這個測驗中我覺得有幾個很值得看的地方:

AI 在完成工程師任務的成功率較低,但在完成工程經理任務的成功率顯然較高。

我認為這是兩種不同驗證方法的嚴謹性有關,工程師類的任務,要通過單元測試,這代表結果必須要完整無誤,難度上本來就比較高。工程管理類的任務,比較像是一種偏好選擇,AI 只要掌握了大原則,一般就能做出品質還不差的判斷。

加上為了有效測試,測試集的題目也不會刻意設計有一大堆商業、組織政治的考量,所以問題應該是相對單純的。

這個測試中,AI 其實是處在一個沒人可以請教,試錯次數有限,還沒有人能直接手把手指導的狀態。

這與一般工程師在工作中的狀況不同,所以成功率顯然會比較低,但如果有人回饋,有人補上文件,有人完善註解,有人教育訓練。然後讓 AI 在這樣的基礎下可以做多次嘗試,我相信成功率應該會提高許多。

現階段要把 AI 當成一個可完全獨立作業的工程師還是很難的,過程仍須仰賴人類的回饋與建議,但這並不代表 AI 還無法取代人類。

因為工作其實是由一個個任務組成,只要重新做任務的分配,兩個人各有一半任務可以由 AI 取代,人類工作量少了一半,那等於可以少掉一個人,然後調整另一個人的工作範疇,讓他去學習另一個人尚未被 AI 取代的任務即可。

不用覺得不可能,在這個時代,有 AI 輔助的狀況下,掌握一門新技能的門檻大幅降低,任何人都有機會透過訓練與學習升級自己的技能。

AI 取代的,一直都不是人,而是任務,當你的工作任務被完全取代了,你這個人自然也沒有存在的必要了。

未來幾年應該會是軟體開發的革命時期,大量的任務會被 AI 取代,而人與人之間的分工也會因此產生大幅改變。有些職務會不再存在,有些職務則會被創造出來,有些職務則會被重新定義。

下一篇我們接著聊我看到即將改變的幾件具體事項吧。

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

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

Read more

讓會議開的更有效率六個要點

讓會議開的更有效率六個要點

開會,是每個職場工作者都無法避免的工作任務之一,懂得開會的人,工作效率一般很好,也能透過會議解決許多的問題。但也有很多人即便開了數百次會,還是無法把會議開好。 如何開好一個會議呢?往下我將跟大家分享我過去開會的方法。 首先,請記得以下幾個原則,會議最忌以下幾件事: 第一,會而不議,大家聚在一起了,卻沒有討論什麼重要的事 第二,議而不決,討論了議題,但卻沒有做出任何決議 第三,決而不行,大家決定好怎麼做了,但卻沒有採取任何行動 緊接著,就讓我們來看看有效開會的步驟與方法吧。 1.目的要清晰 年輕的時候如果有人邀請我去開會,我通常也不太問為何需要開這個會,而是先到現場再隨機應變,有時討論的議題我熟悉,我便能侃侃而談,但若是我不熟悉的主題,然後我也沒準備,去到現場大概就是幫忙製造二氧化碳。 年紀稍長,開始覺得時間異常重要,每次會議前我總會先詢問:「今天要討論什麼?會議結束後期望得到什麼結論? 」 若今天是專案啟動會議,那你的目的是取得大家的承諾,你一定要把你要他人承諾的事情寫在專案議程中,並逐一獲得大家的承諾;如果是決策方案會議,那你要把候選的方案條列,並說明不同方案間的優劣

By gipi
例行性會議,反應了一家公司管理的素質

例行性會議,反應了一家公司管理的素質

要看一個主管的管理品質,就看他怎麼開例行性會議的。 只要讓我參與幾次例行性會議,我就知道團隊目前的問題在哪了。 例行性會議會凸顯以下資訊: 1. 團隊是在解決問題,還是在彙整資訊。 2. 團隊是主動找答案,還是在等主管作主。 3. 主管是否善用引導與提問來提升團隊能力。 4. 會議的主軸是否清晰,反應了團隊運作是否高效。 5. 團隊是缺乏意願、意識、能力任一或多種。 其實例行性會議就是團隊運作的縮影,這是團隊慣性,騙不了人。 你相信嗎?只要改變例行性會議的報告內容、進行方式與跟進工作,團隊的整體能力也會有大幅度的提升。 這就是我常講的「管理槓桿」,從小的改變來撬動大的變化。 幾乎每個公司、每個部門都會有例行性會議與報告,很多人可能覺得這樣的會議很沒意義,就是大家形式上做做樣子,把要講的講一講就結束了,但如果,你希望把管理做得更到位,那例行性會議對你來說就非常關鍵,重要性甚至遠高於月會。 例行性會議是你跟團隊互動的好機會,而月會一般是面對老闆,兩者的對象不同,重點不同,報告方式也不一樣。 本文我暫且回到例行性會議上,身為一個主管或會議主持人,在聽工作報告時,

By gipi
降低不確定性,提升成功率

降低不確定性,提升成功率

昨天在幫一家企業上管報相關課程,課堂中我有張投影片放了兩家企業逐月的營收表現。A 企業的表現高底起伏很明顯,B 企業則表現相對較穩定,但這兩家企業全年的業績總額是一樣的。我問大家:「兩間公司讓你選一間,你會覺得哪間公司更棒?」 大家不約而同地選了 B 企業。我進一步問大家:「為什麼?」 我獲得得答案是:「B 企業感覺較穩健,而且看起來逐季在成長。」 B 企業會被認定為穩健,跟他的營收波動較小有關,一家營收波動小的公司,我可以合理相信他對營收的管理有一套方法在,知道做什麼事可以提升預估業績與實際業績間的一致性。 同一堂課程中,我分享了另一個案例,這個案例是在某次的業務週會上,有個部門的業績未達標,落後了30%左右,此時業務主管表示他們可以在本週補上落後的業績。 我問他:「你如何做到?」 他告訴我:「我會督促團隊努力做,拼命做,總之,本週一定會趕上。」 可我現場直接告訴他:「團隊拚了命,應該也無法在本週把進度追上。」 現場我算給他看,清楚的讓他知道為何他的承諾完全忽略了現實。 落後 30% 的業績,實際金額是 600 萬,

By gipi