The following article originally appeared on Charity Majors’s Substack and is being reposted here with the author’s permission.本文最初发表于 Charity Majors 的 Substack，经作者许可在此转载。
A few days back I wrote a piece called “AI enthusiasts are in a race against time, AI skeptics are in a race against entropy.”几天前，我写了一篇文章，题为《AI 狂热者在与时间赛跑，AI 怀疑论者在与熵增赛跑》。
I have notes on a whole pile of AI-related topics that I’d like to cover in depth: AI mandates, communication norms, code review, AI art, and more. Unfortunately, I got too many interesting responses to my last piece, and now I have to address those before I can move on to other topics. 
我手头有一堆关于 AI 的主题想深入探讨：AI 规范、沟通准则、代码审查、AI 艺术等等。遗憾的是，上一篇文章收到的反馈实在太多，我必须先回应这些反馈，才能继续探讨其他话题。
There were two types of interesting responses: the first on the technical merits, the second on ethical grounds. I will respond to each of these separately. Let’s take the technical side first, because it’s easier.反馈主要分为两类：一类针对技术价值，另一类针对伦理层面。我将分别进行回应。先从技术层面开始，因为这部分比较简单。
Somehow, a subset of readers came away believing I was telling everyone to ditch code review and push their shittiest code straight into production without reading it, right now, tout suite.1不知为何，一部分读者误以为我在建议大家现在立刻马上放弃代码审查，直接把最烂的代码推送到生产环境，连看都不看一眼。1
That is not what I am doing. That is not what I think you should do. But I did not pick that example at random, and I will tell you why.我并没有这么做，也不认为你应该这样做。但我并非随意挑选那个例子，我会告诉你原因。
In 2025, the question was whether AI could ever generate “good” code2025年，人们还在质疑 AI 是否能写出“好”代码
It’s easy to forget, but for most of 2025, the idea that AI-generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.2容易被遗忘的是，在2025年的大部分时间里，认为“AI 生成的代码是垃圾，且可能永远是垃圾”不仅是一种合理的观点，更是当时的主流共识。2
That question was answered decisively last November. Ever since Opus 4.5 came out, AI has been able to generate code that is approximately as good as that of the median software engineer, at least for common patterns, and much faster and more cheaply. I came out of a book hole and realized this in January, and over the first few months of 2026, it seemed like everyone around me was having a similar realization.去年11月，这个问题得到了决定性的回答。自 Opus 4.5 发布以来，AI 已经能够生成与普通软件工程师水平相当的代码（至少在通用模式下如此），而且速度更快、成本更低。我从闭关写作中出来时意识到了这一点，而在2026年的头几个月里，我发现周围的每个人似乎都有了类似的觉悟。
But many saw it coming much sooner.但许多人更早之前就预见到了这一点。
The popular narrative holds that Opus 4.5 was what changed. But Opus 4.5 was more like the tipping point. Agentic harnesses (the code that wraps the LLM in a loop with tools) became a real thing in mid 2025, with precursors building back to late 2024. Tool use, function calling, MCPs…all of this wave was building over the course of 2025, and crested into real general purpose usability at the end of the year.大众的叙事认为 Opus 4.5 是改变的关键。但 Opus 4.5 更像是转折点。代理框架（即通过工具将大模型封装在循环中的代码）在2025年中期开始真正出现，而其前身早在2024年底就开始构建了。工具使用、函数调用、MCP……这股浪潮在2025年全年不断积蓄，并在年底达到了真正的通用可用性高峰。
That’s what the enthusiasts were trying to tell us last year. Not only “this is coming”, but “this is coming faster than you think.”这正是狂热者们去年试图告诉我们的。他们不仅说“这即将到来”，还说“这比你想象的要快得多”。
As it turns out, they were right.事实证明，他们是对的。
It was reasonable to be skeptical the first time第一次持怀疑态度是合理的
As you may know, I come from the reliability side of the house. The compliment I will pay to myself and my people is that we do not struggle to adapt to new realities. As soon as a problem is real and in front of us, we adjust smoothly, even eagerly, thanks to an unwholesome zest for lapping up disgusting technical messes (and the campfire tales we get to tell later).如你所知，我来自可靠性领域。我要给同行们（包括我自己）的一个赞美是：我们从不抗拒适应新现实。一旦问题摆在面前，我们就能平稳甚至热切地进行调整，这归功于我们对处理棘手技术烂摊子有着某种不健康的狂热（以及事后分享这些经历的乐趣）。
The un-compliment I will pay myself and my people is that we sometimes struggle to accept that progress is real, that the continued existence of bugs and edge cases does not diminish the fact that huge swaths of problem space do get more-or-less solved over time, to the point they can be taken for granted by most people.3我要给自己的“非赞美”是：我们有时难以接受进步是真实的，难以接受 bug 和边缘情况的持续存在，并不能掩盖这样一个事实：随着时间推移，大片的问题空间已被或多或少地解决，以至于被大多数人视为理所当然。3
The speed at which code went from total crap to “ah damn, that’s not bad” is what I have in the back of my mind, as enthusiasts are telling us that harness engineering and AI validation is real, it’s already here, and it’s getting better astonishingly fast.代码从“完全垃圾”到“哎呀，还不错”的转变速度，一直萦绕在我的脑海中。与此同时，狂热者们告诉我们，框架工程和 AI 验证已经成为现实，它已经到来，并且正以惊人的速度进步。
Holding out for “I’ll believe it when I see it” was forgivable the first time, but much less so the second time. This is what it feels like to be on the inside of an exponential change curve, turns out.4第一次持“眼见为实”的怀疑态度是可以原谅的，但第二次就不那么容易被原谅了。事实证明，这就是身处指数级变化曲线内部的感觉。4
What happened in 2025, exactly?2025年到底发生了什么？
I want to pause here and be very clear about what I think is happening. Then I’m going to tell you what specifically I am excited about, and why.我想在此暂停，明确说明我认为正在发生的事情。然后，我会告诉你我具体对什么感到兴奋，以及原因。
You are under no obligation to join me there. But there are way too many sweeping statements out there right now about “it was never X”—“it was always Y”—“the future belongs to xyzzy” 
—and I want to be crystal clear how conditional and specific and contextual my claims are.你没有义务认同我。但现在关于“它从来不是 X”、“它一直是 Y”、“未来属于 xyzzy”的笼统陈述实在太多了，我想明确指出我的观点是多么的有条件、具体且受环境影响。
What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight.2025年发生的事情是：代码生产的经济学被彻底颠覆了。生成代码不再是困难、耗时且昂贵的事情，它变得几乎免费且即时。代码行数几乎在一夜之间从珍贵、可复用、精心呵护和维护的对象，变成了可丢弃、可再生的资源。
For most of computing history, the primary way people have learned to understand software is by writing the code. Once you’ve achieved some mastery, reading and discussing code gets you most of the way there. (I might argue that software engineers have always relied far too heavily on the code instead of sensemaking the system through observability.)在计算机历史的大部分时间里，人们理解软件的主要方式是编写代码。一旦掌握了一定程度的技能，阅读和讨论代码就能解决大部分问题。（我甚至认为，软件工程师一直过于依赖代码，而不是通过可观测性来理解系统。）
“The real product of a software team is shared understanding”“软件团队真正的产品是共识”
Many great software engineers hold that true product of every (good) software engineering team has always been a shared understanding of the software we own. That it gets stored as cache state in our fragile little meat brains, frequently flushed to disk, deployed to production, committed to github, but our minds are where meaning has always lived.许多优秀的软件工程师认为，每个（优秀的）软件工程团队真正的产品始终是团队对所拥有软件的共识。它以缓存状态的形式存储在我们脆弱的肉脑中，频繁地刷新到磁盘、部署到生产环境、提交到 GitHub，但意义始终存在于我们的思想中。
Is it any wonder that software has always been such a fiercely collectivist endeavor, exquisitely sensitive to relationship dynamics and manners and questions of fairness and emotional valence? It’s exactly what you’d expect when part of your brain lives in other people’s brains, and your collective interdependence is sky high.难怪软件开发一直是一项激烈的集体活动，对人际关系动态、礼仪以及公平和情感价值的问题极其敏感。当你的大脑一部分生活在别人的大脑中，而你们的集体相互依存度极高时，这正是你所预期的结果。
It’s something that I love about this industry. But there’s no denying that minds have been a poor container for certain aspects of the software development model. We are forgetful, distractible, impatient. We are bad at spotting small details, we grow habituated to repetition. Worst of all, the model in our heads diverges massively and perpetually from the world our users interact with.这是我热爱这个行业的一点。但不可否认的是，对于软件开发模型的某些方面来说，人脑一直是一个糟糕的容器。我们健忘、易分心、没耐心。我们不擅长发现微小的细节，我们习惯于重复。最糟糕的是，我们脑海中的模型与用户互动的真实世界之间存在巨大且持续的偏差。
Anyway, SREs have never quite bought that explanation. To us, it’s clear that the true product of every (good) software engineering team is production.总之，SRE（站点可靠性工程师）从未完全接受过那种解释。对我们来说，很明显，每个（优秀的）软件工程团队真正的产品是生产环境。
Only prod is prod. Test in prod, or live a lie.只有生产环境才是生产环境。在生产环境中测试，否则就是自欺欺人。
(This is all backstory. I am getting to the point, I promise.)（这些都是背景故事。我保证，我马上就要说到重点了。）
Turns out, this is an engineering problem after all事实证明，这终究是一个工程问题
We issued our AI mandate last August.5 I had seen enough to know that this was happening, and it was time to do the responsible thing. Honeycomb is a devtools company, and people come to us to help with hard problems on the forefront of technology. I was all in on AI, but I can’t say I was super excited about it, in my heart of hearts.6我们去年八月发布了 AI 准则。5 我已经看到了足够多的迹象，知道这一切正在发生，是时候采取负责任的行动了。Honeycomb 是一家开发工具公司，人们来找我们是为了解决技术前沿的难题。我全力支持 AI，但在内心深处，我不能说我对此感到非常兴奋。6
Then I found Chad Fowler’s writings on Phoenix Architectures.后来我发现了 Chad Fowler 关于 Phoenix Architectures（凤凰架构）的著作。
If you don’t know what I’m talking about, you should honestly stop reading my shit right now and go read his. Chad is the guy who coined the term “immutable infrastructure” in 2013. His best-known essay is “Relocating Rigor”, because Martin Fowler7 mentioned it recapping a Thoughtworks meetup on the future of software. I replied with “Production Is Where the Rigor Goes”, complaining that they didn’t talk about production enough.如果你不知道我在说什么，老实说，你现在就该停止阅读我的文章，去读读他的作品。Chad 是在2013年创造“不可变基础设施”这一术语的人。他最著名的文章是《重置严谨性》（Relocating Rigor），因为 Martin Fowler7 在总结 Thoughtworks 关于软件未来的聚会时提到了它。我当时回复说《生产环境才是严谨性的归宿》，抱怨他们对生产环境谈论得不够。
When I wrote that, I think “Relocating Rigor” was the only piece I had read. But soon I found the rest of it, and after reading two or three essays, it just clicked. I knew exactly what he was talking about. I could predict the rest of what he was going to say. And then, reader…then I got excited.写那篇文章时，我想我只读过《重置严谨性》。但很快我找到了其余部分，读了两三篇后，我豁然开朗。我完全明白他在说什么。我能预见到他接下来要说的内容。然后，读者朋友们……我感到兴奋了。
This has all happened before, and this will all happen again这一切都曾发生过，也终将再次发生
I am going to give you a small sample of Chad quotes, just enough to get the gist. Here’s one from “The Death and Rebirth of Programming.”我将摘录 Chad 的一些引言，让你了解其要点。这是摘自《编程的死亡与重生》的一段：
Immutable infrastructure. Stateless services. Containers. Blue-green deployments. Infrastructure as code.不可变基础设施。无状态服务。容器。蓝绿部署。基础设施即代码。
These ideas all share a common premise: never fix a running thing. Replace it.这些理念都有一个共同的前提：永远不要修复正在运行的东西，而是替换它。
AI pushes this premise beyond infrastructure and into application code itself. When rewriting is cheap, editing in place becomes risky. Mutation accumulates entropy. Replacement resets it.AI 将这一前提从基础设施推向了应用程序代码本身。当重写成本低廉时，原地修改就变得有风险。变异会积累熵，而替换则能重置它。
Another favorite: “The Deletion Test.”另一个最爱是《删除测试》：
Here’s a simple test you can apply to any software system you work on:这里有一个简单的测试，可以应用于你工作的任何软件系统：
Imagine deleting the entire implementation.想象一下删除整个实现。
Most engineers experience deletion as existential. Code feels like the thing. It’s what we write, review, version, deploy, and debug. Losing it feels like losing the system itself.大多数工程师会将删除视为一种存在主义危机。代码感觉就是核心。它是我们编写、审查、版本控制、部署和调试的东西。失去它感觉就像失去了系统本身。
When people say, “We can’t just throw the code away,” what they usually mean is something more precise:当人们说“我们不能直接扔掉代码”时，他们通常指的是更具体的东西：
- We don’t know exactly what behavior is required.我们不知道到底需要什么行为。
- We don’t know which failures are unacceptable.我们不知道哪些故障是不可接受的。
- We don’t know what invariants must always hold.我们不知道哪些不变量必须始终成立。
- We don’t know how to tell if a new version is correct.我们不知道如何判断一个新版本是否正确。
- We don’t know which bugs are intentional fixes for forgotten edge cases.我们不知道哪些 bug 是为了修复被遗忘的边缘情况而刻意留下的。
Those are not code problems. They are evaluation problems.这些不是代码问题，而是评估问题。
Code becomes precious when it is the only place knowledge lives.当代码成为知识存在的唯一载体时，它就变得珍贵了。
and,以及，
For most of software history, treating code as durable was reasonable.在软件历史的大部分时间里，将代码视为持久资产是合理的。
We treated code as permanent because the labor to produce it was the bottleneck. Rewriting was expensive. Re-validation was risky. Implementations accumulated meaning over time. Structure, tests, comments, bug fixes, and tribal knowledge fused into something you learned not to disturb.我们把代码视为永久性的，因为生产它的劳动是瓶颈。重写很昂贵，重新验证有风险。实现随着时间推移积累了意义。结构、测试、注释、bug 修复和部落知识融合在一起，变成了你学会不去触碰的东西。
That made sense when production was the constraint.当生产环境是制约因素时，这很有道理。
When regeneration is easy, code stops being an asset and starts acting as a cache: a materialized view of understanding that is useful while current, disposable when stale.当再生变得容易时，代码就不再是资产，而开始充当缓存：一种理解的物化视图，在当前有效时很有用，在过时时即可丢弃。
“A materialized view of understanding that is useful while current, disposable when stale.” I think that might have been the exact line that made it click in my head.“一种理解的物化视图，在当前有效时很有用，在过时时即可丢弃。”我想这正是让我豁然开朗的那句话。
Do you remember the sysadmins?你还记得系统管理员吗？
I am just barely old enough that my first job title was “System Administrator.” I was a teenager, working at the university, with root on every machine in the days before they learned they should definitely not do that.8我年纪刚好大到第一份工作的头衔是“系统管理员”。那是我十几岁在大学工作的时候，在他们意识到绝对不应该这样做之前，我拥有每台机器的 root 权限。8
I lived through the shift from handcrafted server pets to immutable infrastructure cattle. I didn’t really understand what was happening at the time, but I’ve contemplated it a lot in recent years. I wrote this in the final chapter of Observability Engineering, 2nd edition (now available, download here!):我经历了从“手工打造的服务器宠物”到“不可变基础设施牛群”的转变。当时我并没有真正理解发生了什么，但近年来我思考了很多。我在《可观测性工程》第二版（现已出版，点击此处下载！）的最后一章中写道：
The shift from handcrafted servers to immutable infrastructure taught us that mutability is the sworn enemy of understanding. Any artifact that is edited in place creates drift. Drift is what makes systems impossible to maintain.从手工服务器到不可变基础设施的转变教会我们，可变性是理解力的死敌。任何原地编辑的工件都会产生漂移。漂移正是导致系统难以维护的原因。
Our ability to kill and regenerate infrastructure components is the reason we trust it. At Honeycomb, we kill the oldest Kafka node off via cron every Tuesday. That’s why we are confident in our bootstrapping and balancing processes: everything is repeatable, the data can be regenerated, the commitments live elsewhere.我们能够销毁并重建基础设施组件的能力，是我们信任它的原因。在 Honeycomb，我们每周二通过 cron 任务销毁最旧的 Kafka 节点。这就是为什么我们对引导和负载均衡流程充满信心：一切都是可重复的，数据可以再生，承诺存在于别处。
The fact that we cannot regenerate our code in the same way is a sign that we do not understand it. We do not know which commitments we have made, we do not know which dependencies will break. We find them by breaking them, mostly.我们无法以同样方式再生代码的事实，说明我们并不理解它。我们不知道自己做出了哪些承诺，不知道哪些依赖项会中断。我们通常是通过破坏它们来发现这些问题的。
Think of all the years of your working life you have wasted on painful migrations and rewrites. Think of replacing load-bearing legacy code. Think of all the strangler figs.想想你职业生涯中浪费在痛苦的迁移和重写上的那些年。想想替换承重的老旧代码。想想所有的“绞杀者无花果”模式。
Lines of code have been doing too much. The code has been the bundled up repository of developer intent, user expectations, implicit and explicit behaviors, the only fossilized composite record we have of bugs gone by. It’s too much!代码行数承载了太多东西。代码一直是开发者意图、用户期望、隐式和显式行为的捆绑仓库，是我们拥有的关于过去 bug 的唯一化石复合记录。这太沉重了！
Lines of code are not the ideal artifact to review代码行数不是审查的理想工件
And look at all the domains that have been neglected due to the towering, all-consuming expense of maintaining and mutating lines of code. Where are the artifacts I can review and discuss to understand how our architecture is evolving? Where are our architecture artifacts, period? What if we could discuss and converge on an architecture diagram, and the code could be regenerated from changes to the architecture, instead of the architecture being kinda-sorta inferred from the code?看看那些因为维护和变异代码行的巨大成本而被忽视的领域。我能审查并讨论哪些工件来理解架构是如何演进的？我们的架构工件在哪里？如果我们能讨论并达成架构图的一致，代码就能从架构变更中再生，而不是从代码中推断架构，那该多好？
I am not asserting that all code will eventually be AI-generated to spec, bypassing human understanding. The feasibility of this whole endeavor hangs on the question of what a spec is, or what a spec could be. Anyone who has ever done a painful database migration should have learned some goddamn humility about our ability to extract and formalize users’ expectations in a replayable, automate-able way.我并不是断言所有代码最终都会按规范由 AI 生成，从而绕过人类理解。整个努力的可行性取决于“规范”是什么，或者规范可能是什么。任何做过痛苦数据库迁移的人都应该对我们以可重放、可自动化方式提取和形式化用户期望的能力保持谦逊。
But I think that every step we can take in that direction will be good for us.但我认为，我们朝着这个方向迈出的每一步对我们都有好处。
The tools to do this don’t exist yet, but many of the ideas do exist. Most come from operations and QA, two domains that software engineering has historically been rather snobbish about.实现这一点的工具尚不存在，但许多理念已经存在。大多数来自运维和 QA，这两个领域在历史上一直被软件工程界所轻视。
Those tests and techniques are not about testing for correctness or what ought to be happening, they are about observing and encoding what is happening. Behavioral tests, characterization tests, capture/replay, traffic splitters. Observability (the good kind).这些测试和技术不是为了测试正确性或“应该发生什么”，而是为了观察和编码“正在发生什么”。行为测试、特征测试、捕获/重放、流量分割。可观测性（好的那种）。
Our brains were not built for validation我们的大脑不是为验证而生的
Having nondeterministic code in production is finally forcing us to do the things we should have done all along. Instrumenting with traces. Tests and evals in production. Production is not what happens after development is over, production is a stage of development.生产环境中存在非确定性代码，最终迫使我们做那些本该一直做的事情。使用追踪进行插桩。在生产环境中进行测试和评估。生产环境不是开发结束后才发生的事情，生产环境是开发的一个阶段。
Human brains are not good at validation. The nitpickiness, the repetition. This is the worst thing to be clinging to, y’all. There are so many better things for us to want to preserve and assert for ourselves in the production and maintenance of software. We are never going to beat the machine when it comes to validation—we are literally the weakest link!人脑不擅长验证。那种吹毛求疵、那种重复。这是我们最不该坚持的东西，伙计们。在软件的生产和维护中，有太多更好的东西值得我们去保留和坚持。在验证方面，我们永远无法战胜机器——我们简直是最薄弱的环节！
My money’s on humans for a good long time when it comes to creativity, inspiration, leaps of logic, and a lot of other things, but PLEASE do not rest your killer argument for humans in software on us being the best quality gate. OMG. 
在创造力、灵感、逻辑跳跃等方面，我长期看好人类，但请千万不要把人类在软件领域的杀手锏论点建立在“我们是最好的质量门禁”上。天哪。
Alright. I’m almost done here. Just one more thing.好了，我快说完了。还有最后一件事。
Nondeterministic systems will require more engineering discipline, not less非确定性系统需要更强的工程纪律，而非更弱
I think what many engineers have found so alienating and terrifying about the last two years of AI discourse has been the way so many prominent AI voices appear to be gleefully declaring that software is no longer an engineering problem. “SaaS is dead!” “Making AI great at coding was the strategy that unlocks everything else”, and so on. Even Adam Jacob, one of my dearest friends and someone who is rarely wrong about technology, seems to anticipate a bloodbath of software jobs.9我认为许多工程师在过去两年的 AI 讨论中感到疏离和恐惧的原因是，许多著名的 AI 声音似乎在兴高采烈地宣称软件不再是一个工程问题。“SaaS 已死！”“让 AI 擅长编码是解锁一切的策略”等等。即使是我最亲密的朋友之一、在技术上极少犯错的 Adam Jacob，似乎也预见到软件工作的血雨腥风。9
If 2025 was the year of vibe coding, where AI got as good at generating lines of code as the median software engineer, and the range of possible futures often felt destabilizingly, impossibly wide open, I feel like 2026 is shaping up to be a return to discipline.如果2025年是“氛围编程”之年，AI 在生成代码行数上达到了普通软件工程师的水平，而各种可能的未来往往让人感到不稳定且极其宽泛，那么我觉得2026年正在演变成回归纪律的一年。
The knowledge in our heads is unavailable to AI until we encode it into the system, after all. The returns on those investments will be massive and nonlinear. We might argue that they always would have paid for themselves in the long run. But now every CEO in existence is chomping at the bit to get some of those AI cookies, so let’s give it to them. Discipline first, cookies second.毕竟，在我们将其编码进系统之前，我们脑中的知识对 AI 来说是不可用的。这些投资的回报将是巨大且非线性的。我们或许会争辩说它们从长远来看总是能回本的。但现在每一位 CEO 都急于吃到那些 AI 饼干，所以让我们给他们吧。纪律第一，饼干第二。
This is our chance to bring our engineering values to the mainstream这是我们将工程价值观带入主流的机会
The share of software engineering teams that work in short, fast feedback loops (the cardinal sign of discipline in my book) is, and always has been, appallingly small. Five percent, maybe? Definitely less than 10%. AI tooling brings this more within reach than ever before. Or it can. It could. The discontinuous returns on investment in engineering discipline are real enough that it just might happen.在短而快的反馈循环中工作的软件工程团队比例（在我看来这是纪律的标志）一直少得惊人。5%？肯定不到10%。AI 工具让这一点比以往任何时候都更容易实现。或者说，它可以实现。工程纪律投资带来的不连续回报非常真实，这或许真的会发生。
I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)我并不担心在短期内，AI 会在缺乏工程纪律的情况下创造巨大且不连续的投资回报。（许多人会尝试，看着会很有趣。）
But value is backed by durability, not disposability, and I don’t see that changing. Bits are cheap and fast and governed by the rules of logic and language, but anything with value must ultimately resolve with physical systems: persistence on the one side, user experience on the other.但价值是由持久性支撑的，而不是可丢弃性，我不认为这一点会改变。比特是廉价、快速且受逻辑和语言规则支配的，但任何有价值的东西最终都必须与物理系统达成一致：一端是持久性，另一端是用户体验。
People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends.人们不想每天醒来登录 Slack，发现按钮和菜单都悄悄变了位置。人们不想金融交易只能“大部分时间”成功。确定性不会消失，朋友们。
AI is not magic. This is still engineering. As Adam says, “it’s still technology, and technology needs technologists.” And I for one am looking forward to learning new and interesting engineering problems, reviewing different kinds of artifacts.AI 不是魔法。这仍然是工程。正如 Adam 所说，“这仍然是技术，技术需要技术专家。”而我个人非常期待学习新的、有趣的工程问题，审查不同类型的工件。
And never doing another sticky, picky, two year long API rewrite or strangler fig migration, ever, ever again.并且再也不用进行那种粘稠、挑剔、耗时两年的 API 重写或绞杀者无花果迁移了，永远不用了。
~charity~charity
P.S. Thanks to everyone who read a draft and gave me feedback: Dave Williams, Chad Fowler, Adam Jacob, Mark Ferlatte, Austin Parker, Erwin van der Koogh.附言：感谢所有阅读草稿并给我反馈的人：Dave Williams、Chad Fowler、Adam Jacob、Mark Ferlatte、Austin Parker、Erwin van der Koogh。
Footnotes脚注
- I was not trying to be neutral or even-handed in my last piece, only to give a baseline of courtesy to everyone. But I think it’s revealing how many times I was accused of being “so overly hard on skeptics”, by skeptics, and “so overly hard on enthusiasts”, by enthusiasts, and sometimes simply “It’s sad how some people can’t accept reality” with no indication which side they meant. Lord. ↩︎我在上一篇文章中并没有试图保持中立或公正，只是想对所有人保持基本的礼貌。但我觉得很有趣的是，我被怀疑论者指责“对怀疑论者太严厉”，被狂热者指责“对狂热者太严厉”，有时甚至只是被说“有些人无法接受现实，真可悲”，却没说明他们指的是哪一边。天哪。 ↩︎
- Fred Hebert and I gave the closing keynote at SRECon in March of 2025 where we told SREs they should get to know AI, maybe even try vibe coding (pause for laughs), because otherwise their critiques wouldn’t land as well.
Seriously, that was our big pitch. Learn AI so that you can complain more effectively.
↩︎Fred Hebert 和我在2025年3月的 SRECon 上做了闭幕主题演讲，我们告诉 SRE 们应该去了解 AI，甚至尝试一下“氛围编程”（停顿以引发笑声），因为否则他们的批评就不会那么到位。说真的，这就是我们的大力推介。学习 AI，这样你就能更有效地抱怨。 ↩︎ - Infrastructure, for example. I think this is true of a lot of engineers, btw. I just think it’s really really true of the type of engineer that signs up to be an SRE. Technological pessimism and ADHD, our two most defining traits. ↩︎例如基础设施。顺便说一句，我认为很多工程师都是这样。我只是觉得这对于那些报名成为 SRE 的工程师来说更是如此。技术悲观主义和 ADHD，是我们最显著的两个特征。 ↩︎
- There is a segment of AI enthusiasts who believe we are entering an era of eternal exponential growth, in which the machines begin to build better and better machines, in ways we cannot understand.
I think those people are bad at math. The only thing we know for certain about exponential growth is that it will end. It always does. either in an S curve or a crash. (For a good time, google Heinz van Foerster and “our great-great grandchildren will be squeezed to death.”)
I definitely think we will use machines to build the machines—duh, we already are—but that’s about recursion and specialization. I think the exponential curve we are on the inside of now was created by sloshy free money chasing high returns, plus the properties of software as a function of language and logic, plus the biggest discoveries always happen in the early days of a technology boom, because low hanging fruit gets picked first.
My personal sense—and keep in mind that I am no kind of expert on AI—is that the exponential advancement in AI models leveled out a while ago, and gains are becoming harder to earn and more incremental in nature. I may turn out to be very wrong, of course. But even if there were no more AI innovations moving forwards, the past year has unleashed enough pent-up force to radically reshape the software industry as we know it. Like a pig in a python, we will be dealing with the consequences for a long time to come.
↩︎有一部分 AI 狂热者认为我们正在进入一个永恒指数增长的时代，机器开始以我们无法理解的方式构建越来越好的机器。我认为这些人数学不好。关于指数增长，我们唯一确定的是它终将结束。它总是会结束，要么呈 S 曲线，要么崩溃。（想找乐子的话，去谷歌搜索 Heinz van Foerster 和“我们的玄孙将被挤死”。）我确实认为我们将使用机器来构建机器——废话，我们已经在这么做了——但这关乎递归和专业化。我认为我们现在身处的指数曲线是由追逐高回报的廉价资金、软件作为语言和逻辑函数的属性，以及技术繁荣初期总是发生最大发现（因为容易摘的果子先被摘了）所创造的。我的个人感觉——请记住我不是 AI 专家——是 AI 模型的指数级进步在一段时间前就已经趋于平缓，收益变得更难获得，且本质上更具增量性。当然，我最终可能会错得很离谱。但即使未来不再有 AI 创新，过去一年释放的压抑力量也足以从根本上重塑我们所知的软件行业。就像蟒蛇肚子里的猪，我们将在很长一段时间内处理这些后果。 ↩︎ - More on this coming EXTREMELY soon. Watch the Honeycomb blog! ↩︎更多相关内容即将发布。请关注 Honeycomb 博客！ ↩︎
- The tech is cool, but as a thinking, feeling, breathing human who cares about other people, it can be hard to get excited about anything that so many people are this upset about. It’s also hard to get excited about something when so many of the loudest voices are out there talking gleefully about putting everyone permanently out of work, and so many artists and writers and people from developing nations are talking openly about the impact on them.
Hold your desire to jump in and berate me here, I beg you. Like I said, I will deal with the ethics and morality of using AI in my very next post. Be honest, your attention span is no more up for reading a 10,000-word essay than mine is up for writing one. (Can we blame AI for that too?)
↩︎技术很酷，但作为一个关心他人的有思想、有感情、有呼吸的人，很难对让这么多人感到不安的事情感到兴奋。当最响亮的声音都在兴高采烈地谈论让人永久失业，而许多艺术家、作家和发展中国家的人都在公开谈论其对他们的影响时，也很难对某事感到兴奋。我恳求你，克制住跳出来责骂我的冲动。正如我所说，我将在下一篇文章中处理使用 AI 的伦理和道德问题。说实话，你的注意力并不比我写一篇一万字文章的精力多多少。（我们可以把这个也归咎于 AI 吗？） ↩︎ - “The Other Fowler.” I gather they’ve been making this joke for like… fifty years. ↩︎“另一个 Fowler”。我听说他们开这个玩笑已经开了……五十年了。 ↩︎
- I share a longer version of this story in the second edition of Observability Engineering, chapter 32, downloadable now!!” ↩︎我在《可观测性工程》第二版第32章中分享了这个故事的更长版本，现可下载！！ ↩︎
- Adam is rarely wrong about technology, and I am 100% sure he is living and working in _a_ future of software engineering. I am less sure it is the future we will all be living in. If the hardest part of software has never been writing code—as is my belief—it logically follows that even if the economics of code production drop to zero, the hard parts will still be hard. ↩︎Adam 在技术上很少犯错，我百分之百确定他生活和工作在软件工程的_某个_未来中。我不太确定那是否是我们所有人都会生活在其中的未来。如果软件最难的部分从来不是编写代码——这是我的信念——那么逻辑上讲，即使代码生产的经济学降为零，困难的部分依然会很难。 ↩︎
