过去谈到 AI 编程，大多数人首先想到的是专业开发场景：工程师打开 IDE，在代码仓库里让 AI 补全代码、生成函数、解释报错、修复 Bug。这个认知并不奇怪，因为 Agentic Coding 的第一批高频用户本来就是软件工程师，最常见的使用界面也集中在 IDE、终端、代码仓库和开发工具链。
但 Anthropic 在《2026 Agentic Coding Trends Report》中提出的第五个趋势是：Agentic Coding 将扩展到新的界面和用户。报告判断，2026 年的 Agentic Coding 不会只服务传统软件工程师，也不会只发生在熟悉的开发环境中。它会进入更多语言、更多工作界面和更多专业角色，包括遗留系统、领域专用语言、安全、运营、设计、数据科学、法律等场景。
这个趋势的关键，不是以后所有人都会成为程序员。更准确的说法是：软件构建能力会从专业工程环境中溢出，进入更多业务和专业场景。用户未必以写代码为目标，但会越来越频繁地用 Agent 把专业问题转化为工具、流程、配置、脚本和可运行系统。
Agentic Coding 的第一波应用，确实主要围绕专业软件开发者展开。工程师每天都要理解代码、修改代码、测试代码、Review 代码，因此 AI 编程工具天然有高频使用场景。让 AI 帮助工程师写代码，是最直接、最容易被验证的价值。
但报告指出，2026 年 Agentic Coding 会扩展到传统开发工具难以触达的上下文和用例中。这里有两个方向：一是支持更多语言和技术栈，尤其是较少见语言、遗留语言和领域专用语言；二是进入更多非传统开发者的工作场景，让安全、运营、设计、数据科学等角色也能用 Agentic Coding 解决问题。
这说明 Agentic Coding 的边界正在变化。过去，写代码意味着用户必须进入一个工程化环境：理解项目结构，使用 IDE，配置依赖，运行命令，提交代码。未来，很多用户不会以我要写代码的方式开始，而是以我要解决一个工作问题的方式开始。
例如，设计师可能希望快速生成可交互原型；运营人员可能希望自动整理文件并生成报表；安全人员可能希望分析一段陌生代码；数据人员可能希望把分析结果变成可视化页面。这些任务背后都包含软件构建能力，但用户不一定把它理解为编程。
这就是第五个趋势真正要表达的变化：Agentic Coding 会把编程能力包装成更普遍的问题解决能力。它不会只改变工程师的工作方式，也会改变组织内部谁能提出软件需求、谁能验证方案、谁能先做出一个可用原型。
报告的第一个预测是：语言障碍会消失。Agentic Coding 将扩展到较少见语言和遗留语言，例如 COBOL、Fortran，以及各种领域专用语言。这个判断很重要，因为很多人讨论 AI 编程时，默认场景还是 Python、JavaScript、TypeScript、Go、Java 这些主流技术栈。
真实企业系统远不止这些。大量金融、通信、制造、政务和大型企业系统中，仍然存在历史悠久的遗留代码。这些系统可能运行稳定、承载核心业务，但维护成本高，懂的人越来越少，文档不完整，改动风险也更大。
遗留系统的难点不只是语言老旧，而是知识稀缺。年轻工程师可以快速学习一门现代语言，但面对几十年历史的业务系统、复杂调用链和过期文档，仍然很难安全修改。很多组织对遗留系统的态度是能不动就不动，因为任何变更都可能带来风险。
如果 Agent 能理解这些语言，解释旧代码逻辑，定位变更影响，辅助生成测试和迁移方案，那么遗留系统维护的成本会下降。它不一定让所有老系统立刻现代化，但可以降低理解和修改门槛，让长期难以维护的旧系统重新变得可操作。
这也是 Agentic Coding 扩展到新语言的真正价值：它不是只让新项目写得更快，也可能让企业重新处理那些过去不敢碰、没人懂、但又绕不开的系统。
除了 COBOL、Fortran 这类遗留语言，报告还提到领域专用语言，也就是 DSL。DSL 通常不是通用软件工程师每天使用的语言，而是为特定领域或系统设计的表达方式。例如配置规则、数据处理流程、测试脚本、交易策略、基础设施定义、工作流编排、报表逻辑等，都可能使用某种领域专用表达。
这类语言的问题在于，它们往往和业务强绑定。懂通用编程的人不一定懂 DSL 背后的业务含义，懂业务的人又不一定能熟练编写 DSL。于是组织里长期存在一个矛盾：真正理解问题的人不能直接修改系统，能修改系统的人又需要反复理解业务上下文。
Agentic Coding 可以在这里发挥作用。它可以把自然语言需求转化为领域专用表达，也可以解释现有规则的含义，检查规则冲突，生成测试样例，帮助用户理解变更影响。
例如，一个运营人员不一定知道某个工作流平台的规则语法，但可以描述：当订单超过某个金额并且用户等级满足条件时，触发人工审核。Agent 可以辅助生成对应配置，并解释规则如何生效。类似地，测试人员可以描述测试意图，让 Agent 生成符合内部测试 DSL 的用例。
这类场景说明，Agentic Coding 的扩展不是简单支持更多编程语言，而是让更多专业系统的表达方式可以被自然语言驱动。真正的变化在于，业务知识和系统表达之间的转换成本会下降。
报告提到，Agentic Coding 将扩展到新的 form factors 和 interfaces。这意味着，未来编程不一定总是发生在 IDE 里。
过去，软件开发高度绑定专业工具链。用户需要进入代码仓库，打开 IDE，理解目录结构，运行构建命令，执行测试，提交 PR。这套流程对于专业工程师是合理的，但对非工程角色来说门槛很高。
Agentic Coding 的扩展会让更多工作界面成为开发入口。比如：
| 新界面 | 可能发生的 Agentic Coding 场景 |
|---|---|
| 浏览器 | 根据网页数据生成自动化脚本或分析工具 |
| 文档 | 根据文档描述生成流程、规则或原型 |
| 聊天工具 | 在对话中触发自动化任务和代码变更 |
| 业务系统 | 根据业务操作生成配置、脚本或工作流 |
| 数据平台 | 根据分析目标生成查询、图表和处理逻辑 |
| 设计工具 | 根据设计意图生成交互原型或前端代码 |
| 安全平台 | 根据告警自动分析代码和生成修复建议 |
这些场景里，用户不一定感知自己在写代码。但底层实际上发生了代码生成、规则生成、脚本执行、工具调用和系统配置。开发入口从 IDE 扩展到日常工作界面后，软件能力会更贴近问题发生的位置。
这也是为什么报告说，Agentic Coding 会挑战一个长期假设：严肃开发工作只能发生在 IDE 中，或者只有使用专业工具的工程师才能用代码解决问题。未来，IDE 仍然重要，但它不再是软件构建能力的唯一入口。
报告明确提到，Agentic Coding 会扩展到非传统开发者，包括网络安全、运营、设计和数据科学等领域。这些角色并不是传统意义上的软件工程师，但他们每天都遇到可以用代码解决的问题。
安全团队可能需要阅读大量不熟悉的代码，判断其中是否存在漏洞。过去，这要求安全人员既懂攻击面，又懂具体语言和框架。Agent 可以帮助他们快速解释代码、标记危险模式、生成验证脚本，降低跨代码库分析成本。
运营团队经常处理文件、表格、流程和系统配置。很多运营问题本质上是自动化问题，比如批量整理数据、生成报表、检查异常、同步系统状态。过去这些任务要么手工做，要么排期找研发支持。Agentic Coding 可以让运营人员更直接地构建小型自动化工具。
设计团队需要把想法快速转化为可验证原型。过去一个交互原型可能需要设计师、前端工程师和产品经理来回沟通。Agent 可以根据设计描述生成简单交互界面，让设计反馈更快发生。
数据科学团队经常需要写脚本、处理数据、构建可视化、搭建实验页面。Agent 可以帮助他们把分析结果包装成更容易展示和验证的工具。报告中总结了一个共同模式：不同团队会使用 AI 增强自己的核心专业，同时扩展到相邻领域。安全团队用 AI 分析陌生代码，研究团队用 AI 构建数据可视化前端，非技术员工用 AI 调试网络问题或进行数据分析。
这就是报告中所说的 Everyone becomes more full-stack。它不是说每个人都变成职业全栈工程师，而是说 AI 让人们更容易跨越自己的专业边界，在不离开本职工作的情况下获得一部分软件构建能力。
这里需要避免一个误解：Agentic Coding 扩展到非工程用户，并不意味着工程师不再重要，也不意味着所有业务人员都能独立构建复杂系统。
更准确地说，Agentic Coding 会让非工程角色获得一部分软件构建能力，尤其是原型、小工具、自动化流程、分析脚本和领域内配置。这些任务过去经常因为工程资源有限而无法及时完成。现在，懂问题的人可以更直接地尝试解决方案。
但生产级系统仍然需要工程治理。权限、安全、可维护性、性能、数据一致性、系统集成、审计和发布流程，仍然需要专业工程能力。尤其当非技术人员借助 Agent 创建工具后，组织更需要工程团队提供平台边界和治理机制。
所以，未来更合理的分工可能是：
| 角色 | 主要职责 |
|---|---|
| 业务和专业人员 | 描述问题，构建原型，自动化局部流程 |
| Agent | 生成代码、配置、脚本、文档和测试 |
| 工程团队 | 提供平台能力、安全边界、审核机制和系统集成 |
| 管理者 | 定义哪些场景可以自助，哪些必须进入正式工程流程 |
这说明 Agentic Coding 并不是让组织绕开工程团队，而是让工程团队从处理所有小需求，转向提供可治理的技术底座。软件能力扩散以后，工程团队的价值不会消失，反而会更多体现在平台、标准、安全边界和质量控制上。
报告中提到 Legora 的案例。Legora 是一个 AI 驱动的法律平台，它把 agentic workflows 集成到法律技术平台中。报告引用 Legora CEO Max Junestrand 的观点，认为 Claude 在指令遵循、构建 Agent 和 Agentic Workflows 方面表现出色。Legora 一方面使用 Claude Code 加速自身开发，另一方面也把 Agentic 能力提供给律师，让他们在没有工程专业知识的情况下创建复杂自动化。
这个案例很好地说明了第五个趋势。法律不是传统软件开发场景，但法律工作中有大量结构化和半结构化任务，例如合同审查、条款比对、文件整理、风险标记、流程跟踪。律师懂法律判断，但不一定会写代码。过去如果他们需要自动化工具，往往要依赖产品和工程团队把需求转化成系统能力。
Agentic Workflows 改变了这条链路。律师可以用更接近自然语言和专业语境的方式描述流程，由 Agent 帮助生成自动化能力。这并不意味着律师变成工程师，而是法律专业知识可以更直接地转化为软件能力。
Legora 的例子说明，Agentic Coding 的扩展不是开发者多了一个工具，而是专业行业开始把软件构建能力嵌入自身工作流。对这类行业来说，关键价值不是代码本身，而是让专业判断、流程规则和自动化能力之间的距离更短。
报告中使用了 democratizes 这个表达。它的含义不是取消专业门槛，而是降低进入门槛，让更多人可以使用软件能力解决问题。
这和过去的 no-code、low-code 有相似之处，但也有明显区别。No-code 和 low-code 通常依赖预设组件、拖拽界面和固定模板。它们适合标准化流程，但一旦需求超出平台预设能力，就会遇到限制。Agentic Coding 则更灵活，因为它可以理解自然语言、分析上下文、生成代码或配置，并根据反馈调整结果。
不过，Agentic Coding 的灵活性也带来新的治理问题。越多非工程用户可以生成工具和自动化，组织越需要关注权限、数据访问、质量、审计和维护责任。否则，企业内部可能出现大量无人维护、权限不清、逻辑不透明的小工具。
因此，Coding 民主化不是无边界自由开发，而是在可治理框架下，让更多人获得解决问题的能力。真正成熟的组织，不会简单鼓励所有人随便生成工具，而是会定义哪些场景可以自助，哪些场景必须进入正式工程流程。
Trend 5 的核心可以概括为：Agentic Coding 会从专业工程师、主流语言和 IDE 场景，扩展到遗留语言、领域专用语言、新界面和非传统用户。
它带来的变化至少有三点。
第一，语言边界会被削弱。Agent 不只会服务现代技术栈，也会帮助企业理解和维护 COBOL、Fortran、DSL 等遗留或专业系统。
第二，开发入口会扩展。Coding 不再只发生在 IDE 中，浏览器、文档、业务系统、设计工具、数据平台和对话界面都可能成为 Agentic Coding 的入口。
第三，用户群体会扩大。安全、运营、设计、数据科学、法律等角色会使用 Agentic Coding 增强自己的专业能力，并跨入相邻的软件构建场景。
但这并不意味着工程师不再重要。相反，当软件构建能力扩散到更多人手中，工程治理、安全边界、质量控制和平台能力会变得更重要。
因此，第五个趋势可以用一句话概括：
Agentic Coding 的未来，不是所有人都成为程序员，而是更多人可以在自己的工作场景中调用软件构建能力，用 Agent 把专业问题更快转化为可运行的工具、流程和系统。
相关阅读
##### FunTester 名片｜万粉千文，百无一用