Re: [請益] 軟體失業是遲早的事吧
※ 引述《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女優一樣,像我就覺得臉蛋漂亮很重要,奶小沒關係,像希島愛里這樣
有人就覺得奶大很重要、假奶沒關係,但一定要奶大,像楪可憐這樣
也有人堅持一定要真奶、不要人造人,這種人去看楪可憐就只會看到楪可憐的缺點
祝大家在喜歡的女優引退後都能找到自己喜歡的新人女優
--
最屌的還是看到開始有人做出了 H 奶 30kg,一邊單眼皮一
邊雙眼皮,然後說因為看習慣 30cm,所以也要加上 30cm,
變成一個每個細節都很屌,但整體不知道到底在幹嘛
前面一堆叫罵聲勢浩大
認真討論的文卻乏人問津
好啦話說回來,我同意這篇文的部分觀點
會出現很多冗餘的參數跟沒必要的流程
完全不管code太理想 但不追求什麼良好設計這種方法倒是
堪用了
我自己也認為「AI要好維護前提是人也好維護」
畢竟正如大家的觀察 Context大小就是很現實的技術極限
結論很讚
設計差 效能爛 實務上的確不是最重要的,能符合需求的產
出才是真正有價值的地方
效能的好壞在實務上是不是最重要的,這點我認為因場景還有階段而異。 我自己是做桌面應用程式+3D軟體出身的,你光是一個button按下去卡頓QA就要來靠北了 這個道理也同樣適用於後端,最後到商業上效能一樣是用戶體驗與成本的處方
看起來不如自己寫比較快...
我自己寫是不可能那麼快的,方方面面都是。 就算把AI犯的錯誤與修正指示、AI修改的時間算進去,還是遠比我一個人開發快。 你要當成你在帶好幾個有時會懶惰會犯錯的junior。 包含我自己與許多在網路上看到的感想,共同心得都是AI開發的瓶頸現在其實是在 人的量能不夠。我一天要測試、review的量,其實資訊量是遠比傳統開發高的。 我Max 5x時段內額度用盡,我通常也很疲勞了。 當然素人現在vibe coding很爽,是因為他們也看不出(或是說不在乎也不知道有哪 些問題),加上他們的專案規模都小或說規格都很常見,所以不會發生問題,過程當 然也很輕鬆愉悅
剛剛試了vibe coding,連最簡單的outlook 2007 pop3
同步刪掉Gmail的信件都在胡說八道,
浪費我的時間,這是怎麼vibe coding啦
話說有人懂嗎?我Gmail已經爆了,現在來跟你們vibe coding
可能比較靠譜
感覺vibe coding這詞跟敏捷這詞一樣是個唬爛的同意詞
蠻贊同這篇的過程跟感想的 對於有生命期的產品vibe codin
終究會帶來不可承受的負擔 更別說要規格業務邏輯的一致性
不過有人說要換個想法 對於每次功能的變動 乾脆直接重新
全部重頭產生程式碼 這也不大合理 最多只能部分codebase
讓AI完全重新產生碼出來 但是就我的實際經驗連個稍微長一
點的演算法或是處理程序 都沒辦法一次'功能'到位 覺得
vibe coding只能用在小型專案上面 我現在也只是拿來產生
script跟很簡單的工作上的資料pipeline
vibe coding這詞也才出來半年多 當然現主時沒辦法完全不看
code很正常R 你給他再5年試試看
中大型專案隨著context window越來越大 遲早能整個吞下去
我不對還沒發生的改變做評論。 就跟Steam玩家不會因為你DLC、免費更新大餅畫得很飽滿就給你為了財報數字趕工上 架的半成品好評一樣。 我拋磚引玉期望的是大神跳上來打臉我說: 「你根本不會用AI,用下面幾個流程與方法我能達到完全不看程式碼又穩健的開發」 這種交流才是對開發社群有助益的實質討論。
Llm目前就是當外部顧問 臨時工用 他沒辦法了解專案或
團隊文化等等隱性知識 就像請一個外部技術專家來 也不
可能三言兩語就上手完成任務 所以別期待AI可以幫你完
成一切
理想情況是在請他做事時一邊建立文件 建立測試 把隱形
知識轉成顯性 但這就像帶新人一樣 短期沒回報 長期也
不一定利己 最後說不定是讓自己失業
他寫文件跟測試是真的很方便。我現在連commit message都懶得自己寫。
多少還是需要祖傳md
我的觀察,claude偶爾會做太high忘記CLAUDE.md的規則。
※ 編輯: SkankHunt42 (146.70.205.92 日本), 08/27/2025 10:45:26推!很贊同這篇的過程和想法 最近剛好也一直在玩這塊
目前在想透過micro service+DDD開發手法,每個領域都用
repository切開,減少AI每次需要學習和需要記憶的量
目前是每個repository底下都放一個md在試試看~
請問大大是用claude還是gemini啊?
YT搜尋Claude就好,已經開始有一堆人講解怎麼用。我用起
來效率乘十倍不誇張
十倍 哈哈哈 你三天就做完以前一個月的專案進度了嗎
還是寫扣的速度快了十倍但寫扣只佔工作的一小部分 其實
整體產出根本也沒提升多少 同時每天大量review AI的產出
還消耗了不少腦力導致整體產出倒退
十倍是扯了點 那丟給你五人份的工作你應該非常輕鬆
還可以偷懶囉?
已經很多人發現使用AI反而造成整體產出下降 你越仰賴 vib
e coding 你對專案程式碼的熟悉度就會越來越低 甚至你不
會記得最近三天新加入的函數有哪些 你會感覺有個公用函
數好像之前才寫過但你不確定放在哪個檔案 你跟AI一樣有
失憶現象最後造成專案裡類似功能的函數到處都是
我沒有做量化分析,加上樣本數只有我自己,所以我也無意討論到底是幾倍,這都是 體感問題。 我原文的焦點其實只有一個問題「在
現階段是否可以
完全忽略程式碼進行開發」 如果你本身是一個經驗豐富的工程師,當然可以透過各種工作流與指令的設計、對 codebase的理解加以推進這個過程。但我認為這並不符合宣傳中所謂「理想中的vibe coding」的模式
cursor+gpt5+大量project rules+FP應該算是目前vibe codi
ng的最頂級combo,便宜好用又不會亂寫
Claude現在還可以幫你執行命令,看build error,下gdb,
callstack直接看,log印成檔案後直接看檔案,確實不太需
要review AI產生的代碼了。真要review再新開一個task叫A
I review
要預防失憶現象,要寫MD檔,甚至AI改完code後可以叫他改
寫MD檔兩邊align
直接改檔案直接跑,你只要按確認就好,連複製貼上都不用
你說的似乎沒有超出我的認知。
推實驗精神
「類似功能的函數到處都是」 這是一個很大的問題嗎?如
果不影響專案進行,這問題根本沒差。利大於弊,除非嵌入
式斤斤計較空間,但嵌入式通常repo不會很大,AI更容易處
理
可以在研究一下context engineering,啟用一個agent去審
有模板貨文檔,也不會有風格偏差太大的問題
你跟yamakazi說的方法其實我都試過,甚至寫在內文。 這原則上就是指定AI去閱讀某份module或文件,不管是全自動還是手動命令的形式。 AI自動循環更新文件→改程式→更新文件的模式我當也試過。 這種方法在一定規模內有用,但一旦內容太多對AI就會變成一種干擾。 當然如果你token額度很大可以整個context都塞進去也沒問題。
要寫README.md,寫了就不太會失憶了
其實你這樣的需求也不明確 也沒定義清楚 雖然說中大型 要
多大才叫中大型? 現在小型專案確實已經可以完全不看程式
碼完成整個產品 但小型是多小型?會不會過陣子 其實已經可
十倍當然不誇張啊,原本一小時才能解完的bug,五分鐘AI
就解完了?那不就十倍?
以做到完全不看程式碼開發一整個電商系統 但又會抱怨電商
根本就中小型專案 難道AI能讓我Vibe Coding出google搜尋引
擎或整個臉書嗎?我覺得喇 怎麼樣都可以打臉的理由 沒有討
論的價值
等到哪天真的能vibe出一個搜尋引擎 又會說 啊是能讓我vibe
出一個ChatGPT嗎?如果不定義標準 AI永遠不可能滿足
AI都拿了諾貝爾化學獎和數奧金牌了,寫程式真的小菜一碟
專案的性質也差很多 vibe一個部落格 跟vibe一個3D遊戲引擎
或跟vibe一個給客戶用的SDK 是完全不一樣的事 每一種類型
也都可大可小 不定義清楚很難說vibe沒什麼用
歡迎你根據自己的定義、使用經驗與觀察與回文。 我可以補充一些我專案的數據: 程式碼行數不含CSS一共有21000行,其中8700行是test。 commit數量110個。 專案是DSL專用的WYSIWYG風格的編輯器。 而對vibe的定義我在開頭也引述了Wiki的寫法。
實際上我就親身遇過業主沒有任何背景程式 vibe出一個演算
法系統來幫忙處理公司內數據 他一行程式碼都看不懂 程式碼
也沒給任何工程師審查過 就他自己做的工具 但運作非常好
看不懂沒差啦,llm的開發人員也說過他們也看不懂現在llm
的程式碼了
整個系統大概一萬多行 這算大 還是小
AI開發者自己對AI模型都無法掌握了,看不懂正常
不可解釋性以及深度學習領域很多新方法難以解釋,這跟你
做資訊系統但不懂其中的程式碼那是完全兩回事
vibe coding 在你只需要一個蛋糕的時候沒有任何問題,他
是一個蛋糕而且還不錯,當你的客戶說我的蛋糕這邊那邊一
定要如何如何的時候,就開始有問題了
其實我看不懂你的蛋糕比喻XD
「這邊一定要如何如何」這對AI來說很難嗎?
很難,因為你沒辦法在不提供明確指令的情況下讓AI滿足你
,而你如果明確的給出所有需求,那你只是在換個語言codin
g
www
程式的確就是對於現實的事物或概念進行描述 要越細緻 就要
描述的越仔細 自然語言本身是很模糊的 要細節那自然語言也
要跟著寫到很細 那還是在寫程式 只是程式語言變成英文?
就像關鍵字 let 一樣。就是個很英文式的程式語法
foreach a in group 這個演化也很英文
AI開發者都對AI無法掌握喔@@
給樓上, 模型研發並不像資訊系統, 你把需求跟規格列出來
我們照著開發就會有進展
就算你去讀了論文告訴你 OO 機制有什麼效果 你也無法預期
引入那個機制對你的模型表現能提升多少 甚至未必是提升
當模型產出你不要的結果, 你沒辦法印出熱力圖然後就說
啊, 這就是因為怎樣怎樣 所以我們只要這樣改就可以解決
不 沒有辦法 所以才需要每年燒數十億美金但你不知道
我們會不會有造出AGI的一天 你只能相信再給他幾年他會
更好
要完全符合vibe那肯定沒辦法,現在搞的東西就是context
window太小,要用程式去另外解決,可以參考:
www.anthropic.com/engineering/multi-agent-research-sy
stem,可以參考
anthropic的做法,說實話也不是給小白去vibe
可以理解現在的業主會想移除軟體建置成本
讓AI自動生成,聽起來快又有效
但是就是那個但是
沒有程式背景的人根本分不出來AI唬爛
所以.....就這樣
而到時候軟體工程師早就進化成另類馴獸師
變成只會有更多的馴獸師要養
對我來說就是可以專注在邏輯和結構,末梢程式碼可以快
速tab解
推jej
推
推
前面都蠻正常的 最後一段的比喻很噁
最大的問題是記憶力 過了幾個問題就會忘了前面一些細節
偏偏細節錯人要花更多時間找出來
當工具用可以 當夥伴用你會累死
還好我同事的記憶力比AI還差
你講那麼多,那些外行一樣看熱鬧啦
跟我使用github copilot的感想一致,推
推。
最後一段很到位了
問題不是context window大小,而是context大了會有回彈
推
拆分小小的 一步一步慢慢完成
ai 生成不確定可以多問幾個比較 甚至把回答貼給另一
個問
26
首Po如題 軟體失業是遲早的事吧 ㄧ堆都在流行vibe coding 最近都在玩這個 原本的技能樹不是前後端 有點概念而已 要弄個sample真的很快![[請益] 軟體失業是遲早的事吧 [請益] 軟體失業是遲早的事吧](https://i.imgur.com/wVeBdCKb.jpeg)
15
Vibe Coding可以讓不懂Coding的人 就可以做一個prototype 這在過往就是你要找軟體工程師來實現的需求 現在這個需求就沒了 直白點軟體工程師的崗位又少了7
這個問題已經有很多先賢回答過了 我就不做重複功 截取一篇正經 一篇不正經的分享一下![Re: [請益] 軟體失業是遲早的事吧 Re: [請益] 軟體失業是遲早的事吧](https://i.imgur.com/Q6SgMdpb.jpeg)
X
專業的來嘴砲一下 剛剛和一個學弟聊 別說工程師了 經理人商業策略都有可能被取代了 只能說當初說工程師經理人不會被取代的26
昨天看到的 大概是,非本職的人,用了AI之後出包 下面的留言討論,滿精彩的 --![Re: [請益] 軟體失業是遲早的事吧 Re: [請益] 軟體失業是遲早的事吧](https://i.imgur.com/j95HHWib.jpeg)
6
保哥三個月就神準預言了 他說半桶水的就會搞出這種 可以直接看YT 從46:10開始 只能說Will保哥才是真正的講師 業界良心![Re: [請益] 軟體失業是遲早的事吧 Re: [請益] 軟體失業是遲早的事吧](https://img.youtube.com/vi/Ji3mg3HwiE4/mqdefault.jpg)
28
我有一個同事就是在弄演算法的 他就曾經有一次經驗,就是叫AI去產生一個常見的演算法 結果他直接拿來用之後,發覺結果非常的發散。 正常來說,應該是要收斂才對,他後來跳進去仔細檢查之後,才發現 是其中一個負號變成了正號。9
抱歉,但你這做法有改進空間 如果是做演算法,優先用python 寫 現在主流AI寫python幾乎不可能錯 寫完後叫AI自己生一些測資再畫圖給你看 圖看完沒問題後再叫他改寫成C++7
一個AI有這麼多不同的體悟 我覺得問題是出在於,很多人在下Prompt的時候說得太籠統了 AI很容易掰出一個錯的東西給你 幻覺議題可以參考OpenAI自己寫的這篇文章3
我覺得就跟早年的司機一樣吧。 就是一開始汽車很少,有駕照的人也不多,會開車的人或者說司機的價值就很高 隨著汽車的普及,司機的價值和薪水就變低了 但是司機職業的從業人數卻變多了 同時也出現了F1車手等等的另類的高價值車手
91
Re: [討論] 對岸的軟體工程師分享一下現在中國公司工作的狀況好了, 程式碼 build 都沒過,是絕對不能回家的,你會害很多人被扣錢。 首先程式碼 commit到分支前,都要設定好jenkins 使用 git push 程式碼到 repository 的分支時, 會觸發CICD流程,大致會執行以下流程:48
[爆卦] AI開始發表學術論文Sakana AI公司開發了第一個用於自動化科學研究和開放式發現的綜合AI The AI Scientist 該AI提出想法、檢查創新性、設計實驗、編寫程式碼,到在GPU上執行實驗並收集結果![[爆卦] AI開始發表學術論文 [爆卦] AI開始發表學術論文](https://sakana.ai/assets/home/sakana_rect.png)
32
Re: [討論] 系統越開發越多,負責的東西越來越多推 yangs0618: 推個 希望有機會聽到進一步分享how 10/28 07:58 → yangs0618: On提出數據說服主管/管理層 開發是越來越耗時間 10/28 07:59 → panbanana: 要怎麼跟上頭說開發越來越久跟code quality有關 10/28 08:18 幾個很簡單的學術名詞就能說明,我相信大家也知道 耦合性 如果我改A模組,B模組就需要跟著改 (這還是B模組沒有牽連其他模組的情況下)![Re: [討論] 系統越開發越多,負責的東西越來越多 Re: [討論] 系統越開發越多,負責的東西越來越多](https://i.imgur.com/1VlaBnpb.png)
24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。17
[討論] 微軟用Copilot Workspace重新定義程式開發微軟旗下的AI程式設計幫手 GitHub Copilot WorkSpace上架了 這款程式開發環境能讓外行人也可以用自然語言將想像轉化成實際程式 微軟老闆Satya Nadella:"我們正在使用 GitHub Copilot Workspace 重新定義開發人員環 境(IDE),任何開發人員都可以使用自然語言從想法、程式碼到軟體。"![[討論] 微軟用Copilot Workspace重新定義程式開發 [討論] 微軟用Copilot Workspace重新定義程式開發](https://githubnext.com/assets/images/og/project/copilot-workspace.png)
4
Re: [請益] 面試如果考coding可以這樣回答嗎?台灣軟體產業的問題從來都不是這些 學程式是越來越簡單,工具越來越多、教學資源越來越多 講白了這些語法、資料結構、演算法都只是基礎問題,甚至台灣87%的軟體工程師都 都不會在實務場景中遇到排序問題,就算會也不會要你手刻 實務的場景是都在搞那些所謂「程式能跑就可以」、「因為趕所以我就隨便寫」、3
[問卦] Vibe Coding是三小女口是頁 矽谷怎麼又多了一個 buzzword 簡單來說就是 Code 都 AI產 Programmer 只要下指令就好 連程式碼都不用懂![[問卦] Vibe Coding是三小 [問卦] Vibe Coding是三小](https://i.imgur.com/edDklnNb.gif)
5
[問卦] vibe coding的程式拿出來賣也太好笑了vibe coding啊 就是出一張嘴 叫AI寫程式 程式碼通常是很亂 你叫AI改東4
Re: [討論] 用AI寫code產生的疑問先講結論,軟體工程師做的事情以及定義從 1946 年 ENIAC 開始就不斷地在改變。 所以接下來改變的還是會是工程師的定義,也許依照人力資源規劃還是會有各種 工程師職階,但是做的事情和現在應該不會一樣。 順帶一提,目前的 GPT 其實還沒辦法完成很多開發工作,所以也許一兩年大家都摸清![Re: [討論] 用AI寫code產生的疑問 Re: [討論] 用AI寫code產生的疑問](https://i.imgur.com/abE2zRMb.jpg)
4
Re: [討論] 用AI寫code產生的疑問AI(GPT)用於Coding的實務心得 作者是虎尾科大資工系陳國益教授,經同意後轉載文字內容,原連結於下: 在上週前往華新麗華授課時,有工程師問到:若有要接手的大型專案,應如何透過AI協助 ,加速對專案的理解速度,或是快速產生手冊、API列表等,傳統上要花非常多時間交互