AI demands more engineering discipline. Not lessAI 需要更多的工程纪律，而不是更少

If you lived through the shift from handcrafted server pets to immutable infrastructure, you should sense something oddly familiar about what's happening now.如果你经历过从手工打造的服务器宠物到不可变基础设施的转变，你应该会对现在正在发生的事情感到一种奇怪的熟悉感。

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.¹不知怎的，一部分读者认为我在告诉所有人放弃代码审查，立即把他们最糟糕的代码直接推送到生产环境，连看都不看，马上执行。¹

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” code

在 2025 年，问题是 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.²很容易忘记，但在 2025 年的大部分时间里，认为 AI 生成的代码是垃圾，并且可能永远是垃圾，这不仅是一个合理的立场，而且是默认的主流立场。²

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 更像是引爆点。智能体框架（将 LLM 与工具循环包装起来的代码）在 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.³我要对自己和我的同行们说的批评是，我们有时难以接受进步是真实的，错误和边缘情况的持续存在并不能否定这样一个事实：大片的难题空间会随着时间的推移或多或少得到解决，以至于大多数人都可以将其视为理所当然。³

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.⁴ 第一次坚持“眼见为实”是可以原谅的，但第二次就不那么值得原谅了。这就是身处指数级变化曲线内部的感觉，事实证明。⁴

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.⁵ 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.⁶我们在去年八月发布了 AI 指令。⁵ 我已经看到了足够多的迹象，知道这正在发生，是时候做负责任的事情了。Honeycomb 是一家开发工具公司，人们来找我们是为了解决技术前沿的难题。我全力支持 AI，但我不能说在内心深处我对此超级兴奋。⁶

Then I found Chad Fowler’s writings on Phoenix Architectures.然后我发现了 Chad Fowler 关于凤凰架构的著作。

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 Fowler⁷ 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 年创造“不可变基础设施”一词的人。他最著名的文章是《重新定位严谨性》，因为 Martin Fowler⁷ 在回顾一次关于软件未来的 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.我们不知道哪些错误是对被遗忘的边缘情况的有意修复。

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.我们将代码视为永久的，因为生产它的劳动力是瓶颈。重写成本高昂。重新验证有风险。实现随着时间的推移积累了意义。结构、测试、注释、错误修复和部落知识融合成一种你学会不去打扰的东西。

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.⁸我刚好年纪够大，我的第一个职位是“系统管理员”。我当时是个青少年，在大学工作，拥有每台机器的 root 权限，那是在他们意识到绝对不应该这样做之前。⁸

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 (available for download as of Wednesday, June 17th!):我经历了从手工打造的服务器宠物到不可变基础设施牲畜的转变。我当时并不真正理解发生了什么，但近年来我思考了很多。我在《可观测性工程》第二版的最后一章中写道（6 月 17 日星期三起可下载！）：

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! 代码行承担了太多东西。代码一直是开发者意图、用户期望、隐式和显式行为、以及我们拥有的唯一关于过去错误的化石复合记录的捆绑仓库。这太多了！

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! 人类的大脑不擅长验证。挑剔、重复。这是最糟糕的坚持，各位。在软件的生产和维护中，有太多更好的东西值得我们为自己保留和主张。我们在验证方面永远无法击败机器——我们实际上是 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.⁹我认为过去两年 AI 讨论中让许多工程师感到疏远和恐惧的是，许多 prominent AI 声音似乎兴高采烈地宣称软件不再是工程问题。“SaaS 已死！”“让 AI 擅长编码是解锁其他一切的策略”，等等。甚至 Adam Jacob，我最亲爱的朋友之一，一个很少在技术问题上犯错的人，似乎也预见到软件工作岗位的血洗。⁹

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.在短、快反馈循环中工作的软件工程团队的比例（在我看来是纪律的首要标志）一直小得惊人。百分之五？可能吧。肯定不到 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, Ankur Bhatt.P.S. 感谢所有阅读草稿并给我反馈的人：Dave Williams、Chad Fowler、Adam Jacob、Mark Ferlatte、Austin Parker、Erwin van der Koogh、Ankur Bhatt。

1. 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.

2. 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.

3. 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.

4. 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.

5. More on this coming EXTREMELY soon. Watch the Honeycomb blog!

6. 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?)

7. “The Other Fowler.” I gather they’ve been making this joke for like.. fifty years.

8. I share a longer version of this story in the second edition of “Observability Engineering, chapter 32, downloadable later this week!!"

9. 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.