PTT職涯區 / Soft_Job (軟體人)

Re: [請益] 軟體失業是遲早的事吧

看板Soft_Job (軟體人)作者 (凱子爸)時間3周前 (2025/08/26 19:43), 3周前編輯推噓41(42推 1噓 114→)
留言157則, 36人參與, 2周前最新討論串2/5 (看更多)
※ 引述《bxc (機率遊戲)》之銘言： : 如題 軟體失業是遲早的事吧 : ㄧ堆都在流行vibe coding : 最近都在玩這個 : 原本的技能樹不是前後端 有點概念而已 : 要弄個sample真的很快 : https://i.imgur.com/wVeBdCK.jpeg
先來定義什麼是vibe coding Karpathy described it as "fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists". "完全沉浸在氛圍中，擁抱指數級成長，甚至忘記程式碼的存在" Wiki中的描述為: Unlike traditional AI-assisted coding or pair programming, the human developer avoids micromanaging the code, accepts AI-suggested completions liberally, and focuses more on iterative experimentation than code correctness or structure. 我自己透過七天的實驗，分享一下個人的心得。 # 注重迭代而非規格 我不贊同AI開發時所謂"規格"驅動開發，也就是先寫完整套規格，再請AI開發的模式 理由主要有兩個： 1. AI內部的接力機制，假如一個AI 99%正確，迭代22次後會變成80% 2. 即使AI能夠連續工作N小時最後完成整套規格，但若是涉及UI/UX相關的，會有許多 需要手動測試的地方 所以我認為Wiki對Vibe Coding的"重視迭代實驗"的敘述，是比較符合現實場景的。 # 個人方法 1. 要求AI建立單元與整合測試，UI/UX方面的手動測試則由我負責 2. 針對epic任務，讓AI自行建立文件紀錄說明與更新進度 3. 以我不親自更改程式碼為首要原則 4. 每次任務結束時都需要確保測試完全通過，並且通過我手動測試功能 5. 每一個階段都要進行lint與移除程式碼中的legacy code # 歷程 雖然說一開始體驗確實是不錯，但我認為當產品迭代到某個階段時，會開始產生痛點 一般迭代的流程如下： POC -> 逐步增加feature -> MVP -> feature的增減與規格變更 -> 實作 POC到MVP這段，是目前AI的強項，特別是POC；沙士比亞後再無新故事，軟體開發方 面其實99%的人都在做重複的事，只是不同的數據、不同的組合而已 所以AI對我來說，能夠非常快看到可以操作的POC，並且快速迭代到MVP 但在MVP後，軟體需要進入打磨與增減的階段，這時AI的問題就特別明顯 1. AI在每個Task結束後對他來說又是新的開始，所以之前的細節他不一定會記得 這導致AI的產出經常缺乏一致性，或是AI的注意力放在新功能的實現而忘記codebase 可能存在相應的模組可以承擔部分職責，解決方法： a. 新增記憶 (但記憶過多無效) b. 你必須主動提示AI必須參考哪些module或文件 2. AI會把達成任務放在首要需求，意味著AI會不擇手段並選擇阻力最小的途徑來 完成你的指示。這導致許多class過於臃腫，或function承擔了他原本不應該承 擔的職責，甚至是不停累積的legacy程式碼。而這些legacy的程式碼又會成為干 擾AI上下文的主因之一。 解決方法： a. 指定AI建立特定的class並說明其職責 b. 在指示階段直接指導重構的方法 3. 靜默錯誤。 AI會為了確保程式碼能夠"成功"執行而非"正確"執行，經常會過度 地使用預設值、hardcode的數值作為回傳值，這導致一些層層包裝的模組在傳遞 數值時又會過度累積大量的hardcode數值，使得底層模組出現真正異常時往往無 法察覺 講到這裡，大家應該會發現，這些問題與問題的解決方法，都涉及程式碼的結構與正 確性。那若是放任這些問題不管，是否可行？也就是說「如果我們完全忘記程式碼」 這些問題是否可忽略，或是說程式碼根本一點都不重要 很多公司的程式碼也是爛到爆，說白了AI寫的程式碼可能還是某些公司的上限，那這 些公司還不是錢照賺、功能照加？但我沒有這個勇氣嘗試，因為token的帳是算在我身 上 我看到網路上有些文章，確實會將設計模式、程式碼的設計準則一併加入prompt中，但 這仍然是一種關注程式碼結構與正確性的行為之一。所以，vibe coding目前「忘記程式 碼的存在」、「不用再管程式碼的結構與正確性」這樣的體驗至少我自己還無法感受到 有些公司codebase爛，可是講的是一個產業know how、講的是一個本多忠勝，反正bug 硬幹、產品能跑就好，有潔癖的工程師要走請便，反正多的是其他工程師。 現在這些公司確實是有可能用轉蛋的方式砸token砸出一個可以run又不會被用戶弄出bug 賠錢的產品 (反正價格錯誤再反過來告消費者就好) 軟體開發就跟AV女優一樣，像我就覺得臉蛋漂亮很重要，奶小沒關係，像希島愛里這樣 有人就覺得奶大很重要、假奶沒關係，但一定要奶大，像楪可憐這樣 也有人堅持一定要真奶、不要人造人，這種人去看楪可憐就只會看到楪可憐的缺點 祝大家在喜歡的女優引退後都能找到自己喜歡的新人女優 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 146.70.205.94 (日本) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1756208616.A.A0E.html
推
08/26 19:50, 3周前 , 1F
最屌的還是看到開始有人做出了 H 奶 30kg，一邊單眼皮一
08/26 19:50, 1F
→
08/26 19:50, 3周前 , 2F
邊雙眼皮，然後說因為看習慣 30cm，所以也要加上 30cm，
08/26 19:50, 2F
→
08/26 19:50, 3周前 , 3F
變成一個每個細節都很屌，但整體不知道到底在幹嘛
08/26 19:50, 3F
推
08/26 20:16, 3周前 , 4F
前面一堆叫罵聲勢浩大
08/26 20:16, 4F
→
08/26 20:16, 3周前 , 5F
認真討論的文卻乏人問津
08/26 20:16, 5F
→
08/26 20:20, 3周前 , 6F
好啦話說回來，我同意這篇文的部分觀點
08/26 20:20, 6F
→
08/26 20:20, 3周前 , 7F
會出現很多冗餘的參數跟沒必要的流程
08/26 20:20, 7F
→
08/26 21:46, 3周前 , 8F
完全不管code太理想 但不追求什麼良好設計這種方法倒是
08/26 21:46, 8F
→
08/26 21:46, 3周前 , 9F
堪用了
08/26 21:46, 9F
→
08/26 22:29, 3周前 , 10F
我自己也認為「AI要好維護前提是人也好維護」
08/26 22:29, 10F
→
08/26 22:30, 3周前 , 11F
畢竟正如大家的觀察 Context大小就是很現實的技術極限
08/26 22:30, 11F
推
08/26 22:54, 3周前 , 12F
結論很讚
08/26 22:54, 12F
推
08/27 01:00, 3周前 , 13F
設計差 效能爛 實務上的確不是最重要的，能符合需求的產
08/27 01:00, 13F
→
08/27 01:00, 3周前 , 14F
出才是真正有價值的地方
08/27 01:00, 14F
效能的好壞在實務上是不是最重要的，這點我認為因場景還有階段而異。 我自己是做桌面應用程式+3D軟體出身的，你光是一個button按下去卡頓QA就要來靠北了 這個道理也同樣適用於後端，最後到商業上效能一樣是用戶體驗與成本的處方
推
08/27 01:14, 3周前 , 15F
看起來不如自己寫比較快...
08/27 01:14, 15F
我自己寫是不可能那麼快的，方方面面都是。 就算把AI犯的錯誤與修正指示、AI修改的時間算進去，還是遠比我一個人開發快。 你要當成你在帶好幾個有時會懶惰會犯錯的junior。 包含我自己與許多在網路上看到的感想，共同心得都是AI開發的瓶頸現在其實是在 人的量能不夠。我一天要測試、review的量，其實資訊量是遠比傳統開發高的。 我Max 5x時段內額度用盡，我通常也很疲勞了。 當然素人現在vibe coding很爽，是因為他們也看不出(或是說不在乎也不知道有哪 些問題)，加上他們的專案規模都小或說規格都很常見，所以不會發生問題，過程當 然也很輕鬆愉悅
推
08/27 01:32, 3周前 , 16F
剛剛試了vibe coding，連最簡單的outlook 2007 pop3
08/27 01:32, 16F
→
08/27 01:33, 3周前 , 17F
同步刪掉Gmail的信件都在胡說八道，
08/27 01:33, 17F
→
08/27 01:33, 3周前 , 18F
浪費我的時間，這是怎麼vibe coding啦
08/27 01:33, 18F
→
08/27 01:35, 3周前 , 19F
話說有人懂嗎？我Gmail已經爆了,現在來跟你們vibe coding
08/27 01:35, 19F
→
08/27 01:35, 3周前 , 20F
可能比較靠譜
08/27 01:35, 20F
推
08/27 01:37, 3周前 , 21F
感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞
08/27 01:37, 21F
※ 編輯: SkankHunt42 (146.70.205.188 日本), 08/27/2025 02:07:40
→
08/27 02:28, 3周前 , 22F
蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin
08/27 02:28, 22F
→
08/27 02:30, 3周前 , 23F
終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性
08/27 02:30, 23F
→
08/27 02:31, 3周前 , 24F
不過有人說要換個想法 對於每次功能的變動 乾脆直接重新
08/27 02:31, 24F
→
08/27 02:33, 3周前 , 25F
全部重頭產生程式碼 這也不大合理 最多只能部分codebase
08/27 02:33, 25F
→
08/27 02:34, 3周前 , 26F
讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一
08/27 02:34, 26F
→
08/27 02:35, 3周前 , 27F
點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得
08/27 02:35, 27F
→
08/27 02:36, 3周前 , 28F
vibe coding只能用在小型專案上面 我現在也只是拿來產生
08/27 02:36, 28F
→
08/27 02:37, 3周前 , 29F
script跟很簡單的工作上的資料pipeline
08/27 02:37, 29F
推
08/27 02:56, 3周前 , 30F
vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看
08/27 02:56, 30F
→
08/27 02:56, 3周前 , 31F
code很正常R 你給他再5年試試看
08/27 02:56, 31F
→
08/27 02:57, 3周前 , 32F
中大型專案隨著context window越來越大 遲早能整個吞下去
08/27 02:57, 32F
我不對還沒發生的改變做評論。 就跟Steam玩家不會因為你DLC、免費更新大餅畫得很飽滿就給你為了財報數字趕工上 架的半成品好評一樣。 我拋磚引玉期望的是大神跳上來打臉我說： 「你根本不會用AI，用下面幾個流程與方法我能達到完全不看程式碼又穩健的開發」 這種交流才是對開發社群有助益的實質討論。
推
08/27 05:32, 3周前 , 33F
Llm目前就是當外部顧問 臨時工用 他沒辦法了解專案或
08/27 05:32, 33F
→
08/27 05:32, 3周前 , 34F
團隊文化等等隱性知識 就像請一個外部技術專家來 也不
08/27 05:32, 34F
→
08/27 05:32, 3周前 , 35F
可能三言兩語就上手完成任務 所以別期待AI可以幫你完
08/27 05:32, 35F
還有 82 則推文
還有 8 段內文
→
08/27 16:35, 3周前 , 118F
我們照著開發就會有進展
08/27 16:35, 118F
→
08/27 16:36, 3周前 , 119F
就算你去讀了論文告訴你 OO 機制有什麼效果 你也無法預期
08/27 16:36, 119F
→
08/27 16:36, 3周前 , 120F
引入那個機制對你的模型表現能提升多少 甚至未必是提升
08/27 16:36, 120F
→
08/27 16:38, 3周前 , 121F
當模型產出你不要的結果, 你沒辦法印出熱力圖然後就說
08/27 16:38, 121F
→
08/27 16:38, 3周前 , 122F
啊, 這就是因為怎樣怎樣 所以我們只要這樣改就可以解決
08/27 16:38, 122F
→
08/27 16:39, 3周前 , 123F
不 沒有辦法 所以才需要每年燒數十億美金但你不知道
08/27 16:39, 123F
→
08/27 16:40, 3周前 , 124F
我們會不會有造出AGI的一天 你只能相信再給他幾年他會
08/27 16:40, 124F
→
08/27 16:40, 3周前 , 125F
更好
08/27 16:40, 125F
→
08/27 19:38, 3周前 , 126F
要完全符合vibe那肯定沒辦法，現在搞的東西就是context
08/27 19:38, 126F
→
08/27 19:39, 3周前 , 127F
window太小，要用程式去另外解決，可以參考:
08/27 19:39, 127F
→
08/27 19:41, 3周前 , 128F
www.anthropic.com/engineering/multi-agent-research-sy
08/27 19:41, 128F
→
08/27 19:42, 3周前 , 129F
stem，可以參考
08/27 19:42, 129F
推
08/27 19:45, 3周前 , 130F
anthropic的做法，說實話也不是給小白去vibe
08/27 19:45, 130F
推
08/27 20:22, 3周前 , 131F
可以理解現在的業主會想移除軟體建置成本
08/27 20:22, 131F
→
08/27 20:22, 3周前 , 132F
讓AI自動生成，聽起來快又有效
08/27 20:22, 132F
→
08/27 20:22, 3周前 , 133F
但是就是那個但是
08/27 20:22, 133F
→
08/27 20:22, 3周前 , 134F
沒有程式背景的人根本分不出來AI唬爛
08/27 20:22, 134F
→
08/27 20:22, 3周前 , 135F
所以.....就這樣
08/27 20:22, 135F
→
08/27 20:24, 3周前 , 136F
而到時候軟體工程師早就進化成另類馴獸師
08/27 20:24, 136F
→
08/27 20:24, 3周前 , 137F
變成只會有更多的馴獸師要養
08/27 20:24, 137F
推
08/27 20:51, 3周前 , 138F
對我來說就是可以專注在邏輯和結構，末梢程式碼可以快
08/27 20:51, 138F
→
08/27 20:51, 3周前 , 139F
速tab解
08/27 20:51, 139F
推
08/28 00:56, 3周前 , 140F
推jej
08/28 00:56, 140F
推
08/28 06:12, 3周前 , 141F
推
08/28 06:12, 141F
推
08/28 09:12, 3周前 , 142F
推
08/28 09:12, 142F
噓
08/28 09:34, 3周前 , 143F
前面都蠻正常的 最後一段的比喻很噁
08/28 09:34, 143F
推
08/28 10:28, 3周前 , 144F
最大的問題是記憶力 過了幾個問題就會忘了前面一些細節
08/28 10:28, 144F
→
08/28 10:28, 3周前 , 145F
偏偏細節錯人要花更多時間找出來
08/28 10:28, 145F
→
08/28 10:29, 3周前 , 146F
當工具用可以 當夥伴用你會累死
08/28 10:29, 146F
推
08/28 11:11, 2周前 , 147F
還好我同事的記憶力比AI還差
08/28 11:11, 147F
→
08/28 13:18, 2周前 , 148F
你講那麼多，那些外行一樣看熱鬧啦
08/28 13:18, 148F
推
08/28 17:10, 2周前 , 149F
跟我使用github copilot的感想一致，推
08/28 17:10, 149F
推
08/28 17:44, 2周前 , 150F
推。
08/28 17:44, 150F
推
08/28 18:16, 2周前 , 151F
最後一段很到位了
08/28 18:16, 151F
推
08/28 19:06, 2周前 , 152F
問題不是context window大小，而是context大了會有回彈
08/28 19:06, 152F
推
08/28 21:37, 2周前 , 153F
推
08/28 21:37, 153F
→
08/29 05:19, 2周前 , 154F
拆分小小的 一步一步慢慢完成
08/29 05:19, 154F
推
08/29 12:43, 2周前 , 155F
ai 生成不確定可以多問幾個比較 甚至把回答貼給另一
08/29 12:43, 155F
→
08/29 12:43, 2周前 , 156F
個問
08/29 12:43, 156F
推
08/30 11:06, 2周前 , 157F
哇 這篇含金量真不錯
08/30 11:06, 157F
‣ 更多 SkankHunt42 的文章
文章代碼(AID): #1ehPteeE (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 SkankHunt42 的文章
文章代碼(AID): #1ehPteeE (Soft_Job)