“我們現在推行AIGC，服務端不需要UI交互設計的用AI自動產出代碼，你建議的結對編程、TDD等是否還適用？”
這兩年AI確實很火，是報紙、雜志的熱門話題。例如，HBR雜志從2024年9月至2025年二月份3期，里面有接近一半文章都與AI有關。朋友圈晚飯或在飛機場候機廳我都提過以下對話：
“未來人類的工作估計全都會被人工智能取代！”
“以前以為有些專業，例如醫生，會比較放心，難以被AI替代，但聽說好像連手術也可以由機器人來做了。”
越來越多開發團隊使用AI，希望提高效率。如何能有效地利用AI？應如何適應這新技術發展？ 詳細討論這些之前，先分享兩個故事：

兩個故事

某歐洲城市巴士公司為了提升效率管理層引入了獎金計劃：按計劃不延誤，給司機的獎金越高。
因為巴士按區收費，售票員也要查看下車乘客有沒有正確按規定買票，公司會隨機隨機派人抽查，如發現售票員違規（包括售票與查票）會扣獎金。因為收入提升，司機或和售票員都喜歡新的獎金制度。售票員在巴士后方有固定位置，指示司機是否可以開車離站。但當交通繁忙時，因乘客太多，太忙，售票員可能來不及回到車尾位置指示開車，這類延誤會影響到司機的獎金收入。售票員大部分是少數民族新移民，司機大多是來自傳統藍領階層，經常發生糾紛，有時候甚至會雙方動手打人。請問有什么解決方案建議？
改善獎金制度？例如：平均分配獎金？請雙方代表坐下來協商？一起討論解決方案？

最終解決方案：
因為發現主要的繁忙車站數量比巴士數量少，所以安排售票員守在車站，在巴士到站前預先售票，售票員也可以在車站查看下車的乘客是否買了正確的車票；也可以在車站指示司機是否可以開車。非繁忙時間售票員可以正常回到巴士里工作。

---+++---

美國一家歷史悠久的彩色印刷公司，主要為高端的雜志和出版社印刷彩色照片或者油油畫等。公司在美國俄亥俄州有8條生產線，雖然銷售還是很理想，但管理生產的副總裁VP要解決一個頭疼的問題——過去5年生產線的生產率逐年下降，甚至已經開始沒有利潤。通過檢查設備、機器是否老化、設備缺乏維修等，發現這些都不是原因。最后發現主因是雖然增加了大量新產品，生產量卻很少，而每一輪生產之間的準備時間卻要增加很多，便請顧問看看如何優化生產的時間安排，希望能盡量減少準備時間。
顧問先用電腦對生產進行模擬，發現如果改善策劃，確實能提高生產率。但顧問同時也發現產品線中絕大部分的利潤來自8%的產品，它們構成所有生產的9成。另外很多“老”產品，銷售量很小，基本沒有利潤。發現這情況后，顧問跟生產副總裁提建議，但被拒絕——“賣什么產品，不是我們管生產的范圍。”就請他問管市場部的副總裁，副總裁雖然沒有拒絕，但擔心影響客戶滿意度也不愿意取消老產品。因為這家老公司承諾客戶永遠不會停掉某一條已經提供過的產品線。
顧問還是覺得問題的核心不在調整生產，建議修正銷售人員的分成安排：基本薪水不變，但他們的分成會按銷售是否有利潤掛鉤。如果他們多賣一些有利潤的產品，他們的收入就會提高。但如果他們多賣一些沒利潤的產品，對他們的收入沒有幫助。人事部對這個建議很感興趣，愿意找美國某區域做試點，試點發現有65%沒有利潤的產品在整個試點區內就沒有銷售，但有利潤的產品就提升了18%，銷售人員的收入加倍，然后公司的總收入也上升了一倍。

---+++---

以上兩個故事的經驗教訓：

• 改善系統的某部分不能改善整個系統
• 解決問題應從各種視角看，如果僅僅某個專業來分析，難以找出整個系統的最佳方案

在軟件開發公司也有類似例子，比如專門給醫院做系統的公司發現80%開發出來的功能沒有用上，浪費資源。改善開發流程并非問題的核心，而應針對怎么去挑選并拒絕沒有價值的需求，公司組織里面的功能互相依賴，好比我們人體器官相互依賴，不能單靠優化某一部分改善整個系統。

向煤礦工人學習

戰后50年代的英國煤礦，在機器化前，煤礦工人都是小組手工運作，伙伴互相幫助，后面利用機械化大規模采煤，類似工業生產的生產線一樣，本以為設計好整個系統，配上工人，就能大大提升效率。但發現并非如此，機械生產開始時，按技能要求分工，如鉆洞、切割、修建隧道、挖煤、清理等，每人負責一小塊固定的工作，輪班 （詳見附件的圖2），發現工人常常生病，出勤率也不理想。必須安排后備人員，因某些崗位缺人會影響整個過程。
因煤礦是天然產生，煤層（分布、厚度等）會按地形變化。例如，如果最后挖煤的人發現前面負責挖洞工人沒做好，挖煤便很困難。機器化之前都是團隊制，互相依賴，互相幫忙解決問題。但現在工作細分后，當挖煤的工人遇到困難時便求助無門，很無奈，導致大量缺勤、生病。
針對這不足，有些公司采用多功能團隊制，讓團隊可以靈活按需要轉換工種，不是只做某一塊工作，像機械化前互相合作，發現效果很好，生產力從以前的78%提升到95%；曠工率從20% 降到8.2%。（詳見附件）
從以上研究發現，不能僅僅靠科技設計生產線，也必須考慮人的因素，E.Trist 、F.Emery 等學者提出社會技術系統 socio-technical systems (STS) 的概念，工人不是生產機械的延續。

1936年的經典黑白電影《摩登時代》(Modern Times)，卓別林演電影中的工廠工人，每天不斷地做一項工作：擰螺絲釘。最終頂不住煩躁的工作，發瘋了，借此諷刺工業生產線生產的問題。

軟件開發也一樣。
前面章節提到有些公司從需求到測試每個環節分工明確，某些崗位只做需求，某些崗位只做設計，誤以為每個環節做好，總體的效果一定會好，忽略了活動間相互依賴。例如需求寫得模糊會導致開發和測試出現缺陷和返工。這些都要等到測試和驗收時才發現，但正因為每個工種獨立，做開發或測試的很無奈，因為心里都知道，問題是出自需求，但她控制不了。所以敏捷開發強調要小團隊各人互補。
例如：測試報告：
因為測試只能從他的視角看到有多少是系統測試找出的缺陷做分析，沒有考慮其他過程，如評審，需求等，不清楚缺陷的真正源頭，報告對減少后面缺陷與返工沒有幫助。但是如果所有團隊成員，包括需求、開發一起分析缺陷的排除率，就可以更全面的看到問題了。
“我們確實有類似以上的問題，但如果要改善整個系統有什么好辦法？”
“請問你現在電話的一些功能，例如：

• 按鍵音頻電話、呼叫等待、呼叫轉移、語音郵件、來電顯示、電話會議、免提電話、快速撥號
• touch tone phone , call waiting, call forwarding, voice mail, call ID, conference call, speaker phone, speed dial in memory

是什么時候發明？”
以上功能都是1951年在美國貝爾實驗室創造出來的。例如，按鍵音頻電話機之前的電話都是撥號盤式。現在可能只能在某些古典酒店大堂看到，而且都是假的。

1951年，貝爾實驗室的會議室

“全美國的電話系統昨晚被切底破壞，一無所有了。”召集緊急會議的副總裁很嚴肅，跟所有部門經理說。
“你們各位最好相信我剛才這番話，如果到了中午你們還不相信的話，我就辭退你。”
所有經理都莫名其妙，想“今天早上我才打過電話，這位副總裁出了什么問題？”
過了一會，副總裁面露笑容，原來他是跟大家開玩笑。
然后他解釋說，“很多美國人都相信我們實驗室是全美國最優秀的研發實驗室。請問貝爾實驗室對電話系統的最大貢獻是什么？”
“轉盤式 (dial) 電話”

“同軸電纜 (coaxial cable)，經過大西洋連接美國和英國”
“但這些偉大發明都在1900年前，都是在座的所有人出生之前 ，你們都只是對電話系統做了些改善，沒有什么更大的貢獻。
要做出有突破的優秀發明，先有以下2假設：

1. 假定現在的系統已經被徹底破壞，從零開始想象希望電話系統有什么功能和好處？而且只是針對現在，不是五年或者十年以后。
2. 不要顧慮有任何困難，先從客戶的角度提出。

但還要考慮2個限制條件：

• 技術方面是否可行，我們不希望只是一個科幻小說的場景
• 在現在環境可操作，因為我們不可能改變環境，包括所有的法律、規章制度等

我們這么多人不可能一起設計，先把你們分成6個小組，包括：

• 城市內的短途通信
• 城市間的長途通信
• 交換機
• 電話機等

現在大家開始分組討論。”

上面提過(包括按鍵式電話) 的多種現代電話功能，都源自在當天分組互動工作坊里電話機小組的頭腦風暴討論。（工作坊時間有限，組員先從用戶的角度，會遇到什么困難，想象有了新功能想法后，還是要與工程部交流，探索可行性。）
以上是Dr Ackoff 教授1951年的親身經歷，這次經歷促進他在2006年出版《最佳設計》(Idealized Design,詳見參考)。他提倡要做好設計應：

• 大家天馬行空沒有任何顧慮和限制，不考慮現在系統
• 不去分析現在系統的不足
• 工作坊形式交流與頭腦風暴：沒有公司崗位級別的區分，每個人都可以暢所欲言
• 因為這些經理都有參與開頭的討論，后面他們才會支持并投資源實現這些新發明

這最佳設計思路也適用于改善過程。我會經常利用在這類工作坊來幫助企業做過程改進，強調4點工作坊原則：

• 包括整個系統 Whole system in the room.
• 從全局“全象”策劃本身行動 Global“whole elephant "context for local action.
• 關注未來和共同點，而不是問題和沖突 Focus on future and common ground-not problems and conflicts.
• 自我管理，對行動負責 Self-management and responsibility for action.

很類似《最佳設計》里提倡重點，因背后都是基于STS學者研究發現的原理。

經驗分享

必須找到了合適的利益相關者參與，必須整個系統的代表在一起，才能包含各種視角，例如，發現原來開發或產品經理是不理解現場實施人員面對的問題，測試人員也不知道開發人員面臨的問題等。但當大家都聚在一起的時候，就可以交流、討論如何改善整個系統。
主要部門負責人都要在，如果他們不在的話，所有新的思路會因為沒有獲得資源和支持，都很難推進。反過來如果相關人都有參與討論的話，他們后面就有動力參與推行，因為覺得這是自己有出主意的東西。
也打破了公司里面的高低層的關系，每個人都可以自由發言，提意見。
如果剛才貝爾實驗室的場景只靠高層副總裁定個年度計劃，設定目標給一層一層去做創新，你估計會在短期內發生這么多新的創新變化嗎？
不可能。個人的想象力有限，當然貝爾里面的人員每個都是行業精英，所以更容易在適合的環境，從整個系統看問題，做出突破。

開發團隊如何應對AI大趨勢

“AI實在太厲害了。AI圍棋，初級，它讓我6子，我還是贏不了。我以前一致認為電腦下象棋打敗人類可信，但圍棋太復雜了，一直不信電腦能學好這玩意。”我老同學聚餐時說，他從初中已經懂圍棋，有超過40年下棋經驗。

越來越多人問人工智能幫公司提升生產率嗎？我不懂人工智能，用手機下載了POE做一些查詢，會導出一個很好看的報告，后面我再去細看的時候，發現里面有的信息是錯誤的。
例如，2025年2月初問：“Eric Trist Biography”

雖然格式包裝都很專業，但內容有誤：第一天：發現去世年份時2019年是錯誤的。第二天；同樣再詢問，（1909-1993） 是正確，但出生地點不是倫敦，他是劍橋大學畢業，非倫敦大學。 與能網上免費搜索到，如維基百科或Britannica出的內容相差甚遠。
AI也可以自動生成PPT報告，并配上聲音讀出來。一些超過二十分鐘的PPT，我通常看不到兩分鐘就離開了，因為太樣板化，沒有人氣，就和打電話給人工智能客服一樣，你會盡量想找個真人來跟你對話。
對比18分鐘的TED講話，講者可能會先跟你開個玩笑或者挑某一件事引起你的興趣，然后中間也會有停頓，有聲調的高低，最重要會和現場的人有各種交流溝通，眼神、面容等，這些都是機器暫時無法替代的。也正是這些元素來吸引你，繼續聽完他的18分鐘講話。
以上實驗暴露了AI的不足，因為它是靠大量搜索同類的文章信息，提供“最佳”答案，但中間可能缺乏檢測過程，產生錯漏，但客戶（人類）可能誤以為電腦出來的都是正確。所以雖然AI能很有效解決有明確規律的問題，如圍棋，但難以取代人的思考與交流。而且與AI交流如進入了虛擬世界，難分真假。
所以有些研究發現程序員雖然用了AI自動生成代碼，雖然代碼多了，好像生產率提高了，但是缺陷數量也增加了。2024年的研究，分析了使用ChatGPT自動生成JAVA/Python程序，共四千個程序：發現40%-89%產出“正確”代碼，看語言、難易度、是否有類似“老”程序供參考等因素。用靜態掃描“正確”代碼，發現各種代碼異味（ 詳見附件）。
很多時候是初級的人員沒經驗，誤以為自動生成的代碼都是正確的，沒去校驗，就會出現問題。

所以大家不用擔心AI會取代開發人員工作，因 AI只是有很大潛能的工具，類似80年代 IDE能提高開發效率，但無法超越人類，而且要小心使用。 因為AI自動出來的代碼有不少缺陷，更需要我們前面提到的單元自動化測試，更需要團員間的評審，結對編程等確保代碼的質量與可讀性。更需要有環境讓團隊成員一起不斷學習、不斷交流、一起進步。最終人才最重要。（2023年，有家出名北京軟件產品公司，我建議他們要有自動化單元測試，但開發主管說我的代碼都是劑槍人自動生成，無法做到。所以他們內部集成、系統測試時，有些產品會以4位數的缺陷發現。）
所以豐田汽車的大野先生在五十年代引進機器人自動化的時候也特別小心，他不會以為買了機器人就能提升公司的生產率，必須要工程師想好怎么利用機器人輔助工作，確實能提高質量和效率才會批準購買。 我們也應該向大野先生學習，不要誤以為用了AI就能提高效率，更需要看怎么可以輔助編碼人員、開發人員、測試人員做好他們的工作。
如有固定規矩，偏重復性的工作，機器和AI能發揮作用 （如下棋、酒店送外賣到房間）；但要有創新的工作最終還是靠人。不要輕信短期未來人類會被人工智能取代，沒有工作。
要做最佳設計還應參照1951年已經有公司成功使用的方法和原則。
AI只是一類新科技工具，每個人要更好學習提升才可以跟得上市場的競爭的最佳對策。
所以HBR2024年9月份一篇文章提到公司不應誤以為AI是可以幫公司創造獨特的競爭能力，原因是你可以用AI，你的競爭對手也可以很容易復制。（詳見參考）

總結

雖然本部分分章節討論需求、設計、編碼、集成、評審、測試各過程的最佳實踐，但若想改進應先設定總體目標，用多種視角看整個系統，再定各過程如何配合，好比建筑師按你的新花園別墅要求（如2層4房2廳，預算在一千萬內）一樣，必先做總體別墅設計，而不是先分別房間、客廳。

附件

英國煤礦生產問題的研究

在機械化之前，英國采煤是以小組作坊式工作,通常是兩人一組，再加上一位做清理的助手。小組會直接跟礦場合作，專門負責某一塊煤礦，小組以互補的形式做各種工作，自己管自己，獨立性很高。因為采礦工作非常危險，所以選擇伙伴很重要，都希望有穩定的伙伴關系，不會輕易換人。當某工人受傷或者去世，他的伙伴都會盡力幫助他的家人。這種小組作坊式工作方式后來被機械化生產線模式取代，但機械化生產卻引起很多新問題。
先了解一下長壁（Longwall）開采法是怎么利用機械化大規模開采煤礦。
英國的煤層一般不深，最多可能1米左右，上面覆蓋著泥土。用長壁機械化采煤方式就可以大面積采煤。

圖1：

（上圖A部分是煤礦俯視圖，B部分是俯視圖中長璧面從左面X 到右面X 直線的切面圖，能看到是左、中、右3條隧道）

共180米寬的長壁是為了大面積采煤，（看上圖）為了通風和運輸，會有3條隧道，之間距離90米，中間隧道是比較高，大概有3米(9英尺)，左右隧道比較矮，大概2.3米(7英尺)高。這些隧道都是固定，讓人或機械可以在中間通過。看上面平面圖，左右2塊90米寬的方形面積都是已經采完煤的泥土。從下面的切面圖（B） 可以看到中間的和兩邊兩個隧道。每個采煤的煤層，只有1米高。也可以看見1米高的柱子，柱子是用來頂住上面的泥土，防止泥土在煤挖空以后塌下來。

長壁（Longwall）如何操作：
沿長壁面X到X180米的直線有兩條平行的過道，都是1米寬。貼著煤礦哪條一條只有1米高的通道，是讓采煤工人爬過去工作。旁邊有一條傳輸帶運作的通道，也是一米寬，一米高。每一米都會有柱子頂住上面的泥土。當長壁180米的煤挖完后，會繼續同樣往煤礦開2條通道，拆掉原先的柱子，搬到新建2條通道使用。原先2條通道的上層泥土會塌下來。你可以想象挖煤工人沿著一米寬一米高的通道挖煤，放到旁邊的運輸帶，工作環境多么惡劣。

工程師設計了7個工種，請參照下面的輪班表。每循環會包括3個輪班：

• 第1個輪班主要是做轉動和切割和清理，比如讓那些切割的煤有空位落下來，讓后面那些采煤工人容易可以采到煤。通常第一個輪班都是下午班或者晚班。
• 第2個輪班就是鞏固隧道和安裝傳輸帶，通常是下午班或者晚班，這2個班總共就會大概有20個工人。細分到不同的工種，比如有2位只鉆洞、2位只切割、8位專門管理通風隧道的鞏固工作，分工很細。
• 第3個輪班主要有20位采煤工人操作。第3個輪班只有早上班和下午班，所以他們需要依賴前期技術人員做好準備工作，然后自己按大概9米的范圍去采煤。收入是按采煤量計算，比如20位采煤人每人負責9米，加起來剛好等于整個長壁的180米。

分工設計很科學，如果都按正常操作，每次循環可以采到200噸煤。
圖2： 工人分工和輪班

但是你估計，這種機械化的大規模連續采煤操作會有什么問題？生產力效果怎么樣？
以上的工作關系很密切，例如：

• 如果洞鉆得不夠深，采煤工便采不到煤。
• 如果切割沒做好會導致采煤工可采空間不足，影響產量。
• 如傳輸帶沒有安裝好，不成直線就導致后面的傳輸停頓，采煤工無法操作。

各種狀況都可能發生，加上煤礦是天然的，本身就有很多變數：例如地層有斷層，或者地下天然氣等。各種人為因素或天然因素都影響采煤工能否正常采煤。加上采煤的工作環境很惡劣，導致曠工問題很嚴重。例如某采煤工因前面2個輪班工作沒做好，導致煤太硬，采不了，就需要用機器、工具去采，很辛苦，效果也不好，導致他工作2天就放一天假，然后也不補班。有些輪班因為人手不夠，剩下的采礦工人就需要在地下多做兩三個小時，才可以把整個長壁做完。最后當有些輪班時，采礦人數確實太少了，其他人也撂擔子，導致無法正常開工。
因為采用機械化大規模采煤的各種問題，有些礦場開始引入自主團隊組織架構，取代原本的輪班分工（下面稱為傳統分工）。
表1是兩個不同的組織架構，技術都一樣，也是在同一個環境。左面用原本長壁的方式設計工作分工，右面的加上自主團隊負責制分工。左面礦工只需要做一項簡單工作，比如采煤，與其他工人沒有任何關系（在前面已詳細舉例說明）。右面就需要組員合作，協調應對采礦的各種特殊情況。
從這個例子看到同樣一個采煤技術，可以有不同的組織架構支撐，效果完全不一樣。所以團隊組織架構必須與技術部分相配合，不能單獨設計工人工作。

表1:

	Conventional傳統分工	Composite自主團隊
Number of men人數	41	41
Number of segregated tasks 任務數	14	1
Mean job variation for members 每成員的平均任務/變化數:
Tasks work with 要處理的任務:	1.0	5.5
Main tasks worked 主要任務:	1.0	3.6
Diff. shifts worked 不同的輪班:	2.0	2.9

從下面表2可以看到右面的組織架構更靈活，生產率比傳統的單一工作設計高。右面的自主團隊架構更能適應變化萬千的采礦、采煤環境。采煤的步驟安排，也必須按照按環境的不同來應對。但如果是左面的硬性單一分工安排，缺乏這種靈活性（除非是專業性強的技術工種，必須把工作細分,每個人做某一件事)。但在采煤機械化、批量生產這種技術沒有這個限制，所以采煤工人經過一些學習可以兼任其他工作。

表2:

	Conventional傳統分工	Composite自主團隊
Productivity(%) 生產率	78	95
Ancillary work at face(hrs per man-shift) 輔助工作(小時/每輪班)	1.32	0.03
平均后備人力/總人力 (%)	6	no
Shifts with cycle lag 輪班延遲 (%)	69	5
最長連續輪班數（沒有輪班有問題導致取消）	12	65
average per cent of coal won each day平均每天獲得的煤炭%

團隊組織架構除了讓工人更好做好采礦工作以外，也可以更好滿足工人的個人心理需要，包括互相支持，有團隊合作的概念。但是如果按左面傳統的工業化分工，就缺乏合作。導致很多采煤工只能單打獨斗，孤立無援，導致心理壓力很大。這個也可以從表3的缺勤率看得出來，會更容易無緣無故請假等，背后主因是分工設計導致工人心理壓力太大，承受不了。團隊互相協助的環境可以減輕這方面的壓力。

表3:

	Conventional傳統分工	Composite自主團隊
Absenteeism (% of possible shifts)曠工率(可能輪班數之百分比)
Without reason 沒有理由	4.3	0.4
Sickness or other 病或其他	8.9	4.6
Accidents 意外	6.8	3.2
Total 總數	20.0	8.2

ChatGPT 自動生成代碼質量研究結果重點

2024年發文的研究分析了4066個ChatGPT 自動生成的JAVA/Python程序，發現2756個正確（約占68%），1082個結果不正確，177個編譯出錯。

• 成功出正確結果%與程序難易度相關，容易的程序成功率最高，難的成功率最低，JAVA 與 Python 一樣
• Mann-Whitney U 測試JAVA與Python間的差異是否顯著P-value都大于0.05 ,差異不顯著（詳見下表）

表1：LeetCode的通過率準確率

Pass@1	低 Easy	中 Medium	高 Hard	總 Overall
Python	0.890	0.674	0.400	0.664
Java	0.860	0.710	0.468	0.691
P-value	0.346	0.654	0.535	0.471

• 也取決于這程序是否新出現，越新越容易出錯（因ChatGPT難以從網上找到參考例子）：
• 下圖最右是2023年1月后，最左是2021年7至12月
• 難度越高，新舊間的差異越大

• 程序越難，發現代碼的質量問題越多

• 下表是編譯錯誤、輸出結果有誤、代碼異味與維護性、性能等問題(issues)按語言、難度的分布：
  • 代碼異味例子：定義了變量，但沒有使用

表3： 按難度級別和編程語言的問題分布

	Easy (501)		Medium(1,064)		Hard (468)		Pass (2756)	Fail (1310)	Sum
	P	J	P	J	P	J
Compilation and Runtime Error	7 (1%)	8 (2%)	37 (3%)	32 (3%)	46 (10%)	47(10%)	0 (0%)	177 (14%)	177 (14%)
Wrong Outputs	47 (9%)	60 (12%)	290 (27%)	260 (24%)	229 (49%)	196 (42%)	0 (0%)	1,082 (83%)	1,082 (27%)
Code Style and Maintainability	174 (35%)	230 (46%)	431 (41%)	588 (55%)	194 (41%)	313 (67%)	1,243 (45%)	687 (52%)	1,930 (47%)
Performance and Efficiency	1 (0%)	2 (0%)	20 (2%)	16 (2%)	6 (1%)	6 (1%)	0 (0%)	51 (4%)	51 (1%)

• 利用chatGPT AI功能自動修復，成功率按程序語言、難易度和錯誤類型分布：（下圖）
• 從20%左右起，最高能達到60%

參考 References

1. E.L. Trist and K.W. Bamforth, 'Some Social and Psychological consequences of the Longwall method of Coal-Getting, Tavistock Institute (1951)
2. F.E. Emery and E.L. Trist, 'Socio-technical systems', in C.W. Churchman and M. Verhulst (eds.),?Management Science, Models and Techniques, vol. 2, Pergamon (1960)
3. Ackoff,R.L. , J. Magidson and H.J. Addison,?IDEALIZED DESIGN Creating an Organization's Future.?Wharton School Publishing (2006)
4. Barney, J.B. and Reeves M., 'AI won't give you a New Sustainable Advantage.' Harvard Business Review Sept-Oct, 2024.
5. Liu, Y. et al. 'Refining ChatGPT generated code: characterizing and mitigating code quality issues.' ACM Trans. Software Eng. Methodol. Vol.33, No.5, Art.116 June 2024.