前幾天一直在回頭整理以前寫程式的經驗，寫到 Debug、找問題，也讓我想到另外一件事情。這二十年來，我們其實一直都在想辦法讓軟體開發快一點。以前會整理共用 Function，把重複的 Code 抽出來，後來開始做 Library、Framework，再往後有版本管理、自動化 Build、CI/CD。每一次工具跟方法的改變，多少都讓開發速度再往前一些，只是以前這種變化比較像是一點一點累積，很少會讓我覺得整個開發方式突然變得不一樣。
最近開始大量使用 AI 之後，這個差異變得比較明顯。有些以前需要幾天處理的工作，現在很快就可以先看到第一版。以前想到一個小工具，還會先衡量值不值得花幾天去做，現在有些事情可能一個下午就可以先做出來看看。
這讓我開始想到以前在公司裡面很常碰到的一種情況，就是需求永遠比人多。每個單位都有想改善的事情，有些是系統功能，有些是報表，有些只是每天重複做很多次的動作。很多需求其實不是沒有用，只是排不到，因為工程師的時間有限，總是得先做影響人數比較多、比較重要，或者真的非做不可的事情。
有些需求大家講了幾次，最後也就算了。可能只有三、五個人在用，花兩個星期開發不划算；可能一個月只做一次，人工處理一下也還可以；也有一些只是覺得現在操作很麻煩，可是還沒有麻煩到值得另外做一套東西。久了之後，連使用者自己也會知道哪些事情不要提了，反正 IT 沒時間，這其實是以前很正常的狀況。
可是現在如果原本要做兩個星期的東西，變成一天或兩天可以先有一個版本，原本的判斷方式可能就會開始改變。以前只有幾個人使用，所以不做，現在如果半天就能完成，也許就做了。以前一年只會用幾次，所以繼續用 Excel，現在如果很快就可以做一個小工具，也許就不用再一直 Copy、Paste。以前有些需求甚至不會被當成系統需求，因為大家早就習慣自己處理，當開發的成本往下降之後，我反而覺得這些以前被忽略掉的小事情，可能會慢慢跑出來。
我們常常會說 AI 可以讓開發速度提高多少、工程師生產力可以增加多少，但如果真的提高很多，後面發生的事情應該不只是原本十個需求比較快做完，可能連什麼事情值得做成軟體，都會跟著改變。
以前做一套系統，通常會希望有一定數量的人使用，因為開發、測試、部署、維護都有成本。如果未來做一個小工具的成本變得很低，那一套東西也不一定非得服務幾百個人。它可能只給一個部門用，甚至只解決某一個角色每天重複做的事情。有些東西也不一定需要用很多年，也許某個專案進行半年，就有一個專案自己的小工具；某一段工作需要整理資料，就暫時有一個程式幫忙；工作方式改了，這個工具也就不用了。
以前我不太會把這些東西都當成「軟體開發」，因為花費的成本不太合理。現在回頭看，這個界線可能會越來越模糊。
但另外一邊也沒有跟著變這麼快。人的時間沒有變多，公司的流程也沒有突然變簡單。系統可以一天做出來，不代表使用者一天就能改掉原本的工作方式。東西做得越來越快之後，使用者到底有沒有時間去理解、接受、使用，反而可能慢慢變成另外一個問題。
所以我現在還不太確定，開發速度一直往上之後，最後會變成什麼樣子。也許以前很多沒有機會被做出來的小需求會開始被滿足，也可能我們很快就會碰到另一種情況，就是可以做的東西越來越多，但真正能夠留下來、持續被使用的東西沒有跟著增加這麼快。
以前做軟體，我們很習慣面對「需求太多，做不完」，所以很大一部分時間都放在排優先順序、估工時、分配開發資源。當開發成本開始下降，這套判斷方式可能也要跟著改。因為一個東西做得快，不代表它做完之後真的有價值；一個 Prototype 很快可以完成，也不代表它值得繼續投入，最後變成正式系統。
這幾年在看企業裡面的數位化、AI 應用時，我越來越在意這一件事情。做完之後到底改善了什麼？原本花多少時間，現在少了多少？原本需要多少人工處理，現在降低了多少？錯誤率有沒有下降？流程有沒有變快？使用的人是不是真的持續在用？這些事情如果沒有辦法回答，開發速度再快，最後可能也只是讓我們更快做出更多東西。
當 AI 開始把「做出來」這件事情變得越來越容易，後面真正需要花時間的，可能會慢慢移到另外一個地方。我們要更清楚一件事情為什麼值得做，做完之後要改善什麼，也要有辦法知道它最後到底有沒有產生效果。
後面幾篇，我也想慢慢把這一塊整理出來。企業裡面真正有意義的軟體或 AI 應用，最後還是會回到實際工作場景、使用者碰到的問題，以及最後能不能看到一些具體的改變。開發速度變快當然很好，只是做得快之後，怎麼知道自己做的是對的事情，可能會變得比以前更重要。