I recently delivered the keynote at the LDX3 engineering leadership conference in New York, attended by 2,000+ engineering leaders, CTOs, Director+ and Staff+ engineering folks, in which I attempted to create a snapshot of where the tech industry is at this exact point.我最近在纽约举行的 LDX3 工程领导力大会上发表了主题演讲，现场有超过 2000 名工程主管、CTO、总监级及资深工程师参加。在演讲中，我试图勾勒出科技行业在当前这一刻的真实样貌。
It came after I had the chance to visit the AI labs OpenAI and Anthropic, meet innovative startups like Ramp, Uber and others, get new, unpublished data from GitHub, Factory AI and Linear. The focus of the talk is trend inside of AI labs, VC-funded startups and Big Tech. Thanks to the kind access to these teams!在此之前，我有机会走访了 OpenAI 和 Anthropic 等 AI 实验室，接触了 Ramp、Uber 等创新型初创公司，并从 GitHub、Factory AI 和 Linear 获取了全新的未公开数据。本次演讲聚焦于 AI 实验室、风投支持的初创公司以及大型科技公司内部的趋势。感谢这些团队的慷慨支持！
Before the conference, I spent weeks identifying and recording trends that didn’t exist a year ago – or were much more nascent back then – and also things that are currently broken, and others that remain unchanged. Today, we cover:在大会召开前，我花了数周时间识别并记录了那些一年前还不存在（或当时尚处于萌芽阶段）的趋势，以及目前已经崩坏的事物，还有那些依然保持不变的事物。今天，我们将探讨以下内容：
Speed of change. In the tech industry, change has never been this large-scale, this fast. Industry legend Martin Fowler confirms.变革速度。在科技行业，变革的规模和速度从未像现在这样巨大且迅猛。行业传奇人物 Martin Fowler 对此表示认同。
What’s changed: practically nobody writes code by hand anymore, working with 5-10 agents more common, the fading of the IDE, and 13 more changes from the last year.发生了什么变化：实际上已经没有人再手动编写代码了，同时使用 5-10 个智能体已成常态，IDE 正在消亡，以及过去一年中发生的其他 13 项变化。
What’s broken: assumptions about code output broke, code reviews became theatrical, quality and reliability is down, and more.哪些已经崩坏：关于代码产出的假设失效了，代码审查沦为形式主义，质量和可靠性下降，等等。
What’s still the same: teams are still important, as is planning; non-engineers are still not shipping code, and more.哪些依然如故：团队依然重要，规划依然重要；非工程师人员依然无法直接交付代码，等等。
What comes next? Cloud coding agents and harnesses, engineers to stop reading the code, companies building a new type of AI infra, and more are already starting, and should accelerate.未来会怎样？云端编码智能体与框架、工程师不再阅读代码、企业构建新型 AI 基础设施等趋势已经开启，并将加速发展。
You can watch the full talk, which is 29 minutes long:您可以观看时长 29 分钟的完整演讲：
Paid subscribers can also access the slides for the presentation:付费订阅者还可以获取演讲演示文稿的幻灯片：
1. Speed of change1. 变革速度
People in tech are more than used to change; seeing the internet go from zero to everywhere, the arrival of mobile communications and smartphones exploding in popularity, cloud computing rising from a niche concern, and the development of programming languages like Go and Rust, and frameworks like React (web) and Jetpack Compose (Android).科技从业者对变革早已习以为常；他们见证了互联网从无到有、覆盖全球，移动通信和智能手机的普及，云计算从一个小众概念崛起，以及 Go 和 Rust 等编程语言，还有 React（Web）和 Jetpack Compose（Android）等框架的发展。
Despite this, the scale and pace of the impact AI is having at present is still without precedent. That’s how industry veteran Martin Fowler described it at The Pragmatic Summit:尽管如此，AI 目前所产生的影响规模和速度仍然是前所未有的。行业资深专家 Martin Fowler 在 The Pragmatic Summit 上是这样描述的：
“Nothing has hit with the magnitude of AI. This is a whole size difference from anything that we’ve faced before.“没有任何事物能像 AI 这样产生如此巨大的冲击。这与我们以往面对的任何事物相比，完全是不同量级的。”
On a smaller scale, we were very much involved in the growth of object-oriented languages. [object-oriented languages] scared a lot of people, but it didn’t scare us so much because we were part of it.“在较小的范围内，我们曾深度参与了面向对象语言的发展。[面向对象语言] 吓到了很多人，但并没有吓到我们，因为我们是其中的一部分。”
The internet had a huge impact upon us all. And, of course, we were spreading the challenge of agile software development. [Agile] had a very big impact on a lot of organizations because you could tell by how hard they resisted it.“互联网对我们所有人都产生了巨大的影响。当然，我们当时也在推广敏捷软件开发的理念。[敏捷] 对许多组织产生了非常深远的影响，这一点从他们抵制它的强烈程度就能看出来。”
But [for all those other changes] we kept talking about how important they were and how valuable they were and trying to persuade people of the importance of them. It may sound surprising, but even for the internet, there were people who wouldn’t think that was important!“但 [对于所有那些其他变革]，我们一直在谈论它们有多重要、多有价值，并试图说服人们认识到它们的重要性。听起来可能很令人惊讶，但即使在互联网时代，也曾有人认为它并不重要！”
For AI there’s no argument about how important it is. You cannot put blinkers on to deny the importance of this thing.”“对于 AI，没人会质疑它的重要性。你无法蒙上双眼去否认它的重要性。”
My own take is similar; we are without doubt at the beginning of a massive technological transformation, and after it, software will be built differently from how we’ve been doing for decades, although some parts of development will remain the same. At the very least, the tooling and best practices will look different, and things are changing faster than ever.我的观点也类似；毫无疑问，我们正处于一场大规模技术变革的开端。在这之后，软件的构建方式将与过去几十年的做法大不相同，尽管开发中的某些部分依然会保持不变。至少，工具和最佳实践将会发生改变，而且事物变化的速度比以往任何时候都要快。
2. What’s changed?2. 发生了什么变化？
#1 Nobody writes code by hand anymore#1 手动编写代码已成过去式
As the calendar enters Q4 of this year, we see this has solidified into a mega trend since the end of 2025 year when models greatly improved at coding. Related to this, in the very first article of this year we asked the question: when AI writes almost all code, what happens to software engineering?随着今年进入第四季度，我们看到自 2025 年底模型在编码能力上取得巨大进步以来，这一趋势已变得稳固。与此相关的是，我们在今年年初的第一篇文章中就提出了一个问题：当 AI 编写了几乎所有的代码时，软件工程会发生什么？
Today, there are plenty of signs that most engineers have stopped writing code by hand, and it was also a sign of the times recently when the Ruby on Rails creator sparked a “death of coding by hand” debate. Personally, I’m excited by the new opportunity that AI creates, and it’s exciting to experience this revolution firsthand. As mentioned in that deepdive, I’m certain that my way of coding will change drastically in 2026, and there’ll be plenty of knock-on effects.今天，有大量迹象表明大多数工程师已经停止手动编写代码。最近，Ruby on Rails 的创建者引发了一场关于“手动编码终结”的辩论，这也是时代变迁的一个缩影。就我个人而言，我对 AI 创造的新机遇感到兴奋，能亲身经历这场革命令人激动。正如在那篇深度分析中所提到的，我确信我的编码方式将在 2026 年发生剧烈改变，并且会产生诸多连锁反应。
For more on this topic, check out this recent edition of The Pulse.关于此话题的更多内容，请查看最近一期的《The Pulse》。
#2 Working with several parallel agents is increasingly common#2 同时使用多个并行智能体已日益普遍
I like talking to engineers at AI labs because their working practices are often a few months ahead of the rest of the industry. Claude Code creator, Boris Cherny, revealed the new way he gets things done on the podcast:我喜欢与 AI 实验室的工程师交流，因为他们的工作实践往往比行业其他部分领先几个月。Claude Code 的创建者 Boris Cherny 在播客中透露了他完成工作的新方式：
“I have 5 terminal tabs. Each one of them has a checkout of their repository. I’ll round robin and start Claude Code in each one. I also run 5-10 Claudes on Claude Web, in parallel with my local Claudes.”“我有 5 个终端标签页。每一个都签出了各自的代码库。我会轮流在每个标签页中启动 Claude Code。此外，我还会与本地的 Claude 并行运行 5-10 个 Claude Web 实例。”
A few months after these comments, on last week’s pod with Cockroach Labs cofounder, Peter Mattis, – who’s an extremely productive developer who wrote circa 100K lines of code/year, pre-AI – said he’s doing something similar:在这些评论发表几个月后，在上周与 Cockroach Labs 联合创始人 Peter Mattis 的播客中——他是一位极其高效的开发者，在 AI 出现前每年编写约 10 万行代码——他表示自己也在做类似的事情：
“Oftentimes, I’m doing things in parallel. I find my cognitive overhead is about 5-10 agent sessions concurrently. But sometimes those sessions will have many subagents doing things.”“通常情况下，我是在并行处理事务。我发现我的认知负荷大约可以同时处理 5-10 个智能体任务。但有时这些任务会包含许多子智能体在执行具体操作。”
I also asked a former coworker at Uber, who’s also an extremely productive software engineer, how he works these days. Dima Zaytsev (now a software engineer at Linear), told me:我还问了一位以前在 Uber 的同事，他也是一位极其高效的软件工程师，问他现在是如何工作的。Dima Zaytsev（现为 Linear 的软件工程师）告诉我：
“It used to be a simple world: one mouse, one keyboard, one screen. You physically can’t work on more than one thing at once. Now, you no longer have that limitation.“过去的世界很简单：一个鼠标、一个键盘、一个屏幕。你实际上无法同时处理多件事。现在，你不再受此限制了。”
I end up having 5-10 (literally) worktrees locally that I rotate between. Prompt one agent, and while it is working, move on to another to test output or review code.”“我本地最终会有 5-10 个（字面意思）工作树在切换。给一个智能体发送提示词，在它工作的同时，转去另一个测试输出或审查代码。”
Nearly all of the most productive software engineers I’ve met – who were hand-writing code a year ago – no longer write the code by hand and also run several parallel agents. What a change!我遇到过几乎所有最高效的软件工程师——他们一年前还在手动编写代码——现在都不再手动编写代码，并且都在运行多个并行智能体。真是巨大的变化！
#3 Rapid rise of agent-generated PRs#3 智能体生成的 PR 迅速增加
Fresh data that GitHub shared with me:GitHub 与我分享的最新数据：
I’ve given GitHub grief for its ongoing reliability issues, but seeing how rapidly agent-generated PRs are growing makes me a lot more empathetic for the load which the platform is dealing with.我曾因 GitHub 持续不断的可靠性问题而对其提出批评，但看到智能体生成的 PR 增长如此迅速，我对其平台所承受的负载多了几分同情。
Food for thought: there were more agent-authored PRs in August 2026 on GitHub than human-authored ones! It’s reasonable to speculate that the number of agent-generated PRs will be permanently exceeding human-generated ones on the platform, going forward.值得深思的是：2026 年 8 月，GitHub 上智能体提交的 PR 数量已经超过了人类提交的数量！可以合理推测，未来该平台上智能体生成的 PR 数量将永久性地超过人类生成的数量。
To give a sense of the number of AI-generated PRs: as of today (October 2025), there is likely to be 3x as many fully AI-generated PRs, per month (probably 75M+), than human generated ones at the end of 2023 (25M in December 2023). And the pace of AI-generated PRs does not seem to be slowing down, at least not now.为了说明 AI 生成 PR 的数量级：截至今天（2025 年 10 月），每月完全由 AI 生成的 PR 数量可能已达到 2023 年底人类生成数量（2023 年 12 月为 2500 万）的 3 倍（可能超过 7500 万）。而且 AI 生成 PR 的速度似乎并没有放缓，至少目前还没有。
#4 Agent-generated issues also rising rapidly#4 智能体生成的问题（Issue）也在迅速增加
Agents are not just generating PRs, they’re also opening tickets. Some more exclusive data, this time from my friends at Linear, which added first-class MCP support for agentic creation of issues:智能体不仅在生成 PR，它们还在开启工单（Ticket）。来自 Linear 朋友们的一些独家数据，他们增加了对智能体创建 Issue 的一流 MCP 支持：
#5 Agent skills usage is mainstream#5 智能体技能的使用已成为主流
Both engineers and non-engineers use agent skills, and lots of companies are building their own agent skills repositories for all staff to create, share, and evaluate. An interesting data point on skills usage trending heavily up comes from autonomous software factory vendor Factory AI, which shared with me:工程师和非工程师都在使用智能体技能，许多公司正在构建自己的智能体技能库，供全体员工创建、共享和评估。自主软件工厂供应商 Factory AI 与我分享了一个关于技能使用率大幅上升的有趣数据点：
#6 The fading IDE#6 IDE 的消亡
I have great respect for software engineer Steve Yegge, who’s good at identifying emerging trends and learning about them. In a podcast episode, he said the IDE is effectively over:我对软件工程师 Steve Yegge 非常尊重，他擅长识别新兴趋势并深入学习。在一次播客中，他说 IDE 实际上已经终结了：
Gergely: “Speaking about the job as developers, you’ve said something that can be triggering for a lot of people. You’ve said, on the AI Engineer Summit, that if you’re still using an IDE now, you’re a bad engineer.”Gergely：“谈到开发者工作，你曾说过一些可能会触发很多人敏感神经的话。你在 AI 工程师峰会上说，如果你现在还在使用 IDE，那你就是一个糟糕的工程师。”
Steve: “Yeah, well, you got to be a little provocative. Let me put it this way. Okay, I’m not going to say you’re a bad engineer because I know some very, very good engineers, better than I am, who are still at level one or two in my chart [of AI usage]? But I feel profoundly sorry for them.Steve：“是的，好吧，你得稍微激进一点。让我换种说法。好吧，我不会说你是个糟糕的工程师，因为我知道一些非常、非常优秀的工程师，比我还好，但他们仍处于我图表 [AI 使用等级] 中的第一或第二级？但我深深地为他们感到遗憾。”
I feel pity for them like I’ve never felt in my life. For these grown people who are good engineers or used to be. And they’re like, ‘yeah, you know, I use Cursor and I ask it questions sometimes. And I’m really impressed with the answers. And then I review its code really carefully.’“我为他们感到前所未有的同情。对于这些成年人，他们是优秀的工程师，或者曾经是。他们会说：‘是的，你知道，我使用 Cursor，有时会问它问题。我对答案印象深刻。然后我会非常仔细地审查它的代码。’
And then I check it in and I’m like: ‘dude, you’re going to get fired. And you’re one of the best engineers I know!!’ ““然后我提交代码，我想：‘老兄，你会丢掉工作的。而你是我认识的最优秀的工程师之一！！’”
Steve described his levels of AI usage like this:Steve 对 AI 使用等级的描述如下：
No AI usage不使用 AI
AI agent in the IDE, with strict permissionsIDE 中的 AI 智能体，具有严格的权限
AI agent in the IDE, with “YOLO” mode (permissions off)IDE 中的 AI 智能体，具有“YOLO”模式（无权限限制）
AI agent in the IDE, no longer looking at the code, but interacting with the agentIDE 中的 AI 智能体，不再查看代码，而是与智能体交互
CLI-first: abandoned the IDECLI 优先：放弃 IDE
Running several agents in parallel并行运行多个智能体
Running 10+ agents运行 10 个以上智能体
Built a custom agent orchestrator to run 30+ (or 100+) agents构建自定义智能体编排器以运行 30 个（或 100 个以上）智能体
Steve believes that “AI-pilled” engineers will abandon the IDE, and I’m seeing data from the market which backs that prediction:Steve 认为那些“沉迷 AI”的工程师会放弃 IDE，我从市场看到的数据也支持这一预测：
Antigravity 1.0 was the last IDE released, based on a VS Code fork. It was released in November 2025. After that, no major IDE that is a VS Code Fork has launched. In May 2026, when Antigravity 2.0 launched, the product moved away from the IDE concept.Antigravity 1.0 是最后一款基于 VS Code 分支发布的 IDE，发布于 2025 年 11 月。此后，没有再出现过基于 VS Code 分支的大型 IDE。2026 年 5 月 Antigravity 2.0 发布时，该产品已经脱离了 IDE 的概念。
Codex launched as a non-IDE in Feb 2026, and they’re glad they did so, despite being torn about moving away from the IDE concept, at the end of 2025.Codex 于 2026 年 2 月作为非 IDE 产品推出，尽管在 2025 年底对是否脱离 IDE 概念感到纠结，但他们很高兴做出了这一决定。
Cursor moved away from the IDE. In April 2026, Cursor relaunched and got rid of the IDE interface. It now looks pretty similar to the Codex and Claude desktop apps. When I talked to their team over the summer, they told me they maintain the “legacy” VS Code fork version for existing enterprises, but the future is agentic for them.Cursor 也脱离了 IDE。2026 年 4 月，Cursor 重新发布并去掉了 IDE 界面。它现在看起来与 Codex 和 Claude 桌面应用非常相似。今年夏天我与他们的团队交谈时，他们告诉我，他们为现有企业保留了“遗留”的 VS Code 分支版本，但对他们来说，未来是智能体化的。
JetBrains seems in a hurry to pivot from IDEs. JetBrains has built some of the most beloved IDEs for developers, but the company is now also pivoting to JetBrains Air, and agentic development environments.JetBrains 似乎急于从 IDE 转型。JetBrains 构建了一些最受开发者喜爱的 IDE，但该公司现在也正在转向 JetBrains Air 和智能体化开发环境。
Industry legend Kent Beck told me something interesting when we discussed why IDEs are slowly vanishing:行业传奇人物 Kent Beck 在我们讨论 IDE 为何逐渐消失时告诉我一件有趣的事：
“It’s not that we don’t need more perspective and context for our human-based decisions; it’s that the context has changed.”“并不是说我们不需要为基于人类的决策提供更多的视角和背景；而是背景已经改变了。”
I wonder if what is really happening is the IDE evolving into something different to work better with coding agents. Steve Yegge also talked about how the IDE needs to evolve into a conversation and monitoring interface, but not an editor, given that we no longer write the code.我想知道，真正发生的是不是 IDE 正在演变成某种不同的东西，以便更好地与编码智能体协作。Steve Yegge 也谈到，鉴于我们不再编写代码，IDE 需要演变成一个对话和监控界面，而不是编辑器。
I’d also add that IDEs need to evolve into a validation and verification interface: how do we know that the agents’ output works as expected, how can we verify what tests it passes, how it looks, and whether you can try out whatever the agent builds. Tools like this are surely coming and will be widely adopted.我还要补充一点，IDE 需要演变成验证和核实界面：我们如何知道智能体的输出是否如预期工作，如何验证它通过了哪些测试，它看起来如何，以及你是否可以试用智能体构建的任何东西。这类工具肯定会出现并被广泛采用。
#7 Everyone is building their own harness/agent platform#7 每个人都在构建自己的框架/智能体平台
In August, I posed a question on social media about whether it’s possible to be a serious tech business without having built an AI harness:8 月份，我在社交媒体上提出了一个问题：如果不构建 AI 框架，还能否成为一家严肃的科技企业？
I asked it because most mid-sized-and-above companies have built their own agent harnesses, at this point! A few examples:我之所以这样问，是因为大多数中型及以上规模的公司此时都已经构建了自己的智能体框架！举几个例子：
Ramp building Inspect – a case study we covered in depthRamp 构建了 Inspect——我们深入报道过的一个案例研究
Stripe (Minions), Uber (Minion), Block (Goose), Shopify (River)Stripe (Minions)、Uber (Minion)、Block (Goose)、Shopify (River)
Google (Agent Smith), Meta (Devmate), Amazon (Kiro + Crew), Dropbox (Nova), Spotify (Honk)Google (Agent Smith)、Meta (Devmate)、Amazon (Kiro + Crew)、Dropbox (Nova)、Spotify (Honk)
DoorDash (Flux), Grab (LLM-Kit), WorkOS (Horizon), Hubspot (Crucible)DoorDash (Flux)、Grab (LLM-Kit)、WorkOS (Horizon)、Hubspot (Crucible)
Monzo (Agent Chip), Sierra (Pinecone), Harvey (Spectre), Browserbase (bb)Monzo (Agent Chip)、Sierra (Pinecone)、Harvey (Spectre)、Browserbase (bb)
… and many, many more!……以及更多！
#8 Dev work often starts in Slack#8 开发工作通常从 Slack 开始
What I’ve learned by visiting startups is that more and more development kicks off inside Slack. At OpenAI, it’s “@Codex, implement this”; within Anthropic, it’s “@Claude build this”, while inside Linear, it’s “@Linear work on this”. More startups have their own Slack integration of their coding agent – often a custom one.通过走访初创公司我了解到，越来越多的开发工作在 Slack 内部启动。在 OpenAI，是“@Codex，实现这个”；在 Anthropic，是“@Claude 构建这个”；而在 Linear，则是“@Linear 处理这个”。更多的初创公司拥有自己的 Slack 编码智能体集成——通常是定制的。
Coding agents work really well when deeply integrated into a company’s stack, when the Slack agent kicks off a coding agent that runs in the cloud.当编码智能体深度集成到公司的技术栈中时，工作效率非常高，例如当 Slack 智能体启动在云端运行的编码智能体时。
#9 Agentic software factories being built everywhere#9 智能体软件工厂正在各地兴建
We have covered in-depth how OpenAI is building an agentic software factory, and a lot of feedback from readers about that article has been an “we are too!” type response. Many readers say that their company is building a similar “agentic software factory.”我们深入探讨了 OpenAI 如何构建智能体软件工厂，读者对此文章的许多反馈都是“我们也是！”。许多读者表示，他们的公司正在构建类似的“智能体软件工厂”。
The “agentic software factory” adds AI functionality to a bunch of existing systems such as the CI/CD system; for instance, in being able to interact with CI/CD via Slack, or creating brand new systems with agents in them like agentic code review tools, OpenAI’s agentic deploy system, or the Perf Factory.“智能体软件工厂”为一系列现有系统（如 CI/CD 系统）增加了 AI 功能；例如，能够通过 Slack 与 CI/CD 交互，或者利用其中的智能体创建全新的系统，如智能体代码审查工具、OpenAI 的智能体部署系统或 Perf Factory。
#10 Migrations no longer take years#10 迁移不再需要数年时间
We’re seeing many migrations that would have taken years to complete, now taking mere weeks or months:我们看到许多原本需要数年才能完成的迁移，现在只需数周或数月即可完成：
Anthropic: migrating the package manager Bun from Zig to Rust in 11 days (versus an estimated 1.5 engineering years)Anthropic：在 11 天内将包管理器 Bun 从 Zig 迁移到 Rust（预计需要 1.5 个工程年）
OpenAI: the API layer is being migrated from Python to Rust. The migration is taking around 5 months, versus several years that it would have taken, without AIOpenAI：API 层正在从 Python 迁移到 Rust。迁移耗时约 5 个月，而没有 AI 的话则需要数年
Airbnb: migrating 3,500 end-to-end test files from Enzyme to React Testing Library: took 6 weeks (instead of years)Airbnb：将 3,500 个端到端测试文件从 Enzyme 迁移到 React Testing Library：耗时 6 周（而不是数年）
Asana: migrating 4,000 end-to-end test files from Enzyme to React Testing Library: 2 weeks, instead of an estimated spread out over five yearsAsana：将 4,000 个端到端测试文件从 Enzyme 迁移到 React Testing Library：耗时 2 周，而不是预计分散在五年内完成
Uber: migrating 600,000 JUnit 4 tests across 15 million lines of code (!!) to JUnit 5: took 4 months (instead of estimated several years)Uber：将 1500 万行代码中的 60 万个 JUnit 4 测试迁移到 JUnit 5（！！）：耗时 4 个月（而不是预计的数年）
#11 AI costs a major engineering concern#11 AI 成本成为工程部门的主要关注点
In May, we covered the trend of companies wanting to cut back on AI spend within engineering departments, and last month, I reported on how tech companies are moving to open AI models to save 50% or more in token costs. Uber is a good example, where, despite token usage trending upwards, costs have stayed flat since May thanks to them running open models and doing smart model routing:5 月份，我们报道了公司希望削减工程部门 AI 支出的趋势；上个月，我报道了科技公司如何转向开源 AI 模型以节省 50% 或更多的 Token 成本。Uber 就是一个很好的例子，尽管 Token 使用量呈上升趋势，但由于他们运行开源模型并进行智能模型路由，成本自 5 月以来保持平稳：
Three weeks after my article, Bloomberg confirmed the exact same trend. As I covered in my original deepdive, lower-cost models and smart routing account for the majority of cost savings at most companies. If you’re only doing two things, consider those techniques.在我文章发布三周后，彭博社证实了完全相同的趋势。正如我在最初的深度分析中所述，低成本模型和智能路由占大多数公司成本节约的大部分。如果你只做两件事，请考虑这些技术。
#12 Projects get done with only one or two engineers#12 项目只需一两名工程师即可完成
Katelyn Lesse, Head of Engineering for Claude Platform, told me how her team works inside Anthropic. From our deepdive:Claude 平台工程主管 Katelyn Lesse 告诉我她的团队在 Anthropic 内部是如何工作的。摘自我们的深度分析：
“On an individual project, you often cannot have more than two people working on it. This is because each engineer is already running several agents. And so as an engineer, you’re already fighting against your agents, which are stepping on each other’s toes on implementation. And in this setup, you just cannot have that many humans, who also come with all their agents!”“在单个项目上，你通常不能有超过两个人参与。这是因为每个工程师都已经运行了几个智能体。因此，作为一名工程师，你已经在与你的智能体进行斗争，它们在实现上互相干扰。在这种设置下，你根本不能有那么多人类，因为他们每个人都带着自己的智能体！”
These days, I see the same thing happening at companies both small and large.如今，我在大大小小的公司都看到了同样的情况。
Other changes其他变化
13. Engineering specializations are disappearing. Specifically, there seems to be less demand for iOS, Android, and frontend specializations, and more for “generic” software engineers. We covered this trend with data in the State of the software engineering job market in 2026, observing how mobile and frontend demand is dropping (while AI & FDE demand surges)13. 工程专业化正在消失。具体来说，对 iOS、Android 和前端专业化的需求似乎在减少，而对“通用”软件工程师的需求在增加。我们在《2026 年软件工程就业市场现状》中通过数据观察到了这一趋势，即移动端和前端需求正在下降（而 AI 和 FDE 需求激增）。
14. Teams are getting smaller. Projects are being done by fewer engineers. Inside startups, team sizes seem to be shrinking.14. 团队规模正在缩小。项目由更少的工程师完成。在初创公司内部，团队规模似乎正在缩减。
15. Reduced junior recruitment. We cover how it’s harder for graduates & interns to get hired in the State of the software engineering job market in 2026 deepdive.15. 初级岗位招聘减少。我们在《2026 年软件工程就业市场现状》深度分析中讨论了毕业生和实习生如何更难被录用。
16. Agentic infra is becoming its own discipline. Most mid-sized-and-above companies are building out agentic platforms, and infra teams are increasingly morphing into agentic infra teams.16. 智能体基础设施正成为一个独立的学科。大多数中型及以上规模的公司都在构建智能体平台，基础设施团队正日益演变为智能体基础设施团队。
3. What’s broken?3. 哪些已经崩坏？
Assumptions about code quantity and frequency关于代码数量和频率的假设
It’s been a commonly held belief that code quantity grows roughly linearly. But with agents, both the lines of code and number of commits are growing exponentially, as shown in data from GitHub:人们普遍认为代码数量的增长大致呈线性。但有了智能体之后，代码行数和提交次数都在呈指数级增长，正如 GitHub 的数据显示：
(Human) code reviews are dead（人类）代码审查已死
A software engineer at a mid-sized startup told me something that’s pretty much an open secret across the industry, including at places with code reviews in place.一家中型初创公司的软件工程师告诉我一件在整个行业（包括那些有代码审查制度的地方）几乎是公开秘密的事情。
“Everyone is playing the theater of doing reviews, but with the volume of changes that get thrown your way, I observed that people just find a path of least resistance: give up on reviews and just stamp everything with LGTM.“每个人都在演戏进行审查，但面对涌向你的海量变更，我观察到人们只是选择了阻力最小的路径：放弃审查，直接给所有东西盖上 LGTM（看起来没问题）的戳。”
We are gradually phasing out this process ourselves with some shortcuts that you are allowed to take, and that has been a major productivity boost.”“我们自己也在逐渐淘汰这个流程，并采取了一些允许使用的捷径，这带来了巨大的生产力提升。”
At the LDX3 conference, there was a strong reaction among the audience when they heard the bolded sentence out above. Today at most companies, there is indeed a “theater of code reviews”. The fact is that no engineer can keep up with 5-10 times more code to review, so most don’t thoroughly review the code.在 LDX3 大会上，当观众听到上面加粗的句子时，反应非常强烈。如今在大多数公司，确实存在“代码审查的戏码”。事实是，没有任何工程师能跟上 5-10 倍的代码审查量，所以大多数人并没有彻底审查代码。
Agent-only code reviews trending up仅由智能体进行的代码审查呈上升趋势
Fresh data from Linear shows that PRs which are reviewed solely by AI agents are a rising trend, and I expect it’ll continue:来自 Linear 的最新数据显示，仅由 AI 智能体审查的 PR 呈上升趋势，我预计这种情况将持续下去：
Quality and reliability down质量和可靠性下降
We see this in many of the digital products we use. As Mario Zechner, the creator of Pi, said on the podcast:我们在使用的许多数字产品中都看到了这一点。正如 Pi 的创建者 Mario Zechner 在播客中所说：
“Everything is broken. It sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services. And user interfaces have the weirdest bugs that you’d think a QA team would catch. I give you that that’s been the case for longer than agents exist. But we seem to be accelerating.”“一切都坏了。软件确实看起来变成了一团脆弱的烂摊子，98% 的正常运行时间已成为常态而非例外，即使对于大型服务也是如此。而且用户界面存在最奇怪的 Bug，你本以为 QA 团队会发现它们。我承认这种情况在智能体出现之前就存在了。但我们似乎正在加速。”
We covered the phenomenon of quality being worse with more AI usage in March, in ‘Are AI agents actually slowing us down?’我们在 3 月份的《AI 智能体真的在拖慢我们的速度吗？》一文中讨论过 AI 使用率越高质量越差的现象。
Infra capacity shortage基础设施容量短缺
It’s common knowledge that there’s a GPU shortage and memory shortage in the market. In addition, there’s also the growing trend of CPU shortages. As I covered last month:众所周知，市场上存在 GPU 短缺和内存短缺。此外，CPU 短缺的趋势也在增长。正如我上个月所报道的：
“Apparently, it’s now nearly impossible to get CPUs on spot instances without long-running connections with cloud providers. Also, reserving specific CPUs now needs to be done months in advance, and cloud providers will even turn down certain reservations because they don’t have enough CPUs or the right type of CPUs.”“显然，现在如果不与云服务商建立长期连接，几乎不可能在竞价实例（Spot Instances）上获得 CPU。此外，预留特定 CPU 现在需要提前数月完成，云服务商甚至会因为没有足够的 CPU 或没有合适类型的 CPU 而拒绝某些预留申请。”
If you’re at a company with a non-trivial amount of CPU usage, securing capacity is something worth doing now, as I wrote recently:如果你所在的公司有非微量的 CPU 使用需求，那么现在就确保容量是非常值得的，正如我最近所写：
“The best time to secure more CPU capacity is most certainly right now. I’m hearing rumors that certain cloud regions no longer accept new tenants because all CPU capacity is leased, or negotiations elsewhere are difficult. I’m also hearing that customers are already paying today to reserve capacity that will only come online in data centers from December. This seems predatory by providers, but demand is so high that this is how they likely prioritize new capacity allocation – while earning much higher profits than usual.“确保更多 CPU 容量的最佳时机无疑就是现在。我听说有些云区域不再接受新租户，因为所有 CPU 容量都已租出，或者其他地方的谈判很困难。我还听说客户今天已经在付费预留容量，这些容量要到 12 月才会从数据中心上线。这看起来像是服务商的掠夺行为，但需求如此之高，这很可能是他们优先分配新容量的方式——同时赚取比平时高得多的利润。
If your company has dynamic workloads, and you’ve used spot instances in the past, now could be a good time to allocate fixed capacity – even if it’s more expensive. If you expect meaningful growth, doing so now might mean having options at some cloud providers or in some regions.”如果你的公司有动态工作负载，并且过去使用过竞价实例，现在可能是分配固定容量的好时机——即使它更昂贵。如果你预计会有显著增长，现在这样做可能意味着在某些云服务商或某些区域有选择权。”
A hit on personal focus and productivity对个人专注力和生产力的打击
Software engineer Dima Zaytsev (currently at Linear, formerly my colleague at Uber) told me something that felt very relatable on AI and productivity:软件工程师 Dima Zaytsev（现就职于 Linear，曾是我在 Uber 的同事）告诉我一些关于 AI 和生产力的感受，非常令人感同身受：
“There’s lots of context switching: there’s always another agent that waits on your response.“有很多上下文切换：总是有另一个智能体在等待你的响应。”
Also, it’s just more work. When AI was ramping up, I felt more productive than my peers: I did in an hour what others needed a day for. Now, the expectation has become that everyone works on parallel things. And so, I end up feeling I have more work compared to pre-AI.”“而且，这纯粹是更多的工作。当 AI 开始兴起时，我觉得自己比同事更有生产力：我用一小时完成了别人需要一天才能完成的工作。现在，期望值已经变成了每个人都在并行处理多项事务。因此，与 AI 出现之前相比，我最终感觉自己的工作量更大了。”
Engineering leaders taking career breaks工程领导者正在休假
An interesting, unexpected trend that has emerged is CTOs, Heads of Engineering, and VPs of Engineering resigning from their jobs, often with nothing specific lined up. From a current CTO who asked to remain anonymous:一个有趣且出人意料的趋势是，CTO、工程主管和工程副总裁纷纷辞职，而且通常没有任何具体的后续安排。来自一位要求匿名现任 CTO 的话：
“This change [with AI] makes builders want to build. We want to build again, so we can build more, and build faster with better tools, so we can increase the “talent density” of the team by doing more with fewer great people, and so on.“这种变化 [伴随 AI] 让构建者想要构建。我们想再次构建，这样我们就能构建更多，利用更好的工具构建得更快，从而通过用更少的优秀人才做更多的事来提高团队的‘人才密度’，等等。”
It’s an amazing time to build things. And it’s only getting better. And people just want to be close to it. They want to build and see how far they can go with these new tools.“现在是构建事物的绝佳时机。而且只会越来越好。人们只是想接近它。他们想构建，并看看利用这些新工具能走多远。”
I have a bunch of friends in my social circle who are the “CTO drop outs” you speak of. More still who are moving from management to IC roles in large companies. And their stories are largely what I describe above. They simply see this as a truly exciting time to build.“我的社交圈里有一群朋友，他们就是你所说的‘CTO 辍学者’。还有更多人正从管理岗位转向大公司的个人贡献者（IC）角色。他们的故事很大程度上就是我上面描述的那样。他们只是认为这是一个构建事物的真正令人兴奋的时代。”
In the end, building is why they got into this field in the first place.”“归根结底，构建就是他们最初进入这个领域的原因。”
We cover this in the deepdive ‘Headed for the exit: the great engineering leader career break’.我们在深度分析《走向出口：工程领导者的职业大休假》中讨论了这一点。
4. What’s still the same?4. 哪些依然如故？
In the LDX3 keynote, I also covered areas that are mostly unchanged from before AI:在 LDX3 主题演讲中，我还涵盖了在 AI 出现后基本没有变化的领域：
Teams are still important. As Katelyn Lesse, Head of Engineering for Claude Platform told me in July:团队依然重要。正如 Claude 平台工程主管 Katelyn Lesse 在 7 月份告诉我的：
“One thing I’ve heard from some people is “we have two humans and a bunch of agents.” I reply that this isn’t where we’re at. I still have teams whose job it is to own a piece of software, iterate on it, own oncall, and so on. While each of these humans are supercharged by AI, the size and shape of the team is still similar. We still have two-pizza teams.”“我从一些人那里听到的一个说法是‘我们有两个人类和一堆智能体’。我回答说，情况并非如此。我仍然有负责拥有某部分软件、迭代它、负责值班（oncall）等的团队。虽然这些人类中的每一个都被 AI 增强了，但团队的规模和形态依然相似。我们仍然有‘两个披萨’团队。”
Katelyn works at one of the most “AI-pilled” companies globally, so if teams are still as important there as they were before AI, then it’s not a stretch to say that the team structure is still relevant at companies across the industry.Katelyn 在全球最“沉迷 AI”的公司之一工作，所以如果那里的团队依然像 AI 出现前一样重要，那么说团队结构在整个行业的公司中依然适用并不夸张。
Planning still happens – at least for complex work. Complex projects still have a lengthy planning phase. Also from Katelyn, on the planning phase of Claude Managed Agents:规划依然存在——至少对于复杂工作而言。复杂的项目仍然有漫长的规划阶段。同样来自 Katelyn，关于 Claude 托管智能体（Managed Agents）的规划阶段：
“Our planning process looked more like a typical pre-AI planning process. You know how every team has the project, where everyone comes up with some version of the same idea and people keep floating and circling it around until you finally do it? Managed Agents was this for our team. When we started the project, we had documents dating back up to two years about ideas and suggestions.”“我们的规划流程看起来更像典型的 AI 前规划流程。你知道每个团队都有那个项目，每个人都提出某种版本的相同想法，人们不断地漂浮和围绕它盘旋，直到你最终付诸实施？托管智能体对我们的团队就是这样。当我们开始这个项目时，我们有长达两年的关于想法和建议的文档。”
Tests and validation are still very important. From Jarred Sumner, creator of Bun, who’s currently at Anthropic:测试和验证仍然非常重要。来自 Bun 的创建者、目前在 Anthropic 的 Jarred Sumner：
“The AI writes pretty much all the code, but we have the AI write pretty much all the tests as well. Before AI, for production-ready software, we spent about the same time writing tests as we did on writing code. This is still the case with AI. You need to have a way to trust your code, and tests are probably the best way to.”“AI 编写了几乎所有的代码，但我们也让 AI 编写了几乎所有的测试。在 AI 出现之前，对于生产就绪的软件，我们编写测试所花费的时间与编写代码的时间大致相同。AI 出现后依然如此。你需要有一种方式来信任你的代码，而测试可能是最好的方式。”
At each company I talked to in advance of the LDX3 keynote, I observed that a lot of focus is going into validating the output of AI agents. This makes sense: code review no longer works like it did before, we have more code, and we need to make sure that it won’t break production!在 LDX3 主题演讲之前，我与每一家公司交谈时都观察到，很多重点都放在验证 AI 智能体的输出上。这是有道理的：代码审查不再像以前那样工作，我们有了更多的代码，我们需要确保它不会破坏生产环境！
Non-engineers are still not shipping prod code. In the last few weeks, there’s been stuff on social media about AI enabling product managers/designers/non-technical people to ship production code. So, I asked the AI labs, startups, and other companies.非工程师人员依然无法交付生产代码。在过去几周里，社交媒体上出现了一些关于 AI 使产品经理/设计师/非技术人员能够交付生产代码的内容。因此，我询问了 AI 实验室、初创公司和其他公司。
I can report that I did not find any single company where PMs/designers/non-technical people ship to production!我可以报告说，我没有发现任何一家公司是由 PM/设计师/非技术人员交付到生产环境的！
What I did learn about are cases where these folks create bugfixes – often unknowingly! – or new features with their agents that end up with devs to review. There’s also a massive amount of prototyping. But it’s still engineers who are responsible for deciding what can and what cannot be released to production.我所了解到的情况是，这些人有时会创建 Bug 修复——通常是在不知情的情况下！——或者用他们的智能体创建新功能，最终交由开发人员审查。此外还有大量的原型设计。但最终负责决定什么可以、什么不可以发布到生产环境的，依然是工程师。
We’re rediscovering old patterns that work great with AI. This came up in our podcast with Matt Pocock. Matt noticed that agents try to build software layer by layer, which causes bugs between the layers. Reading The Pragmatic Programmer, he discovered the concept of the “tracer bullet.” When he instructed the agent to use “tracer bullets” to build an app (aka implement a “golden path”), the agent started to produce better code.我们正在重新发现与 AI 配合得很好的旧模式。这出现在我们与 Matt Pocock 的播客中。Matt 注意到智能体试图一层一层地构建软件，这导致了层与层之间的错误。在阅读《程序员修炼之道》（The Pragmatic Programmer）时，他发现了“曳光弹”（tracer bullet）的概念。当他指示智能体使用“曳光弹”来构建应用程序（即实现一条“黄金路径”）时，智能体开始产生更好的代码。
As mentioned in the podcast, Matt is now reading classic software engineering books to find other “leading words” that guide agents efficiently.正如在播客中提到的，Matt 现在正在阅读经典的软件工程书籍，以寻找其他能够有效引导智能体的“引导词”。
In general, I’m noticing that “old” best practices are helpful when building better software when working with AI. This includes writing unit tests, building a “golden path” first (aka a “tracer bullet”), architecting an application upfront, and even using design patterns. The amusing thing is that we’re talking about decades-old best practices here.总的来说，我注意到在使用 AI 构建更好的软件时，“旧的”最佳实践很有帮助。这包括编写单元测试、首先构建“黄金路径”（即“曳光弹”）、预先构建应用程序架构，甚至使用设计模式。有趣的是，我们在这里谈论的是几十年前的最佳实践。
5. What comes next?5. 未来会怎样？
It’s possible to look ahead at where the tech industry is headed by identifying trends that are underway, and which look certain to conitnue:通过识别正在进行且看起来肯定会持续下去的趋势，可以展望科技行业的发展方向：
Cloud coding agents + harnesses will dominate. Most devs at companies will run AI agents in the cloud, instead of locally. Ramp offers a blueprint for this in our deepdive about their cloud agent, called Inspect. It seems that inside innovative tech companies, the “build your own cloud agent harness” principle is trending.云端编码智能体 + 框架将占据主导地位。公司里的大多数开发者将在云端运行 AI 智能体，而不是在本地。Ramp 在我们关于其云智能体（名为 Inspect）的深度分析中为此提供了一个蓝图。看起来在创新型科技公司内部，“构建你自己的云智能体框架”原则正成为一种趋势。
I also expect vendors like Anthropic, OpenAI, SpaceX, and others to start pushing their cloud coding agent offerings, and for more startups to build their own cloud harnesses.我还预计 Anthropic、OpenAI、SpaceX 等厂商将开始推广其云端编码智能体服务，并会有更多初创公司构建自己的云端协作框架。
As engineers, we’ll stop reading the code. It’s too early to tell when this will happen; this year, next year, or further in the future, but it’s likely that few of us will read the code that AI agents produce properly, going forward.作为工程师，我们将不再阅读代码。现在说这种情况何时发生还为时尚早——是今年、明年还是更远的未来——但未来我们中很少有人会真正去阅读 AI 智能体生成的代码，这一点很可能会成为现实。
As a rule, I pay a lot of attention to Honeycomb cofounder and CTO, Charity Majors, due to her being a “default sceptic” about new technology, as well as a standout engineer and someone who speaks her mind. On our podcast in August, she asked:通常情况下，我会非常关注 Honeycomb 的联合创始人兼 CTO Charity Majors，因为她对新技术持“默认怀疑”态度，同时她也是一位出色的工程师，并且敢于直言。在八月份的播客中，她提出了这样一个问题：
“What would it take for you to be comfortable shipping code without you reading it and understanding it? Because that is engineering.”“要让你在不阅读也不理解代码的情况下就敢于发布它，需要具备什么条件？因为这才是工程学。”
Charity made the point that Ops and QA have already had decades to figure out how to ship code to production that they didn’t write and don’t understand – all while making sure it works! It seems unavoidable that most software engineers will also join this group. This is ironic, since software engineering, for the longest time, was about engineers writing and understanding the code!Charity 指出，运维和 QA 部门几十年来一直在处理如何发布他们并未编写且不理解的代码——同时还要确保其正常运行！大多数软件工程师加入这个行列似乎已不可避免。这很讽刺，因为长期以来，软件工程的核心一直在于工程师编写并理解代码！
Companies will build brand new types of internal infra. We’ll see a “reinvention” of these systems to work well with agents:公司将构建全新的内部基础设施。我们将看到这些系统为了与智能体更好地协同工作而进行“重塑”：
CI/CD, with agentic evals part of the pipelinesCI/CD，将智能体评估纳入流水线。
Agentic software factories, and figuring out what is and isn’t practical智能体软件工厂，并弄清楚哪些是可行的，哪些是不可行的。
Agents becoming part of deployments, observability, incident management智能体成为部署、可观测性和事件管理的一部分。
Agentic observability will surely become its own problem space and specialization: how can we make sure the customer-facing agents deployed work as expected, and how to ensure that systems which agents build and modify actually work as expected?智能体可观测性必将成为一个独立的领域和专业方向：我们如何确保部署的面向客户的智能体按预期工作？又如何确保智能体构建和修改的系统确实按预期运行？
A “golden age” of refactoring/migrations/full-on rewrites. Migrations and rewrites that had been delayed for years because they’d take similar amounts of time to complete, should take no longer than weeks. That means there’s little excuse to delay any longer!重构、迁移和全面重写的“黄金时代”即将到来。那些因为耗时过长而搁置多年的迁移和重写任务，现在应该能在几周内完成。这意味着再也没有理由推迟了！
Engineers understand more about how capable AI agents are with rewrites/refactors/migrations today, and we’ll also clean up tech debt much faster, while having no reason to have a system in a state that we’re unhappy with!工程师们如今更了解 AI 智能体在重写、重构和迁移方面的能力，我们将能以更快的速度清理技术债务，同时再也没有理由让系统处于我们不满意的状态！
AI “fluency” and “positivity” matter in recruitment at startups. A trend I have not written much about – but which is already happening – is startups selecting engineers for jobs who demonstrate a positive attitude about AI. As the Director of Engineering at a Series D startup told me:AI 的“熟练度”和“积极态度”在初创公司的招聘中很重要。我还没怎么写过的一个趋势——但它已经发生了——是初创公司在招聘时会选择那些对 AI 持积极态度的工程师。正如一家 D 轮初创公司的工程总监告诉我的那样：
“AI positivity was something we started to screen for in our hiring process. We want people to join who want to help us push the limits with what we can build with AI.”“AI 积极性是我们招聘过程中开始筛选的一项指标。我们希望加入的人员愿意帮助我们利用 AI 突破构建能力的极限。”
The reality is that AI coding agents are already everywhere, and agentic systems look set to proliferate very soon. This will bring great demand for software engineers who are willing and able to build next-generation systems, and it’ll be a baseline criterion to be excited about the problem space.现实情况是，AI 编码智能体已经随处可见，而智能体系统似乎很快就会普及。这将对那些愿意并能够构建下一代系统的软件工程师产生巨大需求，而对该领域充满热情将成为一项基本准则。
This is not too dissimilar to the way that startups hire engineers who buy into the idea of growing fast, or when companies favor engineers who pick up the tech stack already in use, instead of insisting upon the one that they personally use.这与初创公司招聘那些认同快速增长理念的工程师，或者公司偏向于采用现有技术栈而非坚持使用个人偏好技术栈的工程师并无太大区别。
Engineers with deep domain knowledge will become more in demand. In New York, I had a conversation with Titus Winters, lead author of Software Engineering at Google. He told me this observation:拥有深厚领域知识的工程师将变得更加抢手。在纽约，我与《Software Engineering at Google》的主要作者 Titus Winters 进行了一次交谈。他分享了这样的观察：
“What you need to succeed anywhere is intelligence, wisdom, and charisma. Intelligence means: how to do it. Wisdom means: what to do. Charisma means: convince others to do it.“要在任何地方取得成功，你需要的是智慧、见识和魅力。智慧意味着：如何去做。见识意味着：做什么。魅力意味着：说服别人去做。”
When intelligence becomes commonplace, wisdom and charisma become much more important.”当智慧变得普遍时，见识和魅力就会变得更加重要。”
In the context of software engineering, “wisdom” is most easily earned by becoming a domain expert. So, if you work at a fintech company, learn about the finance industry and its customers in order to become a more valuable, in-demand engineer! That also applies if you’re at an agriculture tech company, or work in any other domain.在软件工程的背景下，“见识”最容易通过成为领域专家来获得。因此，如果你在一家金融科技公司工作，那就去学习金融行业及其客户的知识，从而成为一名更有价值、更抢手的工程师！如果你在农业科技公司工作，或者在任何其他领域工作，道理也是一样的。
Finally: remind yourself why you got into the tech industry. At the end of my podcast with Peter Mattis, the cofounder and CTO of Cockroach Labs, we talked about how it feels pretty exhausting right now to keep up with the pace of change. He said:最后：提醒自己当初为什么进入科技行业。在我和 Cockroach Labs 联合创始人兼 CTO Peter Mattis 的播客结束时，我们谈到了现在要跟上变革步伐是多么令人疲惫。他说：
“Remind yourself why you got into this in the first place. I got into software engineering because I like building stuff. Now I can build faster, and without some of the compromises that I had before!”“提醒自己当初为什么选择这一行。我进入软件工程是因为我喜欢构建东西。现在我可以构建得更快，而且不需要像以前那样做出一些妥协！”
"Practically no one writes code by hand anymore". It sounds like this is happening at the leading tech companies which you speak to.
It brings up some questions. Are the teams (which you spoke to) building brand new products from scratch, or mostly doing feature updates, bug fixes etc?
Is there any immediate impact to the quality of code? Have they observed code quality over longer periods of time like 6mo or more?
Do they have any obvious incentives to overstate the impact of AI?
Do they have any employee surveys to see if they are satisfied or frustrated?
The most productive developers that you spoke to are now using multiple agents. Did you ask if that translates to generating more revenue or profit?
Let's rewind the clock and go back to the time before Docker existed. Now imagine if LLM were released during that time. What do you think would have happened?
The history keeps repeating itself. It is just that companies don't learn them from theory. They think they discover them. However, it is already found in theory. There is a huge gap right now between the practitioners and theorists. This gap is growing and that leads to wasting money. The demand for CPU is one of those indicators. No one seems to be measuring how much rework is done due to AI slop. How much waste is created? How much code is really needed to increase business value?
More code means more productivity? Productivity without quality and no business value ? I am confused how they big companies now think about the basics. Does it really matter if we are working on the right things?