認知負債以及退化

Created · Updated

目前的觀點:傳統開發的方式已經死了,我們開發者會作為協調者(Orchestrator)去透過 Agent 進行開發。

我們負責優化 Agent 提供的計畫、優化 Loop、提供我們的 Taste 由 Agent 去執行產出,之後由我們去進行 Review。

衍生出了 SDD, Plan Mode 等方式。

為了去驗證及優化 Agent 產生出來的 Code、產品、方向等是否符合預期、安全性是否符合,會有其他的 Agent 去進行 Review 以及進行驗證。

為了讓 Loop 更流暢,我們需要有許多比以往更複雜的週邊系統。

使用 AI Agent 的悖論是他們需要人類進行監督,但使用 Agent 的同時我們也離 Code 越來越遠,以及技能的逐漸喪失。

在協助公司面試的時候,發現越來越多有多年經驗的工程師,目前連語法可能都不太清楚理解,需要協助。不確定是否是這個的原因。

另外額外的問題是 Token 的費用,社群上有許多工程師是擁有無限 Token 可以去使用的,但可能在多數的公司並不是。

所以 Token 的成本會是另外需要考量的點,可能使用更便宜的開源模型之類的?

不過這是另外成本的問題。

也有許多人會說,語法什麼的是不重要的,越來越多開發者會選擇透過 Rust 進行開發,但本身完全不知道 Rust 怎麼寫。

Rust 本身的安全性被認為是最好 Vibe Coding 的工具。人類只需要負責更高層次更宏觀的角度去看待系統,寫好文件就好了。

在以往我也是透過寫程式去進行思考的,將項目拆分,嘗試定義 Component, Type, Function, Hook 等。

覺得有更好的方式然後重新組合定義確認。

我沒有辦法單純的透過文件本身去理解可能會發生到的問題。

但也有可能這是我的問題?

但端看文件,我覺得我就像 Agent 一樣會產生許多的幻覺,想的過於美好或是有許多地方沒有考慮到。

寫程式釐清過程,建立一個個檔案組織,定義 Type 去設計接口(Interface)等,去幫助我對整體需求進行思考。

Learn from pstack 會透過由 Agent 去進行實驗實際的執行 Code 確認可行性,我覺得我就是屬於那種的開發方式,要我維護文件並在一開始就完美的計畫好,我無法做到。

當程式過於抽象成 Markdown 文字時,我對於底層的實作以及思考能力就退化了許多。

當然也回不去在全部手寫 Code 古老的方式去進行開發,工作追求的是效率以及品質。

手寫的 Code 在目前看來是極其沒有效率的表現(?),但不能放棄本身的批判性思考。

我覺得有一點很有趣,對於工程師來說,未從做過或是有趣有挑戰的功能,工程師會很想自己動手實現,而對於千遍一律的東西就會完全懶的去進行(至少我是這樣)。

所以其實可以將無趣的工作交由 Agent 幫我們完成,例如腳本、公司內部(自己)的工具、切好幾次的畫面版型或是手動的驗證,這些都可以交由 Agent 來進行。

將有趣的實作以及方向性的部分自行去確認,或是 Refactor 從中學習以及理解系統的架構。

或許是另外一種解決方式吧。

維持在 AI 時代的批判思考,覺得就是目前許多工程師都需要練習且努力的課題。

另外其實在 AI 這個時代,能學習到的東西比以往來的更多,我也透過 AI 開始嘗試自己之前從未接觸過的領域,並且進行學習,這過程也非常的有趣。

ReferencesLink to this section: References