
Claude含AI量超Cursor一倍!资深工程主管揭秘AI编码真相!谷歌谨慎全搞自研 原创
编辑 | 伊风
出品 | 51CTO技术栈(微信号:blog51cto)
这应该是我听过最扎实、最客观的一场 AI 编程演讲。
它不讲“奇迹”,也不兜售“焦虑”。而是抛出一个很实在的问题:
“今天我们能不能做一次现实核查:
那些极度乐观的 AI 编程预言,靠谱吗?还是现实中根本没那么神?”
微软 CEO 说:‘30% 的代码都是由 AI 编写的’;
Authoropic 的 CEO 几个月前声称,‘一年之内所有代码都会由 AI 生成’;
但为啥这和工程师跑起来的感觉不一样?
怎么有初创公司的人用了Devin,不仅没提效,还出了bug倒亏了 700 美元的事故成本?
这场演讲来自 Gergely Orosz —— 曾任 Uber 技术主管、后来转型为全职技术作者。
他写的《The Tech Resume Inside Out》一度被称为“程序员简历圣经”,如今则靠着 The Pragmatic Engineer 这一全球最火工程类 Newsletter,持续影响着数十万技术人。
图片
为了回答上面的问题,他花了两个月,采访了 AI DevTools 初创团队、大厂内部工程师、AI 生物创业公司和一群“热爱代码本身”的独立开发者。最终拼出了一份关于 AI 编程真实状态 的多维画像。
先来说个初步结论给大家:
- AI DevTools 初创公司:重度使用(不意外);
- 大厂:投入巨大,使用率持续上升;
- AI 创业公司:使用情况不稳定,有的有效、有的无感;
- 独立开发者:比以前更兴奋、更愿意用。
最令人意外的是一位真正的“老程序员”——Kent Beck(是的,就是《Extreme Programming》作者),他是第四类人的一个代表:
“我现在写代码,比过去 52 年任何时候都开心。” ——Kent Beck今年是第 52 年写代码了。
AI 让他终于能动手做自己一直想做但觉得“太复杂、太贵”的项目,比如用 Smalltalk 写一个并行计算服务器。他说:
“技术栈中‘什么便宜、什么昂贵’的格局正在被重写,很多过去被我们放弃的事情,现在其实便宜得令人发笑。”
小编将这篇干货满满的演讲,梳理成了好读、有料的文章,接下来你将读到:
- AI DevTools 初创公司:9成代码AI生成,成千上万个 MCP请求一起跑!
- Google 和 Amazon:怎么将 LLM 集成进开发工具?
- AI 初创公司:Claude Code、Cursor、Windsurf 等开发者怎么用?
- 独立开发者:谁在“彻底转变”、谁在“理智观察”?
- 最后是他留下的 4 个反思性问题,每一个都戳中真实工程场景。
一、Claude Code、Windsurf 9成已是AI代码,Cursor仅为前者一半
首先是 AI DevTools 初创公司。
我上周刚和 Anthropic 团队聊过,问他们最近在内部观察到什么趋势。虽然这些公司难免会有些“自带滤镜”,但他们的回答还挺值得一听的。
他们说,当第一次在内部开放 Claude Code 给工程师使用时,几乎所有人都立即开始每天使用,而且热情持续到现在。这种“自然启动”让他们自己也有点意外。
要知道,当时这还只是内部版本。Claude Code 直到一个月前才对外发布,它其实不是 IDE,而是一个命令行工具(CLI),运行在终端里。
他们还告诉我,目前 Claude Code 这个产品本身,有 90% 的代码就是用 Claude Code 写的。这个数字听起来非常夸张,甚至像广告词。但我也专门和工程师确认过——他们不像市场部门那样会“演”,所以这个说法还是挺可信的。
他们还提到一个很有意思的数据:Claude Code 正式上线后第一天,使用量就暴涨了 40%;三周不到,涨幅已经达到 160%。不论原因是什么,这说明这个工具的确有吸引力。
此外,Anthropic 还启动了一个叫 MCP(Model Context Protocol) 的项目。他们的目标是用一个协议,把 IDE 或 Agent 接入到开发者已有的上下文环境中,比如数据库、GitHub、Google Drive、Puppet 等。
我自己也动手试了一下,连上了自己的一个 API 数据源,然后直接问它:“有多少人领取了某个优惠码?”它自动生成 SQL 查询,结果也挺靠谱。这种“自然语言连数据”的体验,确实让人眼前一亮。
据他们说,MCP 是在去年 11 月开源的。到今年年初,有几家中型公司开始采用。然后在 3 月、4 月,连 OpenAI、Google、Microsoft 这些“大玩家”也加入了对 MCP 的支持。
现在,每天都有成千上万条 MCP 请求在运行,后面演讲中还会提到它为何重要。
除了 Claude,我还和另外两个 AI IDE 团队聊了聊:
- Windsurf:他们说目前团队中 95% 的代码都是用 Windsurf 的 Agent 或自动补全生成的;
- Cursor:给出的估算是 40% 到 50% 的代码使用了 AI。虽然比不上前面两个,但他们也坦言:有些地方确实有用,有些还不太行。
我很欣赏 Cursor 的坦诚。毕竟这些公司做的就是 AI 编程工具,谁都想把“AI使用率”尽量做到 100%,那可是卖点。但 Cursor 没藏着掖着,这就已经很难得了。
二、Google:“谨慎而长期主义”,所有AI工具都是自研
我和 Google 的几位工程师匿名聊了聊,大概五个人。首先要知道的是:Google 的所有工程系统几乎都是自研的。
- 不用 Kubernetes,而是内部自研的 Borg;
- 不用 GitHub,用的是自己的代码仓库系统;
- 不用公开的 Code Review 工具,而是用内部工具 Critique;
- 他们的 IDE 是自研系统 Cider(全称:Integrated Development Environment and Repository)。
Cider 最初是网页工具,现在已经演变为一个基于 VS Code 的定制分支,与 Google 的内部基础设施高度集成,开发体验非常顺滑,打通程度很高。
工程师告诉我,现在 AI 工具几乎无处不在。
在 Google 内部,他们已经将大模型集成进自己的 IDE「Cider」中。Cider 是基于 VS Code 的一个定制分支,还有一个网页版叫 Cider V,里面集成了自动补全、基于对话的 IDE。他们说使用体验还不错,虽然可能比不上 Cursor,但总体表现已经相当可以。在代码评审工具 Critique 中,AI 也能给出审查反馈,评价是“很合理,能用”。
再比如代码搜索,这是 Google 内部非常强大的工具,现在也已经集成了 LLM 支持。你可以问它一些问题,它会帮你定位相关代码部分。而就在一年前,这些功能在 Google 内部几乎没人用。但半年内一切都变了。
一位现任 Google 工程师告诉我,Google 内部推行 AI 工具的方式是非常“谨慎而长期主义”的。他们希望这些工具能真正被工程师信任、持续使用。
此外,还有不少只面向 Google 内部的工具,比如:
- Notebook LM:你可以上传文档、和它对话;
- Prompt Playground:有点像 OpenAI 的 Playground,但其实 Google 在 OpenAI 发布之前就已经做出来了;
- Moma:一个基于 LLM 的知识检索系统,在 Google 工程师中广泛使用。
我听一位 Googler(不便透露姓名)说,现在每个 org(组织)都在搞属于自己的 GenAI 工具,原因很简单:领导层希望看到这种创新,而且这么做更容易拿到内部资源和预算支持。像 Notebook LM 这样的工具,就是靠“某个团队拉到预算就自己搞起来”的。
不过让我印象最深的,是一位前 SRE 告诉我——他和很多 Google 的 SRE 还保持联系——现在 Google 的基础设施团队正在为“10 倍代码量”的增长做准备。他们在升级部署流水线、代码审查工具、功能开关机制等等。
这让我非常好奇:Google 是不是已经看到了某些我们还没意识到的趋势?
三、Amazon:采用AI比谷歌激进,但相当低调
谈起 AI 工具,大多数人第一反应不会想到 Amazon。
虽然外界对 Amazon 的 AI 能力印象不深,但我跟内部工程师聊下来发现,几乎所有开发者都在用一个叫 Amazon Q Developer Pro 的工具。它对 AWS 相关任务非常好用。
让我惊讶的是,Amazon 内部的人很疑惑,为什么外界对这个工具几乎一无所知?他们表示,“只要你是做 AWS 的,这个工具的上下文理解能力就特别棒。”
大概半年前,我听他们说这个工具“不太行”;但现在,很多人都说:“真的很好用了。”
他们还告诉我,现在写 Amazon 的 PR FAQ(六页文案、模拟新闻稿的那种),也会用 AI 工具。年中绩效季,很多写作任务也用它来加速。
Amazon 和 Anthropic 有合作关系,他们有一个内部版本的 Claude。
关于 Amazon,我觉得最有趣的是 MCP(Model Context Protocol)在内部的推进。
Anthropic 最早提出 MCP,现在 Amazon 似乎在全面接入。
稍微讲讲背景:Amazon 是个“API 驱动”的公司,早在 2002 年,Jeff Bezos 发出著名命令:
“所有团队必须通过服务接口(API)暴露功能和数据,不得使用内部通信,违者将被开除。”
这也是 AWS 能诞生的底层原因。他们的所有服务都可以通过 API 公开,因此现在只需要在 API 上“外挂”一个 MCP server,AI Agent 就能直接对接调用,非常轻松。
我从某位 Amazon 员工那里得知,目前 Amazon 内部的大多数工具和网站已经支持 MCP,这应该是第一次被公开提到。
自动化在 Amazon 内部随处可见。我听说很多人正在用 AI 工具自动处理工单系统、邮件、内部流程等等,有些工程师甚至已经自动化了大部分工作流。
虽然外界没人讨论这些,但它确实正在发生。Amazon 作为“API First”公司,现在可能也正悄悄成为“MCP First”的引领者,时间点就在 2025。
四、初创公司的两极分化:有人爱疯了,有人说“不如手写”
我还和一些小型初创公司聊了聊。它们并不是做 AI 工具起家的,但在日常流程中逐步开始集成 AI —— 有的甚至已经转向“AI 优先”的方向。
1.支持者 Incident IO:整个团队都在用,形成浓厚的“知识共创”氛围
Incident IO,本来是一家做 on-call 报警平台的公司。它本来是做 on-call 平台的,但 AI 明显是很适合用来做报警、排查和解决方案推理的。所以他们逐步变成了 AI 优先的公司。
我采访了联合创始人 Lawrence Jones(他也是这次大会的讲者),他告诉我:
整个团队都在大规模使用 AI 来提效,还会在 Slack 中分享使用技巧、最佳实践,一种“知识共创”的氛围已经形成。
一些具体例子很有代表性:
- 有人尝试用另一台 MCP server 来处理一张复杂的工单,结果 AI 给出的初稿非常靠谱;
- 他把这个经验发到群里,其他人纷纷试用,讨论 prompt 设计和生成逻辑;
- 还有人发现了一个“提示词新玩法”:让 AI 给出 3~5 个不同代码方案,再追问“为什么这样写、换个思路会怎样”。
Lawrence 表示最关键的转折点是 Claude Code 上线后的三周。
他查了一下数据(当时是周日),发现整个团队都已经在日常使用它了。没有任何品牌赞助,只是纯粹觉得Claude太好用了。
2.弃用者 某AI 生物初创公司:最新的模型也满足不了需求,领域太小众了?
这家公司大概成立三年了,团队规模在 50 到 100 人之间,整个系统架构很现代:基于 Kubernetes 的自动化数值管道、Python、Hugging Face 等技术。
他们的工程师对我说: “我们试过很多 LLMs,但没有一个能真正用起来。因为我们手动写出正确代码,其实比修改 AI 写的代码还要快得多 —— 即便是用最新模型,比如 Claude 3.7、甚至 Claude 4,还是这样。”
他们觉得自己的领域可能太小众,不适合让 LLMs 发挥作用。
这位工程师也坦言,不愿意公开名字,是因为他们不想被贴上“AI怀疑者”的标签——但这是实话。
他们是一家节奏很快的初创公司,尝试过各种 AI 工具(包括代码审查助手),但最终发现这些工具不适用于他们开发的新型复杂软件。他们不是不试,而是试了发现不行,就迅速换方向了。
五、“从未如此兴奋!”——独立开发者与老程序员如何评价 AI 编码?
聊完初创公司,我也采访了几位独立软件工程师,他们在 AI 时代之前就已经非常厉害了,对“写代码”这件事有深深的热爱。
1、Flask 作者 Armin:我现在更想当 AI 智能体工程师
Armin Ronacher,Python Web 框架 Flask 的作者,十几年来一直是个“纯写代码”的技术人。他最近离开了 Sentry,准备自己创业。
最近他发布了一篇文章,标题是:《AI 改变了一切》。他说了一句非常颠覆性的话:
“如果你在六个月前告诉我,我会更愿意做一名‘AI 智能体工程师’而不是亲自编码,我肯定不会相信。”
他的转变有三个原因:
- Claude Code 用起来真的很顺;
- 自己在密集使用 LLMs 之后,终于“突破了心理障碍”,开始接受 AI 合作模式;
- 最关键:agent 能自动执行、观察反馈,这种机制可以极大地降低‘幻觉错误’的影响。
2、iOS 工具作者 Peter:我又找回了“写代码的热情”
Peter Steinberger 是 PSPDFKit 的作者,iOS 最流行的 PDF SDK 创始人。他把公司卖掉后一直在探索新技术,最近发了一篇文章,标题就叫:
“The Spark Returns(热情回来了)”
他说他感受到一个转折点到来了:语言和框架不再重要,AI 工具让他轻松从 Objective-C 转到 TypeScript,写什么都行。工具层的解耦能力太强了,生产效率暴涨。
他还跟我分享了一个他发在社交平台的段子: “很多技术人都因为玩 AI 工具兴奋到睡不着。”
有趣的是,我们是在凌晨 5 点互发消息的,我因为别的事早醒,他因为写代码根本没睡。
3、ThoughtWorks 的 Brigita:LLM 是技术栈的“横向力量”
Brigita是ThoughtWorks的Distinguished Engineer,她这样总结 LLM 的意义:LLMs 是极少数可以在任意抽象层使用的工具。
你可以把它当作汇编级别的 low code 工具,也可以用来操控高级语言,甚至用自然语言编程。 这不是简单地‘加一层 AI’,而是在整个技术栈中横向渗透的东西。
正是这种“跨层抽象使用能力”,让 LLMs 真正令人兴奋。说这话的人,本身也是在 AI 出现之前就已功成名就的资深工程师。
4、Django 联合创始人 Simon:真正的突破刚刚开始
Simon Willison 是 Django 框架的联合创始人,靠写博客和开源维生,被 Andrej Karpathy 称为“LLM 博客必读作者”。
他说:
“代码agent确实可以跑得通,可以反复循环、调试编译器、干实事。 过去 6 个月,大模型的迭代明显突破了一道门槛,现在开始真的‘有用’了。”
5、Kent Beck:52 年码农生涯,现在写得最开心!
最后是重量级嘉宾:Kent Beck,极限编程(XP)之父,JUnit 作者,软件工程界的活传奇。
他说:
“我现在编程比过去 52 年任何时候都开心。”
他正在用 Smalltalk 写一个并行虚拟服务器的项目 —— 是他多年来的梦想。
他说 LLM 的出现让他终于可以专注做自己真正想做的事,不用被工具框架牵着走。
在他眼中,LLM 是继微处理器、互联网、智能手机之后,又一次彻底改变成本结构的技术浪潮:
“过去我们因为贵、不现实而不做的事,现在突然变得便宜又容易。”
延伸:值得思考的四个问题
这些趋势很有意思,但我认为现在仍然谈不上“AI 已彻底改变软件开发”。它远不是那种“板上钉钉、未来已来”的故事。
所以我自己也留了 4 个问题:
❓问题一:为什么创始人和 CEO 远比工程师更兴奋?
虽然有一些工程师确实很激动,比如 Armin 和 Peter,他们本身就可能是创业型人才。但比如 Warp 的创始人 Zack Lloyd 就问得很到位:
“有没有人注意到,最资深的工程师往往不怎么用 AI,最热情的反而是创始人和产品经理?”
这可是一个做 AI 工具终端的创始人在反思。
再看那些 CEO 公开发言,几乎都在极力宣传 AI 的潜力。这值得我们思考。
❓问题二:AI 工具的使用在开发者中到底有多主流?
我让现场举手:“每周至少用一次 AI 工具写代码的有多少人?”
现场大约有 60–70% 的人举手。
这和 DX 的调研数据相符。他们最近调查了 3.8 万名开发者,结果是:
- 一个典型组织中,大约 一半人每周使用 AI 工具;
- 最头部的公司能达到六成。
但请注意,我演讲里讲的大多数例子,其实都高于这个中位数(除了那个 AI 生物初创公司)。
也可能有样本偏差——愿意分享经验的人,本来就更愿意使用 AI。
❓问题三:我们到底节省了多少时间?
比如 Pete 告诉我,他感觉自己产出效率提升了 10–20 倍。
但 DX 的调研显示,AI 工具一周大约能帮开发者节省 3–5 小时,平均大概 4 小时。
4 小时也不赖,但要说“10 倍提效”就显得有点夸张了。问题是:我们真的把省下来的时间用来创造更多价值了吗?
我也不知道。
❓问题四:为什么 AI 对个人开发者特别有效,而对团队却效果不佳?
这个现象非常普遍。DX 的 Laura Tacho 也告诉我,AI 工具在“个体层面”表现不错,但在“组织层面”尚未发挥价值。
CEO 和创始人如此热情,不难理解,毕竟他们公司押注 AI,也有财务压力在身上。
大厂积极投资、探索 AI 工具,也说得通。
但最让我在意的是那些“有年头”的资深开发者,他们是真的用出了成果、感受到了变化、愿意投入更多。
我觉得我们可能正处在一个软件开发方式的“台阶式变革”时刻。
我联系了软件工程思想领袖 Martin Fowler,请他为我审阅的一篇文章给点看法。他的回答是:
“LLMs 将对软件开发产生的影响,堪比当年从汇编语言转向高级语言的变革。
后来各种高级语言的更新,虽然改进了生产力,但没有那种‘质变’了。
但 LLM 是不同的:它是计算机历史上第一次引入“非确定性”的工具,这非常关键。”
结语
我的结论是:变化正在发生,我们需要更大胆地去实验。
我们应该像初创公司那样多试错,弄清楚:
- 什么是有效的?
- 什么是没用的?
- 什么是真的便宜了?
- 什么才是真正值得投资的?
这场演讲到这里也告一段落,内容之扎实、视角之多元,令人回味。
你对演讲中的这些观察有没有共鸣?
AI 写代码对你来说,是赋能,还是添乱?欢迎在评论区聊聊你的真实感受
本文转载自51CTO技术栈,作者:伊风
