一個成本低速度快，一個代碼質(zhì)量高程序可擴(kuò)展性好，你會怎么選？

一位名叫 Ab Advany 的技術(shù)人員最近接了個小活兒，幫他的一位好友在其工作單位監(jiān)督編程案例研究。這項案例研究總共花了兩周時間，他們聘請了兩名程序員為其創(chuàng)建最小可行產(chǎn)品（MVP）。

這兩名程序員都是為該機(jī)構(gòu)工作了很長時間的承包商。Ab Advany 之前也曾與二人合作，對兩人的背景十分了解。首先是來自德國的 Alex，擁有 19 年編程經(jīng)驗，采取 100%純手動編程。來自巴基斯坦的 Hamid 僅擁有 4 年開發(fā)經(jīng)驗，在編程中采用了手寫代碼+Copilot+GPT-4+無代碼開發(fā)。

Ab Advany 表示他們原本以為 Hamid 大概能在 8 到 10 周內(nèi)完成工作，而 Alex 可能要多花上 1、2 周時間。但最終結(jié)果卻令他們大為意外！Hamid 在一周之內(nèi)完成了此項目，端到端測試與測試覆蓋率均達(dá)到 100%；Alex 則只完成了 7%。Hamid 的開發(fā)總成本為 3819 美元，Alex 的開發(fā)成本則為 3520 美元。

讓不使用 AI 的老程序員出局？

具體來說的話，兩位程序員都收到了 Figma 設(shè)計要求和詳細(xì)規(guī)格。設(shè)計師會幫助他們獲取所需資產(chǎn)，外加需要集成的現(xiàn)有代碼。

Hamid 在一周之內(nèi)就完成了首個版本，代碼測試覆蓋率和無代碼部分的端到端測試均達(dá)到 100%。95%的工作量似乎已經(jīng)完成，而且基本看不出有什么問題……

Hamid 在 @bubble 中構(gòu)建了 UI 和前端工作流，使用 GPT-4 生成 Cloudflare Workers，使用 Copilot 集成現(xiàn)有代碼，并使用 GPT-4 來生成測試。

Hamid 的開發(fā)成本細(xì)則：

GPT-4: 211 美元

Copilot: 20 美元

Cloudflare: 5 美元

Bubble: 134 美元

總計: 2460 美元 (共 41 個工時)

托管/運行成本：每月 139 美元

Alex 完成了總工作量的約 7%，成本為：

Vercel: 20 美元

總計: 3500 美元

開發(fā)所有內(nèi)容的預(yù)期成本：4.5 萬美元。預(yù)計額外還需要 1.1 萬美元進(jìn)行測試。

托管/運行成本：每月 20 美元

Ab Advany 的好友跟 Alex 交流了研究感受，對方的結(jié)論是“但純手動開發(fā)的應(yīng)用運行成本要低得多，而且一切都在自己的掌握當(dāng)中。”Alex 顯然沒理解 13 倍的產(chǎn)品發(fā)布速度和 1/25 的開發(fā)成本到底意味著什么。

他們讓 Alex 出局了：因為他只相信手動編碼，而不愿借助無代碼/AI 的力量……而 Hamid 則收到了該公司全職工作的邀請：他將培訓(xùn)其他程序員，讓大家結(jié)合無代碼+AI 進(jìn)行編碼……

拉仇恨？！

Ab Advany 將這個事情分享到了 Twitter，他很好奇這樣的比對會帶來怎么樣的結(jié)果。

他還在 Twitter 線程里補(bǔ)充道：“我朋友所在的機(jī)構(gòu)有 100 多位像 Alex 這樣的開發(fā)人員。現(xiàn)在，他們打算對老程序員做重新培訓(xùn)，甚至用 Hamid 這種新兵取代他們……我覺得 Hamid 這類開發(fā)者五年之后也仍然不愁工作崗位，但 Alex 所代表的群體可能會被迫跳槽或者轉(zhuǎn)行。大家怎么看？”

案例發(fā)布后，大家對他進(jìn)行了更仔細(xì)的問詢：

網(wǎng)友 A：“為什么 Alex 不想使用這些工具？我從 1986 年開始編程，我就很喜歡使用 Copilot、ChatGPT 這些，它們讓我的生活更輕松……”

Ab Advany：“你閱讀完這個 Twitter 線程的話，你會看到許多傳統(tǒng)程序員對‘為什么不使用 AI’的答復(fù)。其中比較重要的一點是，當(dāng)前的 AI 有上下文限制。因此，要使其工作，我們需要進(jìn)行函數(shù)式編程。”

網(wǎng)友 B：“用 GPT-4 武裝的 Alex（老程序員） 會是一個更好的解決方案。難道只有我這樣覺得嗎？”

Ab Advany：“Alex 不想使用 GPT-4。他認(rèn)為會產(chǎn)生錯誤的代碼。特別是這意味著 Alex 需要適應(yīng) AI，而不是 AI 適應(yīng) Alex。”

同時 Ab Advany 也收到了非常多的反方意見：

“當(dāng)然，對于簡單的項目、網(wǎng)站/應(yīng)用程序等，你可以得出這個結(jié)論。但對于具有更高復(fù)雜度的新穎解決方案，你不應(yīng)該運行你不理解的代碼，它關(guān)乎到開發(fā)者的聲譽(yù)。如果它們存在安全漏洞，甚至有相關(guān)法律責(zé)任，該怎么辦？”

“對于構(gòu)建可擴(kuò)展和可維護(hù)的長期關(guān)鍵任務(wù)項目，我會選擇 Alex?！薄敖夤?Alex 是錯誤的舉動?！?/p>

“散布這樣的謊言，你能得到什么？在營銷嗎？此外，這樣的比較甚至沒有提到代碼質(zhì)量。將來你肯定要為質(zhì)量、性能和可維護(hù)性付費。”“可能有些人真不在乎代碼質(zhì)量吧？”

……

不出所料，僅兩天后，他發(fā)了條新推文：“我的推文引起了程序員們的強(qiáng)烈不滿。”

更要命的是他的推文配圖，“RIP，傳統(tǒng)程序員”。他堅持認(rèn)為大家必須更好地評估問題并選擇正確的前進(jìn)方向。因為太過激進(jìn)，所以他得到了網(wǎng)友們對他進(jìn)一步的評價：“真是越來越讓人討厭了！”

抗拒 AI 輔助編程會是一場“必敗仗”嗎？

基于大型語言模型的 AI 工具，比如 OpenAI Codex ，或來自微軟的 GitHub Copilot ，亦或來自谷歌 DeepMind 的 AlphaCode，已經(jīng)開始改變許多開發(fā)者的工作方式。雖然目前它們只可以用來編寫代碼片段、發(fā)現(xiàn)錯誤、編寫注釋、提供建議等，但這并不妨礙讓大家見識到它的威力。

去年，谷歌的研究人員發(fā)現(xiàn)，人工智能將“編碼迭代時間”減少了 6%，這份研究主要針對谷歌內(nèi)部的 10,000 名開發(fā)人員。

GitHub 去年也調(diào)查了 2,000 名程序員，了解他們?nèi)绾问褂?GitHub 的 AI 編碼助手 Copilot。大多數(shù)人表示 Copilot 幫助他們減少挫折感并增加成就感；88% 的人表示這提高了他們的工作效率。在報告中，GitHub 說道：“使用 Copilot 輔助編程的開發(fā)人員完成任務(wù)的速度明顯更快——比不使用它的快 55%?！?/p>

雖然生成式 AI 模型和工具還在改進(jìn)中，但一點也不影響其普及速度，越來越多的開發(fā)者開始使用它們。以 GitHub Copilot 為例，微軟于 2022 年 6 月首次面向個人推出該工具時，平均有超過 27% 的開發(fā)人員代碼是由 GitHub Copilot 生成的。到了今年 5 月，微軟再次統(tǒng)計時，這個數(shù)字已經(jīng)變成了 46%——而在 Java 編程語言環(huán)境中，這個數(shù)字躍升到了 61%。

所以 GitHub 大膽斷言，“鑒于這項技術(shù)可以幫助開發(fā)者加快構(gòu)建速度，所以展望未來，不采用生成式人工智能工具的科技公司將在生產(chǎn)力方面處于明顯劣勢。”

Ab Advany 分享的案例，也許這并不是讓我們單純地比較哪個方案更好，而是讓我們明白，我們已經(jīng)有了很多選擇，AI、低代碼等工具都可以用來解決部分問題，那么該是時候讓我們再次評估如何讓開發(fā)人員進(jìn)一步專注于核心業(yè)務(wù)邏輯、減少底層開發(fā)、讓大家更高效更輕松地工作了。

至于 AI 輔助編程是不是未來發(fā)展方向？這就像一位網(wǎng)友給 Ab Advany 的評論中那樣：“純粹的非 AI 輔助編程工程師在這里是在打一場必敗仗，這很明顯……現(xiàn)在誰會在沒有 Copilot 的情況下編寫代碼呢？”