2025年的LLM软件工程：现实检验

来源：https://newsletter.pragmaticengineer.com/p/software-engineering-with-llms-in-2025

大家好——我是Gergely，这是Pragmatic Engineer Newsletter的每月免费刊。每一期，我都从工程经理和高级工程师的视角，探讨大厂和初创公司面临的挑战。如果这封邮件是别人转发给你的，你可以在这里订阅（https://newsletter.pragmaticengineer.com/about）。

两周前，我在伦敦LDX3大会上发表了主题演讲“用GenAI做软件工程“（https://leaddev.com/leaddev-london/agenda/）。在此之前的几周里，我与Anthropic和Cursor等领先AI公司的软件工程师、大厂（Google、Amazon）的工程师、AI初创公司的工程师，以及多位资深软件工程师进行了交流，以了解各团队如何使用各种AI工具，以及哪些趋势最为突出。

如果你有25分钟的空闲时间，可以看看刚发布在我YouTube频道上的剪辑版视频（https://www.youtube.com/watch?v=EO3_qN_Ynsk）。特别感谢LDX3大会主办方（https://leaddev.com/leaddev-london/agenda/）出色的视频制作，以及组织了一场出色的活动——包括现场播客录制（明天发布）和《The Software Engineer’s Guidebook》（https://www.engguidebook.com/）的签售会。

观看主题演讲录像（https://youtu.be/EO3_qN_Ynsk）

我在伦敦LDX3大会上的主题演讲

本文涵盖以下内容：

1. **两个极端。**AI基础设施公司的高管们大胆宣称，而开发者们常常发现这些说法惨遭打脸。
2. **AI开发工具初创公司。**来自Anthropic、Anysphere和Codeium的细节，介绍他们的工程师如何使用Claude Code、Cursor和Windsurf。
3. **大厂。**Google和Amazon如何使用这些工具，包括这家电商巨头如何悄然成为一家MCP优先的公司。
4. **AI初创公司。**值班管理初创公司incident.io和一家生物技术AI公司，分享他们如何试用AI工具。有些工具留了下来，有些则令人失望。
5. **资深软件工程师。**来自经验丰富的程序员的观察：Armin Ronacher（Flask创建者）、Peter Steinberger（PSPDFKit创始人）、Birgitta Böckeler（Thoughtworks杰出工程师）、Simon Willison（Django创建者）、Kent Beck（XP创建者）以及Martin Fowler（Thoughtworks首席技术专家）。
6. **未解问题。**为什么创始人/CEO比开发者对AI工具更乐观？开发者中的使用普及程度如何？AI工具到底节省了多少时间？等等。

本文底部可能在某些邮件客户端中被截断。请在线阅读完整文章。（https://newsletter.pragmaticengineer.com/p/software-engineering-with-llms-in-2025）

在线阅读完整文章（https://newsletter.pragmaticengineer.com/p/software-engineering-with-llms-in-2025）

关于LLM和AI将改变软件工程——或者已经改变了——的预测层出不穷。让我们看看两个极端。

**看多一方：AI高管。**这些头条新闻来自在AI赛道上有利益的公司：

• “Anthropic CEO表示一年内所有代码都将由AI生成。”（Inc Magazine（https://www.inc.com/joe-procopio/anthropics-ceo-said-all-code-will-be-ai-generated-in-a-year/91163367），2025年3月）
• “Microsoft CEO透露AI编写了其30%的代码——有些项目可能全部代码都由AI编写”（Tom’s Hardware（https://www.tomshardware.com/tech-industry/artificial-intelligence/microsofts-ceo-reveals-that-ai-writes-up-to-30-percent-of-its-code-some-projects-may-have-all-of-its-code-written-by-ai），2025年4月）
• “Google首席科学家预测AI可能在一年内达到初级程序员的水平”（Business Insider（https://tech.yahoo.com/ai/articles/google-chief-scientist-predicts-ai-084702595.html），2025年5月）

这些是对信心和成功的宣言——作为科技从业者，后两条可能会让一些软件工程师心生忧虑，担心饭碗不保。但值得注意的是，说这些话的人是谁：有AI产品要卖的公司。它们当然要吹捧自家产品的能力。

**看空一方：失望的开发者。**关于AI工具没那么神的两个有趣案例：第一个发生在一月，编程工具Devin生成了一个bug，导致一个团队因生成数百万条PostHog（https://posthog.com/）分析事件而多花了733美元：

虽然责任在于开发者未经仔细检查就接受了代码提交，但如果AI工具的输出不可靠，那它显然远远没有到能取代软件工程师工作的程度。

另一个案例是GitHub Copilot Agent的公开预览，那些对科技高管关于超高生产力AI的说法不完全买账的人自嘲为幸灾乐祸地看着Agent在.NET代码库（https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my_new_hobby_watching_ai_slowly_drive_microsoft/）中屡屡碰壁。

其中的失误包括Agent添加了失败的测试，微软的软件工程师不得不让Agent重新开始：

微软值得称赞的是没有隐瞒其Agent遇到的问题：.NET仓库中有几个由Agent发起的pull request因工程师对AI的输出失去信心而被关闭。

我们在深度报道《微软在自家产品上试用AI开发工具的未来》中对此事件有更多介绍（https://newsletter.pragmaticengineer.com/i/164565996/dogfood-that%27s-not-tasty-copilot-agent-fumbles-in-real-world-with-net）。

那么，在看多的科技高管和不以为然的开发者之间，真相是什么？为了了解更多细节，我联系了各种类型公司的工程师，询问他们现在如何使用AI工具。以下是我在了解到的情况……

要说哪里最容易找到大量在工作中使用AI工具的开发者，那莫过于为专业人士打造工具并自食其力的AI工具公司了。

Anthropic团队告诉我：

“当我们把Claude Code提供给工程师和研究员时，他们所有人都开始每天使用它，这相当出人意料。”

如今，Anthropic首席产品官Mike Krieger表示，Claude Code自身**90%**的代码是由Claude Code编写的（！）。自5月22日——Claude Sonnet 4和Claude Code的发布日——以来，使用量大幅上升：

• 40%：Claude Sonnet 4发布当天Claude Code使用量的增长幅度
• 160%：发布后一个月内用户群的增长

这些数字表明Claude Code和Claude Sonnet 4在开发者中大受欢迎。Claude Code的创建者Boris Cherny在Latent Space播客（https://www.latent.space/p/claude-code）上说：

“就我个人而言，它大概让我的生产力翻了一番。我认为Anthropic有些工程师的生产力可能因此提高了10倍。”

MCP（Model Context Protocol）由Anthropic于2024年11月创建。它的工作原理如下：

MCP正在整个行业中获得越来越广泛的采用：

• 2024年11月：Anthropic开源MCP（https://www.anthropic.com/news/model-context-protocol）
• 2024年12月–2025年2月：Block、Replit、Windsurf和Sourcegraph采用该协议
• 3月、4月：OpenAI、Google、Microsoft也纷纷采用
• 如今：数千个活跃的MCP服务器在运行，采用还在继续

我们在《MCP协议：AI开发工具的新构建模块》中对这一协议及其重要性有更多介绍（https://newsletter.pragmaticengineer.com/p/mcp）。

当被问及他们如何使用自己的产品来开发Windsurf时，团队告诉我：

“**约95%**的代码是使用Windsurf的Agent Cascade和被动编码功能Windsurf Tab编写的。”

公司的一些非工程师也在使用Windsurf。合作伙伴关系负责人Gardner Johnson用它（https://www.youtube.com/watch?feature=shared&v=BjzpSLtVwU4）搭建了自己的报价系统，并替换了一个现有的B2B供应商。

我们之前曾与Windsurf CEO Varun Mohan一起探讨过Windsurf是如何构建的（https://newsletter.pragmaticengineer.com/p/building-windsurf-with-varun-mohan）。

当被问及时，Cursor的工程团队估计，Cursor约**40–50%**的代码是由Cursor生成的输出编写的。虽然这个数字低于Claude Code和Windsurf，但仍然相当高。当然，公司里每个人都在使用Cursor，每天都在用。

我们在《真实的工程挑战：构建Cursor》中对Cursor的构建方式有更多介绍（https://newsletter.pragmaticengineer.com/p/cursor）。

在与AI开发工具初创公司交流之后，我转向了Google和Amazon的工程师。

通过与这家搜索巨头的五位工程师交流，我发现，在开发者工具方面，所有东西都是内部自研的。例如：

• Borg：Google版的Kubernetes。它比Kubernetes出现得更早，而Kubernetes正是由Google工程师基于Borg的经验构建的。我们在与Kat Cosgrove探讨Kubernetes的历史时有更多介绍（https://newsletter.pragmaticengineer.com/p/how-kubernetes-is-built-with-kat）。
• Cider：Google版的IDE。最初是一个基于Web的编辑器。后来创建了一个VS Code的分支（称为Cider-v）。如今，这个VS Code版本是“主要“版本，简称为“Cider“。
• Critique：GitHub代码审查的内部替代品
• Code Search：内部版的Sourcegraph，Code Search比Sourcegraph出现得更早。Sourcegraph受到了Code Search的启发。我们之前介绍过Sourcegraph的工程文化（https://newsletter.pragmaticengineer.com/p/inside-sourcegraphs-engineering-culture）。

Google之所以“一切自研“，是因为这些工具之间紧密集成。在所有大厂中，Google拥有最出色的开发工具链：所有工具之间都能协同工作，由于深度集成，Google在所有这些工具中加入AI功能也就不足为奇了：

• Cider：多行代码补全——在IDE内与LLM对话进行提示——由Gemini驱动——正如一位现任工程师告诉我的：“Cider可以建议CL描述（changelist——Google版的pull request）、代码审查的AI建议、AI自动补全。它有类似Cursor的聊天界面，但用户体验不如Cursor。”
• Critique：AI代码审查建议
• Code Search：也集成了AI

一位工程师告诉我，Google在开发者工具方面似乎采取“缓慢而稳健“的策略：

“总体而言，Google在这里采取了非常谨慎的方法来建立信任。他们肯定希望第一次就做对，让软件工程师（SWE）能够信任这些工具。”

其他常用工具：

• Gemini：Gemini App和Workspace中的Gemini功能通常在内部进行试用，并且对工程师提供无限使用额度
• LLM提示词实验场：与OpenAI的开发者实验场非常类似，且出现得更早
• 内部LLM使用：各种Gemini模型可供内部使用：大的和小的、指令调优的、更有创意的、思考模型和实验性模型等
• MOMA搜索引擎：使用LLM的知识库。这是一个用Google内部知识微调的聊天机器人。底层模型基于某个版本的Gemini模型，但它的功能相当基础：回答直接问题。开发者告诉我MOMA很有前景，但没有一些人期望的那么有用，可能是因为它严重依赖内部文档。例如，如果一个团队的服务文档很差、缺少参考信息，模型就无法很好地回答相关问题。而且由于Google的所有服务都是自研的，通用模型知识也帮不上忙（比如，关于Kubernetes的知识不一定适用于Borg！）
• NotebookLM：被大量使用。一个用例是将所有产品需求文档/用户体验研究文档导入，然后就内容提问。NotebookLM（https://notebooklm.google.com/）是一个公开可用的产品。

**Google持续投资“内部AI孤岛“。**一位现任软件工程师告诉我：

“到处都在进行各种组织特定和团队特定的GenAI工具项目。因为如今领导层就爱看到这些！往坏了说：发起一个AI项目是如今获得更多资金的方式之一。至于这些工具是否有效，谁知道呢！”

我想补充的是，Google在整个组织范围内资助AI计划的策略乍看之下可能显得浪费，但NotebookLM等成功产品正是这样诞生的。Google有足够多的资源资助数百个项目，并在那些获得关注或可能产生可观收入的项目上继续加大投入。

**Google正在为10倍的代码交付量做准备。**一位前Google网站可靠性工程师（SRE）告诉我：

“我从SRE朋友那里听说的是，他们正在为10倍的代码量进入生产环境做准备。”

如果哪家公司掌握着AI工具可能带来的影响的数据，那就是Google。生成的代码量增加10倍，很可能也意味着以下方面增加10倍：

• 代码审查
• 部署
• Feature flags
• 源代码管理规模
• ……也许还有bug和故障——如果不谨慎处理的话

我与公司里的六位现任软件开发工程师（SDE）进行了交流，了解他们使用的工具。

Amazon Q Developer是Amazon自家的GitHub Copilot。每位开发者都可以免费使用Pro层级，公司大力鼓励使用。Amazon的领导层和首席工程师不断提醒大家使用这个工具。

据我了解，这个工具大约两年前发布时表现平平，因为它只使用Amazon自研的模型Nova（https://newsletter.pragmaticengineer.com/i/155552919/amazons-ai-models-fail-to-impress）。Nova表现平平，意味着Q也不怎么样。

今年四月，情况变了：Q摆脱了对Nova的依赖，变得好了非常多。我交流过的开发者中，约有一半现在非常喜欢新版Q；它在AWS相关任务上表现出色，在处理Amazon代码库方面也优于其他模型。这是因为Amazon也在自己的代码库上训练了几个内部LLM，Q可以使用这些定制模型。其他印象：

• **仅限单文件。**Amazon Q目前一次只能理解一个文件——这是SDE们需要想办法绕过的限制。
• **与Java配合良好。**如果Amazon运行在一种语言上，那就是Java，所以这是一个很好的契合。
• **微调模型只是略好一点。**令人惊讶的是，即使是经过Amazon代码库训练的模型，感觉也只是比未训练的模型稍微好一些。
• **连接到Bedrock的Cline是热门替代方案：**许多SDE更喜欢使用连接到AWS Bedrock的Cline，在上面运行模型（通常是Sonnet 4）
• **Q CLI：**命令行界面（CLI）在内部迅速走红，因为该工具使用AWS CLI，能够直接连接到MCP服务器——Amazon已有数百个MCP服务器（下文讨论）
• Q Transform：内部用于平台迁移，从一个语言版本（如Java 8）迁移到另一个版本（如Java 11）。工程师们说它仍是有好有坏：对某些内部服务效果很好，对其他则不然。Q Transform是公开可用的产品（https://aws.amazon.com/q/developer/transform/）。

Amazon Q是一个公开可用的产品，到目前为止，我收集到的反馈