影片提到軟體開發過程中，真正有價值的東西是設計的邏輯。技術日新月異，需求也一直在變，所以原始碼很快就會過時。就算其他人用非法的手段拿到原始碼，也很難馬上修改，原始碼越龐大，就要花越多時間理解原始碼的運作邏輯，對於競爭對手來說可能重寫還比較快。總體來說，原始碼本身其實沒有想像中這麼有價值。
(影片是這麼說，不過我個人覺得競爭對手拿到原始碼，是可以逆向工程出很多知識的。我想影片作者真正想表達的是從原本的開發團隊來看，原始碼可以視為負債而不是資產，真正的資產是下面所提到的邏輯。)
這個影片的重點是 Peter Naur 提到，軟體開發過程中有三個很難用程式碼或文件完整記錄下來的思考邏輯：
- 現實世界與原始碼的對應關係
- 技術決策當下的背景與原因
- 原始碼如何適應新的需求
而這些難以記錄下來的邏輯，卻是整個軟體專案最有價值的經驗，這些經驗會有很大一部分殘存在參與過專案的人腦海中。
- 軟體的價值在於解決真實世界的問題
這個影片剛好連結到自己最近看到一個軟體工程的方法：領域驅動設計（Domain-Driven Design, DDD），討論軟體開發的價值所在。開發者常常會陷入鑽研酷炫技術，卻忘了真正要解決的問題，導致做出來的東西沒人用。DDD 思考如何讓領域知識盡早參與到開發過程中，讓開發者在設計時，能更好地捕捉現實世界的問題，最後交付出真正有價值的軟體。
一般軟體開發者因為沒有領域相關的知識，得花很多精力去理解真實世界的問題。另一方面，因為理解原始碼的精神成本很高，除了維護該原始碼的人難以參與其中，要等到做出功能後，才能從利害關係人與領域專家們中獲得重要的意見。為了進一步降低開發的風險，在這個基礎上發展出了領域故事化(Domain Storytelling) 的方法，嘗試使用圖形化語言，消除自然語言中的模糊地帶，增加團隊間溝通的效率。
- 站在地科領域的角度可以怎麼看？
非資訊相關科系的人，缺少的是對軟硬體生態的理解，導致 AI 出錯的時候找不到原因，怎麼下 prompt 都沒辦法準確地修正，結果越改越糟，所以才會有工程師說： AI 不會通靈，短期不會取代工程師。
前面提到開發者苦於吸收領域知識，而擁有領域知識的人很少可以開發複雜且龐大的程式。不過在這個 AI 可以幫忙寫程式的時代，很多程式語法的問題，現在都可以快速解決，甚至一些簡單的應用都可以快速生成出原型。
- AI 時代學習程式的方向？
個人認為現在非資訊科系學習程式的重點，可以不用像過去花大量時間在學習程式的語法上，只要可以理解的程度就好，如果當下不能理解，就叫 AI 幫忙解釋。更多時間可以花在理解技術背後的原理和應用情境，就可以有效引導 AI 得到我們想要的結果。
具體一點的問題像是：每個程式語言的特性？資料怎麼儲存在電腦裡的？程式之間怎麼分配工作？電腦之間怎麼溝通？
理解這些背後的原理後，可以進一步去了解如果資料規模放大數千倍，或是硬體被限縮在規格很低的小電腦上，瓶頸會發生在哪？整個軟體架構該如何適應？這個過程需要慢慢累積，建立出現實世界與軟硬體技術的關係。
- 如何更有效率的使用 AI 協作開發程式？
如果不知道如何開始，可以從自己遇到的問題作為起點，不要急著生成程式碼(因為修改具體程式碼的成本比修改抽象的程式架構來的高出不少)，先問問 AI 怎麼設計功能，為什麼要這樣設計？
理解程式架構後，自己嘗試去評估這些技術與自己現有的資源是否匹配，來回交談確定選用的技術與架構，再根據功能生成出每個程式碼片段組合起來。
在迭代的初期不需要太眷戀生成出來的程式碼，可以直接修改抽象的程式架構重新生成原型，等功能釐清、架構穩定了，再來詳細修改程式碼，這樣就可以慢慢理解整個軟體開發的邏輯。
如果必須維護舊的程式碼，可以先叫 AI 抽取出各個程式碼段落的意圖，抽象回程式架構，利用自己的領域知識去補足當時可能的情境，與 AI 討論組織出新的功能與架構設計，再用 AI 去修改或產生新的程式碼。