在 2025 年，我們經歷了 LLM（大型語言模型）快速進步的一年，以 AI Agent 形式的工具越來越多，用於開發軟體的 Coding Agent 也逐漸成熟到變成標準配備，而不是用來快速修改檔案的手段之一。

然而，對於軟體工程師來說，我認為 2026 年最值得投資的並不是學會 Coding Agent 這類工具的使用，而是更根本的能力。

你是否看到 Claude Code 的 Sub-Agent 功能就想設計一堆來用？Backend Agent、Frontend Agent 等等，感覺得到更強的工具，但真的需要嗎？

WebConf 2025 期間跟朋友聊到這個話題，才發現大家對 Sub-Agent 的使用時機還是相對陌生。今年有兩場演講提供了不錯的切入點：ihower 大大的 AI Agents 開發 以及 91APP 首席架構師安德魯大大的 從 Service 到 Agent。

以往對於自行架設的伺服器進行安全防護，大多是設定好防火牆（Firewall）以及像是 Fail2ban 這類根據特定規則自動阻擋的工具，就能減緩大多數網路攻擊。

直到前陣子我在家中的 GitLab 突然發了非常多密碼重設信，才發現缺乏很多手段去阻止現代的網路攻擊，單純依靠 Fail2ban 已經不足以解決問題。

因為 LLM 的不確定性，再加上大多數服務都會採取呼叫 API 的方式來使用，我們很難在測試中直接呼叫，比較好的做法是將 LLM 呼叫使用 Mock 方式處理。

如果要測試 LLM 的表現，則會使用 Evaluation（評估）的方式，並不在這系列討論的範圍中

上週五跟 Stan 也是台灣第一位 Ruby Committer（核心貢獻者）和幾位 Ruby Taiwan 核心社群成員在酒吧討論明年社群活動（RubyJam）的規劃，這就需要面對這幾年大部分社群都有實體活動衰退的問題，以及我們都認同的觀點——社群活動不是以學習知識為目的，而是以知識交流前提建立連結。

如果直接使用 Vitest 來撰寫測試，我們需要模擬大量的 API 請求和回應的檢查，這會造成單一測試非常不好閱讀，在維護新的功能時也需要反覆的產生大量重複的程式碼。

我們可以模仿 BDD（Behavior-Driven Development）風格的方式，設定「步驟」的概念，來讓測試案例變得容易理解，也能讓 AI 擴充測試時更加穩定。

前面的內容我們都注重在功能的實現，然而使用 AI 開發使用測試來確保功能的穩定也是非常重要的，至少我們不會因為產生的程式碼有一些預期外的改動，而破壞整個功能的完整性。

使用 AI 工具可以讓我們在初期很快地進行開發，大部分物件也不太需要對依賴注入的問題進行管理。然而在測試階段，能夠透過統一的介面切換測試用的物件，對於後續開發還是非常有幫助的。

我們接下來會使用 AI 協助我們一開始設定的 tsyringe 套件，正式導入到專案中。

最近 Hono 框架推出了 Hono CLI 工具，我很快的就幫 Claude Code 製作了 Hono Plugin 加入 Agent Skill 支援使用 Hono CLI 查詢文件。

同時我也想到，我很少使用的 ri（Ruby Information）命令，跟 Hono CLI 提供的功能非常相似，因此提早將 Ruby Plugin 製作出來，提供 ri 技能。

前面的實作都是將對話編號寫死為 default 接下來我們要讓每個使用者開啟後都能夠產生一個新的對話，而且持續 60 分鐘都可以使用相同的對話串來進行購物。