在特定使用情境下，若由合適的人來操作，自動化程式設計能大幅加快軟體撰寫的速度。以我的經驗來看，其產出的成果在結構品質與複雜度的精簡程度上，仍不及最頂尖的手寫軟體。然而，並非所有軟體都寫得如此出色，而我的感覺是，自動化程式設計在大多數情況下（若管理得當）已能超越水準尚可的手寫程式碼的品質。

然而，在使用 AI 撰寫新軟體的情況下，品質與時間之間仍存在取捨。在我開發的某些專案中，這種取捨可能非常劇烈，也就是說，原本可能需要數個月才能完成的專案，現在只需幾週就能完成。不過，在某些領域中，LLMs(大型語言模型) 單純地開啟了更強大、能自動化流程的全新途徑，而且完全無需在品質上妥協。其中一個領域就是軟體 QA 與測試。

傳統上，軟體是透過測試套件來進行測試，測試套件由局部範圍的測試與整合測試所組成（以 Redis 為例：一件事是測試 SET foo 10 是否能被 GET foo => 10 正確對應，另一件事則是測試在此情況下 replication 是否正常運作）。接著再透過通常以手動執行的 QA 流程，來彌補可執行測試套件中的漏洞。眾所皆知，涵蓋所有程式碼行數並不代表涵蓋了所有可能的狀態。此外，整合測試在結構上就很困難：存在許多時序問題、環境設定，以及某些只能以視覺檢查、無法自動驗證的品質輸出，導致許多測試機會因時間或後勤限制而未能真正被利用。

LLMs 在現有測試方法之上，提供了一種全新的 QA 執行方式。其構想是建立一個 markdown 檔案，要求 AI agent 擔任 QA engineer，針對新版本執行多項手動測試。舉例來說，以 DwarfStar（一個用於 open weights LLMs 的 inference engine(推論引擎)）為例，我採用了以下做法。在 markdown 檔案中，會要求 agent 檢查在已發布的軟體專案版本之上新增了哪些 commit。接著，告知模型應該執行的一系列事項，例如：

• 檢查分散式推論在 MacBook A 與 MacBook B 之間是否正常運作，確保輸出一致，且推論在兩台機器上的所有 GGUF 檔案上都能正常運作……
• 確保此版本沒有任何速度衰退。

等等。值得注意的是，在速度衰退的部分，我不需要告訴 agent 先前預期的速度是多少，因為這是一個會隨著新版本與新的最佳化而不斷變動的目標。同樣地，分散式推論的整合測試也不需要太多指示，在檔案開頭只需提供 SSH endpoints 與要使用的 key、路徑等資訊即可。

系統會要求 agent 針對這份長長的 QA 活動清單，*特別*是根據新增的 commit 來進行檢視，首先檢查變更內容並辨識可能受影響的範圍，讓 QA 流程能專注於找出特定的回歸問題。

以 Redis Arrays 為例，我使用了類似的方法，要求 agent 建構一個大型的、基於陣列的 Redis 應用程式，建置一個具備 replication 與 persistency 的正式環境，模擬該應用程式在多名使用者使用數天之久的情境，並檢查是否有任何異常。

採用這些方法的測試，也可能觸及軟體品質中較為心理層面的部分，要求 agent 找出所有可能讓人感到意外、文件說明不足，或從使用者角度來看整體上顯得粗糙的新功能。這些事情過去都需要手動執行，而且大多數時候都被略過了。

我有種感覺，自動化 QA 的引入可能會提高軟體新版本的品質門檻，或許也能在一定程度上彌補以自動化程式設計高速產出、但品質較低的程式碼所帶來的不足。