為軟體團隊帶入AI力量的思辨: 使用ChatGPT與Github Copilot

為軟體團隊帶入AI力量的思辨: 使用ChatGPT與Github Copilot

科技的演進總是會帶來新的工具。隨著近年人工智慧 (artificial intelligence) 的發展，我們即將踏入新世代 AI 輔助工具的入口。在程式碼撰寫上，最熱門的莫過於 OpenAI 開發的 GitHub Copilot ** 與 ChatGPT 。**然而，這些 AI 輔助工具是否真的能夠長期幫助到軟體團隊的開發，短時間內也許還是一個開放問題。

使用 ChatGPT 這類的工具，雖然很多時候可以很快速地得到解答，但也存在一些問題。比如當 AI 一本正經胡說八道時，我們不像搜尋引擎一樣可以依照可靠來源驗證。又或者是**長期使用AI工具來撰寫草稿，僅對其進行修飾，是否會在無形中影響到個人的特色和創意力？**這篇文章會從軟體開發，特別是程式碼撰寫這部分，結合我個人與一些開發團隊討論的經驗，來看看這些 AI 輔助工具是否適合導入到開發團隊。

在這篇文章的最一開始，想先釐清「是否幫助到軟體團隊的開發」這個用詞。這篇文章認定有幫助指的是長期對於團隊有幫助，即同時符合以下兩個條件：

1. 確實長期對於開發程式的效率有幫助，不單單只是起步快。
2. 確實對於團隊的成長有幫助，即使用這些工具不影響到團隊成員專業能力的培養。

GitHub Copilot

GitHub Copilot [1] 是一種基於人工智慧技術的代碼自動完成工具，歷史可以追溯到 2020 年，由GitHub 和OpenAI 共同開發。它利用了 OpenAI 的 GPT 模型和 GitHub 的程式碼庫，可以學習已有的程式碼和樣式，自動生成符合開發者需求的代碼。

GitHub Copilot 在程式碼編輯器中提供了智能建議，**當開發者輸入代碼時，Copilot 會根據上下文和已有的程式碼，自動提供可能的完成建議。**此外，還可以幫助開發者快速編寫測試用例、生成注釋和文檔等。

GitHub Copilot 與 code editor 整合很完整，以VSCode 為例，直接在extensions 下載官方 GitHub Copilot 插件 ，然後登入 GitHub 帳號就可以開始使用。

目前 GitHub Copilot 已經沒有免費的 plan，要使用都是要付費的。目前個人用戶價格是一個月10USD，或是一年100USD。

GitHub Copilot 會參考使用者已經開啟的程式碼，臆測使用者想法，並且寫出來的程式碼會與原本程式碼有相似的風格。

以下是用Tensorflow 2.0 自定義 gradient 的方法寫的 training step 。在撰寫的過程，GitHub Copilot 會及時地提供他認定的最佳寫法，讓使用者用類似 auto complete 的方法，按 Tab 就完成填寫。

實際上 GitHub Copilot 會生成至多10種不一樣的程式供使用者選擇，第一時間顯示在 code editor上的是他推測最合適的，如果不合適也可以參考他生成好的其他選項中選擇。

GitHub Copilot 會參照原始程式碼的邏輯與風格，所以當原始程式碼寫得越好，除了可以讓 GitHub Copilot 更容易理解，也可以讓 GitHub Copilot 生成的程式碼品質更好。

以下是一個模組化 Json handler ，因為在父類FileHander裡已經明確定義好 template ，並且整份程式都有寫 type hint 。因此 GitHub Copilot 可以自動完成 dump 的撰寫，並且保持風格一致。

在 function 命名明確的情況， GitHub Copilot 也可以快速地生成一些基本的 utilities，但目前這部分的整體效果不如ChatGPT [2] 那麼全面。

ChatGPT

ChatGPT [2] 是 OpenAI 基於 GPT-3.5 與 GPT-4 模型開發的語言生成模型。他可以通過對自然語言的理解和生成，進行自動回答問題、生成文章或對話等。使用情境非常廣泛，包括但不限於於自然語言處理、自動文章生成、程式碼自動生成與搜尋引擎等。

OpenAI 最簡單的使用方法是用一般瀏覽器進入ChatGPT 網頁 ，直接透過對話視窗請他做事。

ChatGPT 有免費的 credits 可以使用。不過相信再過一陣子免費仔的使用範圍會越來越小。目前基本的付費方案是每個月 20USD。

因為 ChatGPT 有提供 API 給開發者打，所以 code editor 上也可以下載到許多插件，但目前尚未出現官方版本。以 VSCode 來說，我個人使用的是İsmail Ali G. 個人開發的版本 (vscode-chatgpt )。

不過在寫這篇文章的過程，原作者表示某些使用者的使用情境已違反 OpenAI 的使用條例 ，因此暫停開發並下架應用。目前我個人還沒看到其他比較可信賴的 vscode 插件。之後有發現在更新上來。

**對比 GitHub Copilot，目前 ChatGPT 在生成更複雜的 utilities 上有更好的能力。**比如說我的指令是 “use Python dash to build a website for uploading images” ， ChatGPT 生成的程式碼如下：

原封不動跑出來的結果是陽春了點，但整體功能算是符合描述：

AI輸出的結果不像搜尋引擎一樣可以依照可靠來源驗證(比如說維基百科 或是stackoverflow )，因此有時候輸出錯誤答案時，就會有一種一本正經胡說八道的感覺。

比如說我要求他 “write code for building resnet-50 in Tensorflow 2.0”，結果是寫了落落長的程式，但其實一點價值都沒有。

又或者是我請他為我們show_bounding_box這個 function 寫 pytest 的 unit test，結果他卻 import 了不存在的程式，並開始寫一段莫名其妙的test case。

這些問題也許發生的頻率不高，而且會在未來持續被改善。但真正的問題是，end-to-end AI solution時常是缺乏可信賴性，並且不具來源，即使可以做到八成正確，但剩下似是而非的狀況還是會造成使用上的困擾。現階段我們很難避免這類的 AI 方法產生一本正經胡說八道的狀態 (畢竟人類也很會胡說八道)，加上因為ChatGPT能力更強，一本正經胡說八道能力的現象有時顯得更加明顯。

因此使用時需永遠保持獨立判斷是非的能力。

The Final Opinions

當這些 AI 輔助工具確實具備輔助功能時，是否能夠長期使用會是一個很基本的考量點。符合這個條件後，值得思考的就是是否會為團隊帶來負面影響，比如說團隊的思考與開發能力。整體上，我認為

在具備原則與警語的情況下，使用這些 AI工具可以為軟體團隊帶來幫助。

一個工具除了好用外，是否可以長期使用是一個很重要的考量點。就像是現在的軟體工程師已經不見得要會使用 vim ，因為現在許多團隊使用複合式 code editor 是很日常的事情；又或者是現在的 ML 工程師，也不見得要會手刻 gradient decent。

即使是 Microsoft與 OpenAI，也很難說死 GitHub Copilot 與 ChatGPT 是否會永遠存在，畢竟科技變化如此快速。但相信這類型的工具在為來將層出不窮，這點估計是不需要擔心的。

目前 ChatGPT 能力真的很強大，能做的事情非常多。也因此許多人會將開放性問題丟給 ChatGPT 處理，自己複製貼上後再稍作修改，已知這樣的方法除了寫程式外，在信件回復與部落格上也屢見不鮮。

危險的是**當 ChatGPT 替代人類的判斷和經驗，尤其是大幅度地程式設計或計劃撰寫時，即使短期內提升了效率，但長期可能帶負面影響。**因為這些事情多半具有較強烈的個人特色，**如果長期都用 ChatGPT 做初始，自己只做修飾，難免在無形中被影響了個人特色與創意力。**這終將削弱團隊的能力，不可不引以為戒。

現階段我們很難完全避免這類的 AI 方法產生一本正經胡說八道的答案，而且**AI 方法輸出結果不像搜尋引擎一樣可以依照可靠來源驗證。因此對 AI 方法輸出的結果完全理解，再放入專案是開發者的義務。畢竟，最終commit code 還是工程師，不是 ChatGPT 。**在現在 AI 工具的應用範疇內，我可完全不期待某筆 commit 上的作者寫著 ChatGPT。

另外，值得一提的是雖然使用 ChatGPT 可以快速地生成許多 utilities ，但如果發現自己很常在生成相似的 utilities ，那反而要精進的是自己程式架構與模組化的能力。

請注意，不論是 ChatGPT 或是 GitHub Copilot 都有可能會蒐集資料來優化他們的模型。我這邊指的不是什麼 API 互動資訊，而是那些程式碼或是拿來請 ChatGPT 回覆的敏感 email 。

具體上，GitHub Copilot付費版目前是預設不分享程式碼的部分，但建議在意的使用者還是到Copilot設定區 確認一下。 ChatGPT 則是預設打開所有對話的蒐集，如果要不分享資料，除了必須是付費會員 以外，還要額外填寫這個表單 **。**還需要這些政策或許隨時都會改變，在意的使用者還是隨時關注比較好。

整體上，我個人目前偏好以 GitHub Copilot 為主， ChatGPT 為輔。或者更具體地說，使用 GitHub Copilot 做為主力輔助工具， ChatGPT 用來獲取靈感。

對於已在專業領域建立知識多年的軟體工程師而言，還是有許多在架構上的判斷和經驗是目前的 ChatGPT 還做不來的，或者說，原本就不在目前 ChatGPT 的守備範圍內。因此**個人目前認為現階段 Github Copilot 這樣與 code editor 整合良好、輔助力道較弱的工具反而會是更穩定的夥伴。**ChatGPT 則更像是一個涉略廣泛的好朋友，偶爾跳出來給自己一些新的靈感。

整體上，目前在我個人的生活中已經大幅地採用了這些AI資源。在程式撰寫上，GitHub Copilot 是我穩定的好夥伴。在寫 blog 或是寫英文 email 的時候，我有時也會讓 ChatGPT 適時作一些補充與潤飾。但我會謹記永遠保持獨立思考的能力。對於一個新的企劃書、文章、程式碼、開放式問題等，先想過自己的答案，才會讓這些 AI 輔助方法參與完稿。

另外值得一提的是，在人類邁向強人工智慧的路上， 2022年的 InstrustGPT無庸置疑是其中一個突破重點，我們獲得了正面教導大型 pretrained model的一種思路。這也將讓我們**在 2023年開始，可以看到越來越多的 AI輔助工具落地。**這著實是一件令人期待的事情。

AI輔助工具終將改變我們的工作習慣，但在這過程中，切勿迷失自己不可取代的核心價值。

Takeaway

1. 目前GitHub Copilot 因為與 code editor 深度整合，對於整份程式碼的理解較好。

2. 專案程式碼的模組化、命名和邏輯越好， GitHub Copilot 表現也會越好。

3. 在大部分的時候， GitHub Copilot 作為日常開發的輔助工具是不錯的。

4. 對於不熟悉的題目，可以使用 ChatGPT 作為參考，快速堆疊出功能。

5. 可以使用 ChatGPT 「輔助」撰寫 unit test 與 documentation 。

6. 可以使用 ChatGPT 適時作為靈感的參考，比如說 debug 、 optimize code 。

7. **End-to-end AI solution 其中一個主要問題是缺乏可信賴性，因此有時會產生一本正經胡說八道的狀態。**這在能力更強的 ChatGPT 上更加明顯。使用時請保持獨立判斷是非的能力， commit code 還是工程師，不是 ChatGPT 。

8. ChatGPT 可以提供一些靈感，但是不應使用於替代人類開發者的判斷和經驗，尤其是大幅度地程式或計劃書撰寫。這些事情多半具有較強烈的個人特色，如果長期都用 ChatGPT 做初始，自己只做修飾，難免在無形中被影響了個人特色與創意力。

9. 使用 ChatGPT可以快速地生成許多utilities (基本功能的function或class)，但如果發現自己很常在生成相似的 utilities ，那反而要精進的是自己程式架構與模組化的能力。

10. AI走向智慧的過程並不是全知全能，無法避免可能存在偏見、歧視。雖然說這與寫程式無關，但同理在程式撰寫上也必定有其不良示好。

11. 這些AI工具目前都是要將原始程式碼或是相關資訊上傳到server計算，雖然商用規範上都有提到可以設定為不保存這些資料 (皆需升級到付費版)，但還是請注意團隊或公司的資安規範。

好了～這篇文章就先到這邊。老話一句，Deep Learning領域每年都會有大量高質量的論文產出，說真的要跟緊不是一件容易的事。所以我的觀點可能也會存在瑕疵，若有發現什麼錯誤或值得討論的地方，歡迎回覆文章或來信一起討論 :)

Reference

1. GitHub Copilot[GitHub Webside]
2. Introducing ChatGPT[OpenAI Webside]
3. Training language models to follow instructions with human feedback[NeurIPS 2022]