Why Learn Coding in 2026?
已經來到 2026 年一月的尾聲，現在才在開始展望（？） 2026 可能相對有點晚。
但，眼看著新學期再過不到一個月即將展開，作為弄出了這一堆一堆的教材的人，總感覺要在技術飛速迭代的此刻，講清楚為什麼自己還要做這件事情，以及為什麼我仍然認為大家可以試著學這些東西。
希望這一點隻字片語，可以為坐在書桌前面發愁的人，一點點小小的回應或提醒。
首先，我必須承認這個標題有點釣魚的成分。我只是想用 coding 作為一個引子，讓我有機會去跟可能還不太熟軟體開發的人解釋，為什麼 2026 年仍需要學習軟體工程與開發，仍需要訓練軟體工程腦。
好，正篇開始。
我先說這個寫作風格可能對許多人來說有點陌生... 我平常大概也不會用這種寫法來寫 –– 這樣寫太勸退人了。但畢竟這不是一篇常識上的 tech blog，不是我對一個技術點或工具的探索成果分享，而是對於抽象概念的觀察與思考。所以這次我要換個寫法，就是在最一開始拋出最終極的兩個疑問：
- 軟體工程師的本質是什麼？
- 代理的機制／本質是什麼？
軟體工程師的本質是什麼？
應該還稱不上一個軟體工程師，我認為自己目前是一個「擺弄程式碼的傢伙」。但仍希望我的想法能給對這個環境更不熟悉而有些迷茫的人看看並思考一下，起一個拋磚引玉的作用。
有接觸過開發的人，可能會比較容易對我接下來要說的比較有共鳴，若沒共鳴，也希望你可以對我接下來說的話有點印象，待未來的你驗證我的思路是否大致正確。
就是說，「把程式碼寫出來其實是工程師的最後一步」... 暫且先不考慮維運的話。
為什麼我這麼說呢？因為做軟體這件事情，遠遠不是「做出來」而已。縱使大家... 或者說大多剛好沒碰過開發的人，可能看見的都是最後「做出來」的這一步。因為在這一個環節中，軟體工程師會化身為大家印象中的那種工程師... 坐在書桌前，電腦上顯示著一堆一般用電腦的人一輩子可能都不會見到的畫面，眼睛盯著畫面然後時不時的手指在鍵盤上飛速敲打一陣彷彿在 LINE 上跟人吵架那樣。
縱使今天沒有 AI，手指在鍵盤上從頭飛速敲到尾的軟體工程師應該也是稀有生物喔。因為大家經常會花更多時間在思考、討論、讀程式碼、讀外部文件、檢查輸入輸出是否符合預期，以及比對最後出來的東西有沒有跟架構書吻合。甚至有的人會直接說，如果看到軟體工程師在鍵盤上飛速敲很久，那他不是在工作，而是在跟別人傳訊息。我基本也同意這個觀點，不過我不愛把話說死就是了。
如果再讀一遍前面的兩句話就會發現，光我提到的這些就已經不是「寫程式碼」而已了吧？
所以說，工程師工作＝寫程式碼，這個理解其實相當的不完備。
事實上，工程師花更多力氣在
- 確認需求（討論、確認架構書吻合性）
- 整理架構（思考、讀寫程式碼）
這還已經是進到實作層面的階段了，在那之前，可能要做的是：
- 確認問題
- 分析問題
- 確認需求
- 設計架構
注意到了嗎？「確認需求」跟「架構」這兩件事情我說了兩次。因為我粗淺的認為這其實才是軟體工程師的主軸，他們分別意味著什麼？我想是「與真實問題的對應」以及「高效的處理」這兩件事情。
寫程式碼... 其實就是把處理方案實現出來而已。可貴的不是這堆程式碼，而是在背後投入的，對問題的分析以及作出多創意、多高效的解決方案。
若用教學者們常常說的釣魚比喻，那就是最可貴的不是在於把上鉤的魚從水裡拉出來這件事情。而是
- 經過精心的 設計與調查，發現了一處資源豐盛而且釣客不多的河流
- 看準了這條河流中魚的特性，挑選了適合的鉤以及餌
- 透過訓練，可以很高效的甩竿投餌、迅速拉起目標
大家最終關注到的是可能你拉起了一條魚，但拉起那條魚是最後一步，早在前面那些步驟達成時，就基本確定了可以釣到魚。
我們回到最開頭我說的那個 bait，學 coding 、資結演算法，學的不外乎是這個釣魚舉例裡面的第三步：你會有效且高效的操作你的釣竿。
那學 coding 既然是第三步，前面兩步怎麼辦？問題就在 coding 的觀念會深切影響到前面兩步：如果沒有這種軟體面的邏輯思維，很難從軟體的角度切入問題，以及衡量不同做法間的種種，譬如實作成本、便利性或是效能問題。
所以 我們從這個角度來說，學習 coding 絕對還是有它的意義存在。那下一步可能會有人問了：
如今 AI 已經蠻會寫程式碼了，也很會分析問題了，那我學這些做什麼？
所以我接著說說，我所認為的代理問題。
代理的機制／本質
如今我們在使用... 或我說"奴役" AI 來幫我們寫程式、查資料或做些有的沒的， 可以視為我們找了一個不具備實體的工程師來代理我們的工作。不具備實體這件事很重要，我等等細說。總之說到這個工程師，他做事情的速度非常快，他過一陣子才學一次，不過一學就會把很前沿的知識一次學起來。
從此，我們好像不見得要把自己的手弄髒了，因為可以叫這個工程師去做... 無論是調查、分析、設計、實現、檢查，全部都有個東西可以使喚代勞了。我們所要做的，好像只有指令丟出去之後，看看他有沒有給我好的成果就好。如果不好，那就給他更多的前置資訊、下更明確的指令等等等。
可是這樣做，會有什麼問題？問題就在一旦把全部東西都丟給 AI 做，人就放棄了軟體工程，從此大家都是專案經理。有人可能會說：放棄了軟體工程又有什麼大不了的？我認為問題是在，從此大家會忘記，或說放棄了某種解決問題的思維、方法，最終是可能性... 大家會忘記原來可以這麼解決實務問題。縱使我們不把視角拉得那麼宏大而聚焦在程式碼這件事情來說，人失去了對程式碼的掌控能力，這其實無異於人拋棄了工具，回到某種原始的生活型態。於是一旦狀況發生變化 ，人完全不懂怎麼自己下手解決，只能一而再再而三的下著各種 prompt，乾等 AI 幫你解決。
我相信有人至此，仍然不會認為這有什麼問題，但那無妨。接下來我想稍微把「沒有實體」這件事情拉出來講，我相信這件事情會讓人有更深的體認。
我們都有一個基本的思維：出事要有人負責。
一個公司的服務掛掉了，CTO 或部門的管理者大概要開始準備自己被「釘在牆上」了。大的被罵完之後，他們會開始找小的，把這份怨氣一路傳下去。結果到某一層後，有個人兩手一攤說：「AI 寫的啊」，接下來會有什麼發展？
我不相信主管會拍拍他的肩膀說：「好吧那也沒辦法」，而是把他罵得更慘。原因就是那一句「出事要有人負責」。因為 AI 沒有實體，沒有人可以讓 AI 負責，所以負責操作 AI 的那個人，就變成必須要扛起責任的人。對，在我看來 責任 就是代理的本質。
那我們哪來可以扛起 AI 輸出結果的肩膀？知識，此外無他，除非純粹的運氣真可行。
為什麼是知識？因為具有知識，才能讀懂 AI 產生的結果，縱使人快不過機器，但人有辦法跟著機器產出的結果讀，去理解它，甚至挑戰它，最終滿懷自信的說：這麼做確實可行。 那知識哪裡來？唯有不斷的學習，從根本開始打下扎實的基礎。扎實的基礎，就是最終自信的底氣。
於是我們再回到「為什麼要學習寫 code 」這個 bait。 一旦跟電腦交互的底層還是程式碼，那這個世界上就還會需要有人會寫 code，就還需要軟體工程腦來支撐這一切。因為最終要有人負責。
結語
2026 年，電腦的底層會變 得不是程式碼嗎？我沒辦法給出一個肯定的答案，僅能說出可能性偏低，甚至在未來的幾年間，我想也大概是這樣。但我可以確定的是，要成為能肯定得為 AI 輸出的結果負責的人，需要的知識是越來越多了，而沒辦法做到這件事的人，可能就會被說「好吧，AI 比你有用多了」。
會這樣做不是想嚇唬人，而是想說，這看似是一個危機，但綜觀人生來說可能是一個轉機。 如今，幾乎全球都在擁護科技業，無論是人才還是金錢，都瘋狂地為科技業這個，看起來仍然肥沃的土壤播種、澆灌。但真的有一個「人人都是工程師」的世界嗎？並不會，其實這世界要很多除了工程師以外的人... 這世界遠比工程要大多了。 那 AI 影響了人的什麼？人有了更多往外探索的可能性，更輕易地獲取任何知識的基本圖像。 不過 AI 也因此遮蔽掉了世界的一部份，僅讓有在動腦思考或有在認真體會世界的人看到了它的全貌，無論是知識、倫理、以及身而為人的責任。
希望這些文字與想法，可以幫助你想清楚，在 2026 年坐在書桌前的理由。