```
AI coding agents are becoming ubiquitous in development workflows, but a growing number of engineers are discovering that the default behavior of these tools—churn out code as fast as possible—can silently erode software quality. A proposal outlined by engineer Addy Osmani, reposted on O'Reilly Radar, suggests a structured way to rein in that tendency: treat AI agents not as autonomous coders, but as eager but context-blind junior developers who need explicit guidance.
The Speed Trap
The fundamental issue, Osmani argues, is that AI coding agents are optimized for task completion speed. Ask one to build a feature, and it will write the feature—no questions asked. It won't check whether a specification exists, whether tests should come first, or whether its output aligns with existing project conventions. That's a recipe for accelerating technical debt at a pace that traditional code review processes aren't equipped to handle.
This creates a tension that any developer who has used tools like Cursor, GitHub Copilot Workspace, or similar AI coding assistants will recognize: the tool feels productive, but the resulting code often requires substantial rework.
Encoding Discipline Into the Agent
The approach centres on what Osmani calls "Agent Skills"—structured, project-specific instructions that encode software engineering discipline directly into an AI agent's operational context. Rather than relying on vague prompts, teams would define explicit workflows that mandate behaviours like asking clarifying questions before writing code, consulting project documentation, adhering to naming conventions, and producing reviewable increments rather than monolithic code dumps.
This goes beyond typical prompt engineering. Think of it as giving the agent a project-specific onboarding document that it must follow, similar to what a new human hire would receive on their first day.
Responsibility Through Configuration
The approach carries a significant but underexplored implication: it reframes quality ownership. Instead of developers bearing full responsibility for reviewing and fixing every AI-generated line, the team that defines the agent skills effectively configures the quality bar. The code an agent produces is only as disciplined as the instructions it has been given.
For engineers, this means the most valuable skill may no longer be writing code directly, but designing the guardrails that channel an agent's capabilities toward robust outcomes. Osmani frames this as "agent orchestration"—a discipline that blends software architecture knowledge, workflow design, and an understanding of how AI agents actually behave.
Open Source as the Proving Ground
The open-source ecosystem stands to be particularly affected. Maintainers of popular projects already face heavy review burdens when processing community contributions. As more contributors use AI agents to generate pull requests, that workload could spike dramatically.
Existing community infrastructure—files like CONTRIBUTING.md, linting configurations, and CI pipeline definitions—represent natural starting points for formalising agent skills. A project could, for instance, encode its architectural decisions and testing requirements into a structured specification that AI agents consult before generating code. Osmani raises the possibility of a standardised file format, akin to an agent-skills.yml, that projects could adopt to declare their expectations for AI-generated contributions.
Open Questions
Several challenges remain unresolved. How should code review processes adapt to handle significantly higher volumes of AI-generated contributions without sacrificing quality? How can the industry prevent a homogenisation of architectural patterns as agents trained on similar data converge on identical design solutions—a risk made worse if those agents also share similar skill files? And will successful agent skills eventually be absorbed into model training, creating a virtuous cycle that improves baseline agent behaviour?
One notable gap: the piece offers no evidence yet of agent skills files being adopted in production environments, nor of tool vendors building native support for such formats. As adoption data emerges, these will be worth revisiting.
For developers and engineering teams—whether working on internal products or contributing to open-source projects—the takeaway is practical: adopting an AI coding agent without establishing explicit guardrails is like hiring a fast but undisciplined contractor with no supervision. The competitive advantage in AI-assisted development increasingly lies not in whether you use these tools, but in how thoughtfully you constrain them.
AI 編程代理在開發工作流程中正變得無處不在，但越來越多工程師發現，這些工具的預設行為——盡快產出程式碼——可能悄然侵蝕軟件質量。工程師 Addy Osmani 提出的一項建議（經 O'Reilly Radar 轉載）提出了一種結構化的方法來約束這種傾向：不要將 AI 代理視為自主的程式員，而應將其當作積極但缺乏情境意識的初級開發人員，需要明確的指導。
速度陷阱
Osmani 認為，根本問題在於 AI 編程代理是針對任務完成速度進行優化的。當你要求它建立一個功能時，它會直接編寫該功能——不提出任何疑問。它不會檢查是否存在規格說明，是否應先編寫測試，或其輸出是否符合現有的項目慣例。這無異於以傳統程式碼審查流程無法應對的速度，加速技術債的累積。
這造成了一種任何使用過 Cursor、GitHub Copilot Workspace 或類似 AI 編程助手的開發者都會認可的矛盾局面：工具本身感覺效率很高，但產生的程式碼往往需要大量返工。
將紀律編碼到代理中
此方法的核心是 Osmani 所稱的「Agent Skills」——結構化的、特定於項目的指令，將軟件工程紀律直接編碼到 AI 代理的操作情境中。團隊不是依賴模糊的提示詞，而是定義明確的工作流程，強制要求代理在編寫程式碼前提出澄清問題、查閱項目文檔、遵守命名約定，以及產出可供審查的增量式改動，而非一次性提交龐大的程式碼。
這超越了典型的 prompt engineering。可以將其視為給代理一份它必須遵循的、針對特定項目的入職文件，類似於新人類員工入職第一天會收到的文件。
通過配置落實責任
這種方法帶有一個重要但尚未被充分探討的含義：它重新定義了質量責任的歸屬。開發人員不再需要對審查和修復每一行 AI 生成的程式碼承擔全部責任；定義 Agent Skills 的團隊有效地配置了質量標準。代理產出的程式碼的紀律性，完全取決於它所獲得的指令。
對工程師而言，這意味著最有價值的技能可能不再是直接編寫程式碼，而是設計那些引導代理能力走向穩健成果的防護欄。Osmani 將此框架稱為「agent orchestration」——一門融合了軟件架構知識、工作流程設計以及對 AI 代理實際行為理解的學科。
開源作為試驗場
開源生態系統受到的影響將尤為顯著。熱門項目的維護者在處理社群貢獻時，本已面臨繁重的審查負擔。隨著越來越多貢獻者使用 AI 代理來生成 pull request，這項工作量可能會急劇飆升。
現有的社群基礎設施——例如 CONTRIBUTING.md 文件、程式碼風格檢查配置以及 CI pipeline 定義——是形式化 Agent Skills 的天然起點。例如，一個項目可以將其架構決策和測試要求編碼為結構化的規範文件，供 AI 代理在生成程式碼前查閱。Osmani 提出了採用標準化文件格式（例如 agent-skills.yml）的可能性，項目可以採用此格式來宣告其對 AI 生成貢獻的期望。
懸而未決的問題
若干挑戰仍未解決。程式碼審查流程應如何調整，以應對數量顯著增加的 AI 生成貢獻，同時又不犧牲質量？業界如何防止架構模式同質化——當使用相似數據訓練的代理趨向於相同的設計解決方案時，這種風險會加劇，尤其當這些代理還共享相似的技能文件時？成功的 Agent Skills 最終是否會被吸納到模型訓練中，形成改善代理基線行為的良性循環？
一個顯著的空白是：該文章尚未提供任何證據表明 Agent Skills 文件已在生產環境中被採用，也沒有工具供應商為此類格式提供原生支持。隨著採用數據的出現，這些問題值得重新審視。
對於開發者和工程團隊——無論是開發內部產品還是為開源項目做貢獻——結論是實用的：採用 AI 編程代理而不建立明確的防護欄，就像僱用一位快速但缺乏紀律、且無人監督的承包商。在 AI 輔助開發領域，競爭優勢已不再取決於你是否使用這些工具，而在於你如何周全地約束它們。