作者yamagishi (山岸刑務官)
看板Soft_Job
標題Re: [討論] 用AI寫code產生的疑問
時間Sun Apr 2 21:52:12 2023
※ 引述《ripple0129 (perry tsai)》之銘言：
: 事實上未來沒有寫code這種東西
: 我們會在當下才會認為應該是這樣
: 而未來根本沒有所謂的寫code
: 而是跟AI說你要解決什麼問題
: 它就幫你解決這樣
: 當然那個還很久
: 現階段的疑問是AI可以寫code
: 只要幫它code review即可
: 也就是未來沒有初階工程師了
: 你要code review沒有經驗是在review啥
: 換句話說每個公司都會cost down的狀況下
: 初階工程師陣亡一堆
: 而我們最後一批寫程式的人
: 就跟瀕臨絕種動物一樣
: 在還沒有達到最上面說的那個階段前
: 是我們最後存在的價值
: 當然達到那個階段我們也沒價值了
: 已經進入這個行業有資歷的不用擔心失業
: 反而剛要來這個行業的人需要擔心
: 因為連code review都做不到
: 根本無法有效利用當下的AI做產出
回覆應該會變得很長所以特地開一篇。
在專案規模越變越大的時候怎麼去處理祖傳代碼？
從人類既存的軟體史來說這些祖傳代碼幾乎沒有修好的可能性，從這個方向由AI做出發點來討論。
專案本身的複雜度正比於 BUG 的發生率，而 BUG 的發生通常是錯誤的抽象造成的結果。
所以AI可以處理嗎？不行，因為是人類在提需求時就已經有問題了。
再回到複雜度的討論上。
每一種資料結構與其時間、空間的 big O都有其優缺點，這是一種取捨，不可能僅有一種最優解。
那AI生成確定真的是生成你需要的東西嗎？我是不是有修改的需求？
我有修改的需求就表示我需要讀懂AI寫的代碼，那我就需要可讀性，也許你會說既然都用AI生成的話為什麼不用機器語言就好了。
1. 可讀性的本質是易修改，這代表只要較少的資訊就可以實現改變，這是一個迭代效率的問題。
2. 我要求處理時間要在多久以內完成的方式讓AI重新生成代碼，這方式最終還是會回到上述的迭代效率的問題上。
我會在原文的回覆是在說有一群人的觀點是「神打個響指就能解決人類一直解決不了的問題。至於怎麼解決的，我沒有能力關心，因為他是神。」
神替換成AI完全沒問題
-----
Sent from JPTT on my Asus ASUS_I01WD.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.155.48 (臺灣)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1680443534.A.A1C.html
1F：推 ripple0129: 設計的問題產生在於prompt的需求不夠明確，與其說產 04/02 22:06
2F：→ ripple0129: 出來還要去修改，應該在prompt階段就可以去處理了。 04/02 22:06
3F：→ ripple0129: 這一切當然是在現階段還需要去處理的狀況，當運算成 04/02 22:06
4F：→ ripple0129: 本低到一個極致，或是儲存成本低到一個極致，這就沒 04/02 22:06
5F：→ ripple0129: 什麼好處理了。 04/02 22:06
6F：→ ripple0129: 當運算達到極致時根本會沒有祖傳代碼的問題，每一次 04/02 22:08
7F：→ ripple0129: 的運作都像是一次完整的重構一般，這一切都問題根源 04/02 22:08
8F：→ ripple0129: 都還是目前的想像基於運算有限儲存有限 04/02 22:08
9F：→ Firstshadow: Prompt需求不明確,結果是使用者的需求不明確== 04/02 22:14
10F：推 art1: 對我來說 AI 最有用的地方是可以把需求說得很模糊耶 XD 04/02 22:16
11F：推 viper9709: 神說有光就有光(誤) 04/02 22:52
12F：→ yamagishi: 再快也克服不了物理世界的基本規律。 04/02 22:56
13F：→ yamagishi: 今天的業務邏輯是一個 O 的時候，人或機器處理，無非在 04/02 22:56
14F：→ yamagishi: n 很小的時候才有區別。 04/02 22:56
15F：→ yamagishi: 只有找到更低複雜度的近似算法之後才能談AI代替人做。 04/02 22:56
16F：→ yamagishi: 資訊複雜度放在那裡，不是提高算力就能在常數時間解決 04/02 22:56
17F：→ yamagishi: 。 04/02 22:56
18F：推 Suleika: 很務實的觀點 04/05 11:54