ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

AI编程时代,程序员的工作正在发生什么变化?

AI编程时代,程序员的工作正在发生什么变化? AI写代码越来越快程序员为什么反而更累了执行摘要AI 编程真正改变的可能不是“程序员还要不要写代码”而是程序员的工作正在从“生产代码”转向“监督代码”。GitHub Copilot 从 2021 年的代码补全已经一路演进到可以自行修改文件、运行命令、创建 PR 的 Coding AgentClaude Code、Cursor、Codex 也把 AI 从“给你建议”推进到了“替你执行任务”。[11]效率提升是真实的但它并不自动等于工作量下降。2023 年一项 GitHub Copilot 对照实验中开发者完成一个标准化 JavaScript 任务快了 55.8%但 METR 在 2025 年对资深开源开发者真实项目进行随机实验时却发现允许使用 AI 的任务平均反而多耗时 19%。两组结果并不矛盾AI 对“生成”的提升很明显但越接近复杂、长期、需要上下文和交付责任的真实工程验证成本越重要。5所以我越来越认同一句话AI降低了写代码的成本却没有降低把代码安全地交付到生产环境的成本。背景老板“现在都有 AI 了这个功能应该很快吧”业务“AI 都能写代码了为什么还需要这么久”这两句话我相信不少开发者已经听过。问题在于外界看到的往往是 AI 五分钟生成了几百行代码开发者看到的却是后面的事情这几百行到底改了什么需求理解对了吗边界条件覆盖了吗会不会破坏旧逻辑测试真的有效吗上线以后出了问题谁负责过去几年AI 编程工具本身也在迅速改变。2021 年 Copilot 的核心还是 IDE 内的行级、函数级补全2023 年 Copilot X 把聊天和 PR 辅助带进开发流程2024 年 Copilot Workspace 开始覆盖规划、构建、测试到 2025 年Claude Code、GitHub Coding Agent、OpenAI Codex 已经能够直接读取仓库、修改多文件、运行测试并提交 PR。2026 年工具又进一步走向并行 Agent、Skills 和更长时间的自主执行。[11]2021Copilot代码补全2023Copilot XChat / PR 辅助2024Workspace规划 → 编码 → 测试2025Claude Code /Codex / CodingAgent多文件自主执行2026多 Agent / Skills并行生产代码开发者进一步转向审查与监督AI 编程工具与开发工作重心的变化真正值得讨论的已经不是“AI 会不会写代码”而是当生产代码的速度突然提高几倍以后我们有没有同步提高验证代码的能力现状今天主流工具已经不只是“代码补全插件”而是在逐渐成为可以行动的工程 Agent。[11]工具主要能力集成程度需要重点防范的问题GitHub Copilot补全、Chat、Agent、Code Review、云端 AgentIDE GitHub CLI语义错误、错误理解需求、安全漏洞、上下文不足。GitHub 官方明确要求人工 review 和 test。1Claude Code阅读仓库、跨文件修改、运行命令、测试、Agent 工作流Terminal IDE Web错误上下文、命令执行风险、Prompt InjectionAnthropic 明确把最终审查责任交给用户。2CursorAgent 搜索代码库、修改多文件、运行终端、自动修错AI 原生 IDE CLI Cloud Agent缺少清晰规格、测试和 lint 等反馈信号时容易跑偏官方最佳实践同样强调先规划和建立可验证目标。3Codex云端并行任务、功能开发、修 Bug、PR、Code ReviewIDE CLI Cloud输出仍需通过测试、日志和 review 验证OpenAI 自己也把“验证”作为独立工程层处理。4这其实意味着软件开发中出现了一种新的流水线过去理解需求 → 写代码 → 调试 → Review → 测试 → 上线现在理解需求 → 描述任务 → AI 大量生成 → 阅读 AI 输出 → 找错误 → 修正 AI → 测试 → Review → 上线中间的“手敲代码”少了但监督、判断、验证的比例上升了。问题分析2026 年一项针对专业软件工程师的纵向研究给这种变化起了一个很准确的名字Supervisory Engineering Work监督型工程工作。82% 的受访者表示自己写代码的时间下降但工作的重点明显从“创造”转向了“指导、评估和纠正 AI 输出”。9这正是很多人产生落差的地方。AI 让“第一版”来得太快于是组织很容易把生成速度误认为交付速度。但是一个 PR 从 50 行变成 500 行并不代表 review 也能快十倍。反过来AI 越容易生成更多代码团队越可能面对更多 diff、更多测试、更多隐藏的上下文错误。Stack Overflow 2024 调查中约 12% 的专业开发者已经直接把“产生更多需要 review 的代码/PR”列为团队使用 AI 的挑战更大的问题则是缺乏代码库上下文和对输出缺乏信任。8GitHub 自己的文档也明确承认Copilot 可能生成“看起来正确”但语义错误、没有真正解决问题甚至存在安全漏洞的代码因此关键应用必须 review 和 test。1 Anthropic 对 Claude Code 的要求同样直接用户需要负责审查拟执行的代码和命令。2所以“AI 都写完了为什么还不能上线”这个问题本身就混淆了两件事代码生成完成 ≠ 软件工程完成。真正昂贵的部分越来越不是“把代码写出来”而是证明这段代码值得被信任。案例下面三个案例是基于实际研发流程和公开研究综合出的典型场景不对应某一家具体公司。案例一一个原本一天的小需求。开发者让 Agent 修改权限模块十分钟后 AI 改完七个文件测试也通过。看起来已经完成 90%。但 review 时发现 AI 复用了一个旧权限判断在普通场景完全正常只有特定角色组合才会越权。最后真正耗时的不是生成代码而是理解 AI 到底改了什么、补测试并重新验证。这类“代码看起来合理但意图理解错误”的风险也是 GitHub 官方明确列出的限制。1案例二AI 让一个人同时开三个任务。每个 Agent 都在后台工作于是表面吞吐量明显提高。但一小时后三个任务同时回来开发者必须连续切换上下文、读三个 diff、回答三个 Agent 的问题。代码生产并行了人的注意力没有并行。2026 年纵向研究恰好观察到类似趋势生产力感知保持较高但 flow state 和 cognitive load 方面的体验出现恶化。9案例三管理层把 AI 效率直接折算成排期。原本三天的需求被认为“有 AI 一天就够”。开发者确实第一天就拿出了可运行版本但验证、联调和回归并没有同比缩短。最后出现的不是“AI 节省两天”而是剩余两天被新的需求填满。这种“产出速度提高后同步提高工作节奏和产出预期”的风险已经进入开发者福祉研究的讨论范围。9研究与数据目前关于 AI 编程效率的研究其实给出了一个非常有意思的答案AI 提效是真的但“提效多少”高度取决于你测量什么。GitHub/Microsoft 2023 年的受控实验发现 Copilot 可让一个标准化 HTTP Server 任务完成时间缩短 55.8%。6 但 METR 2025 年让 16 名资深开发者处理自己长期维护的大型开源项目中的 246 个真实 issue 时AI 组却平均慢 19%而且开发者主观上仍认为自己快了约 20%。METR 特别强调这一结果不能泛化成“AI 对所有开发者都无效”但它很好地说明了主观的“写得很快”和端到端实际工时并不是一回事。5DORA 的数据则进一步提醒管理者AI 使用与个人生产力提升可以同时存在但组织级软件交付未必同步改善。其报告发现AI 使用增加与 delivery throughput 和 stability 下降存在关联并认为更大的代码批次和 review 压力可能是原因之一。DORA 因而特别强调自动化测试、持续集成和快速反馈回路。7心理层面的信号也开始出现。一项覆盖 442 名开发者的研究发现GenAI 的使用可能通过增加 job demands 与 burnout 建立联系而足够的工作资源、支持和正向使用体验能够缓和这种关系。10 另一项 2026 年纵向研究则发现84% 受访者持续认为 AI 提升了生产力但在匹配样本中至少一个开发体验维度恶化的人群比例从 14% 增至 27%。9换句话说“我产出得更多”与“我工作得更舒服”完全可能同时朝相反方向发展。对策建议真正有效的做法不是要求开发者“多学几个 Prompt”而是把整个研发流程重新设计成适合 AI 高吞吐量的系统。首先排期不能按生成代码的速度估算而应该按可验证交付的速度估算。需求分析、Review、QA、回归、灰度和生产观察仍然应该进入估时所谓 SLA 也应该区分“AI 首版时间”“进入测试时间”和“可安全上线时间”不能把三者混成一个指标。DORA 同样建议组织强化测试和快速反馈而不是只追求生成速度。7其次限制 AI 一次产生的变更规模。一个 100 行、目标清晰、测试明确的 Agent PR通常比一个横跨二十个文件的“自动重构”更容易验证。GitHub Cloud Agent 本身也建议复杂任务拆成更小、更聚焦的任务Cursor 的官方实践则强调先建立计划、测试、类型检查和 lint让 Agent 获得明确的成功信号。[1,3]再次不要让写代码的 AI 自己成为唯一的审查者。可以使用第二模型做 Code Review、静态扫描、单测、集成测试、SAST 和依赖检查把“验证”也自动化但最终仍应保留责任人。OpenAI 的实践很有启发性它甚至把代码生成和代码审查视为两个不同的优化问题并明确警告“clean review”不能被当成安全保证。4最后是最容易被忽略的一点给开发者正式的 AI 学习时间而不是默认“工具给你了你自然就应该更快”。DORA 的组织研究发现在工作时间内提供专门学习时间与更高的团队 AI 采用率相关而把学习压力转嫁到个人时间更容易带来挫败和 burnout。7因此团队真正应该衡量的不只是“AI 写了多少代码”而是从 issue 到 PR 的周期、AI PR 返工次数、review feedback cycles、测试覆盖变化、线上缺陷率和回滚率。GitHub 自己在 Copilot 最佳实践中也建议围绕 issue-to-PR、迭代次数、review 周期和测试改善来衡量效率。1结论我并不反对 AI 编程。恰恰相反我现在越来越难想象完全不用 AI 写代码的工作方式。但我反感的是另一种逻辑“AI 都能写代码了所以开发应该很简单。”AI 确实让生成代码变得越来越简单。2026 年的研究甚至已经观察到软件工程价值正在从 routine coding 向 specification quality、architecture reasoning 和 oversight 转移。9可需求不会因为 Claude Code 出现就自动变清晰系统不会因为 Copilot 写得快就自动变稳定生产事故也不会因为代码是 AI 生成的就由 AI 承担责任。所以未来程序员最重要的能力也许真的会发生变化。以前我们花大量时间证明“我能把代码写出来。”以后我们可能要花更多时间证明“我知道什么应该让 AI 写我知道它哪里可能错而且我有能力为最终结果负责。”AI 降低了代码的生产成本。但在一个代码越来越廉价的时代判断、验证和责任反而会越来越贵。[9,10]参考资料1 GitHub.GitHub Copilot 文档能力、使用限制与人工 Review / 测试要求.GitHub Docs. https://docs.github.com/en/copilot2 Anthropic.Claude Code 文档用户需负责审查拟执行代码与命令.https://docs.anthropic.com/en/docs/claude-code3 Cursor.Cursor 文档与最佳实践先规划、建立可验证目标、测试与 lint 反馈.https://docs.cursor.com4 OpenAI.Codex 文档将“验证”作为独立工程层“clean review” 不能作为安全保证.https://openai.com/index/codex5 Becker, J., Rush, N., Barnes, E., Rein, D. (METR).Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.2025. https://metr.org/blog/2025-07-10-early-2025-AI-experienced-os-dev-study6 Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M.The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.arXiv:2302.06590 (2023). https://doi.org/10.48550/arXiv.2302.065907 DORA (Google Cloud).2024 Accelerate State of DevOps Report与2025 State of AI-Assisted Software Development Report.https://dora.dev8 Stack Overflow.2024 Developer SurveyAI/ML 洞察采用挑战与信任问题.https://stackoverflow.co/labs/2024-developer-survey-insights-for-ai-ml9 Vella, A., Blincoe, K.The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study.2026提出“监督型工程工作 / Supervisory Engineering Work”82% 写代码时间下降84% 感知生产力提升但匹配样本中 27% 体验恶化价值向规格质量 / 架构推理 / 监督转移. arXiv: https://arxiv.org/abs/2605.2313510 IEEE/ACM ICSE 2026 研究n442 名开发者PLS-SEMGenAI 采用通过提升 job demands 增加 burnoutβ0.398, p.001自主性 / 学习机会等工作资源可显著缓和β-0.360, p.001. arXiv: https://arxiv.org/abs/2510.07435DOI: 10.1145/3786581.3786934[11] AI 编程工具演进综述Copilot2021 补全 → 2025 Coding Agent、Claude Code / Cursor / Codex 多文件自主执行、2026 并行 Agent 与 Skills。综合自 1–4 各工具官方发布与文档。
返回列表