How to Improve at Sensemaking AI?如何提升在AI中的意义建构能力？

Note: This is Part 3 of a short series on sensemaking. You may read Part 2 here.注：本文是意义建构系列短文的第三部分。你可以在此处阅读第二部分。

In Part 1 we discussed one way to make sense of AI without losing your head. In Part 2 we examined the Data-Frame theory for sensemaking, the best theory on sensemaking we currently have. In this third and final part, we’ll bring both pieces together: we’re going to update the ideas from Part 1 with what we now know about the sensemaking process.在第一部分中，我们讨论了一种在不失去理智的情况下理解AI的方法。在第二部分中，我们探讨了意义建构的数据-框架理论，这是目前关于意义建构的最佳理论。在这第三部分也是最后一部分中，我们将把两者结合起来：用我们现在对意义建构过程的了解来更新第一部分的观点。

Before we proceed, it’s worth talking about what our goals are. I think the goals I outlined in Part 1 are still valid: you want to be able to make sense of AI developments for your specific outcomes without becoming emotionally compromised. You don’t want to go on tilt. You don’t want to blindly affected by hype. But you also don’t want to bury your head in the sand, and be taken by surprise when developments outstrip your ability to make sense of them.在继续之前，有必要谈谈我们的目标。我认为我在第一部分中概述的目标仍然有效：你希望能够理解AI发展对你特定目标的影响，而不会情绪失控。你不想陷入情绪波动。你不想盲目受炒作影响。但你也不想把头埋进沙子里，当发展超出你的理解能力时措手不及。

At this point in the series, you already know what sensemaking is, and how it works. You know how sensemaking differs between novices and experts. Most importantly for this piece, you know:在本系列的这个阶段，你已经知道什么是意义建构以及它是如何运作的。你知道新手和专家在意义建构上的区别。最重要的是，对于本文，你需要知道：

• How one major pitfall during sensemaking is frame fixation. This is especially problematic during a period of rapid change, like what we are currently facing with AI.意义建构中的一个主要陷阱是框架固化。这在快速变化时期尤其成问题，比如我们目前面临的AI变革。
• You also know that you may improve your sensemaking skills by gathering fragments from related domains. I demonstrated this by giving you a fragment from the PC revolution at the end of the previous essay. I said that the fragment will likely change the way you make sense of this current AI shift — and perhaps you’ve already experienced this for yourself. Now, of course, the question becomes: how should you seek out and expand the number of case fragments in your head?你还知道，通过收集相关领域的片段，你可以提高意义建构能力。我在上一篇文章末尾通过提供一个来自PC革命的片段来演示这一点。我说过这个片段很可能会改变你对当前AI变革的理解方式——也许你已经亲身体验到了。现在，问题自然变成了：你应该如何寻找并扩展你脑海中的案例片段数量？

We’re going to address these two questions, in order.我们将按顺序解决这两个问题。

In order to illustrate these ideas, I want to ground this piece in a real domain: the practice of software engineering. I have chosen this domain because it is the domain that AI has currently made the biggest impact. To be precise, I want to discuss an ongoing controversy between three groups of programmers, each operating from three different frames.为了说明这些观点，我想将本文立足于一个真实领域：软件工程实践。我选择这个领域是因为它是目前AI影响最大的领域。具体来说，我想讨论三个程序员群体之间的一场持续争议，他们各自从三个不同的框架出发。

I should note that while this controversy is dear to me, it is not the main point of this essay. (I graduated with a Computer Science degree, worked as a software engineer for a few years; many of my friends are software engineers). This controversy is a snapshot of the industry I am (was) closest to, but it will likely take on different forms as AI spreads and impacts other fields. I’m merely using this domain as an example because it is concrete, and because it is instructive to examine the industry’s various reactions to AI. The sensemaking response we’re going to see is universal.我应该指出，虽然这场争议对我来说很重要，但它并不是本文的重点。（我拥有计算机科学学位，曾担任软件工程师数年；我的许多朋友都是软件工程师）。这场争议是我最接近（曾经最接近）的行业的一个快照，但随着AI的传播并影响其他领域，它可能会以不同的形式出现。我只是用这个领域作为例子，因为它具体，并且审视行业对AI的各种反应具有启发性。我们将看到的意义建构反应是普遍的。

The AI Programming ControversyAI编程争议

You may skip this bit if you’re already familiar with the events I’m about to describe. In November 2025, knowledge that AI coding agents were good enough suddenly hit a tipping point. Within a span of weeks it seemed like everyone was giving Claude Code a go. Non technical folks were ‘vibe-coding’ throwaway apps; programmers from across the industry began using agentic coding tools to boost productivity.如果你已经熟悉我将要描述的事件，可以跳过这部分。2025年11月，AI编码代理足够好的消息突然达到了一个临界点。在几周内，似乎每个人都在尝试Claude Code。非技术人员在用‘氛围编码’制作一次性应用；来自各行各业的程序员开始使用代理编码工具来提高生产力。

An Anthropic ethnographic report from 2nd December 2025 outlined some of the impacts experienced by Anthropic’s software engineers over the preceding six months. The report serves as a useful snapshot of the effects felt within the industry at the time. Within weeks, I had corroborated many of the claims from the report with posts from social media, from conversations with friends, and eventually from my own personal experience with the tools:2025年12月2日的一份Anthropic人种志报告概述了Anthropic软件工程师在过去六个月中经历的一些影响。该报告是当时行业内感受到的影响的一个有用快照。几周内，我从社交媒体、与朋友的对话以及最终自己使用这些工具的个人经验中证实了报告中的许多说法：

Engineers tend to delegate tasks that are easily verifiable, where they “can relatively easily sniff-check on correctness”, low-stakes (e.g. “throwaway debug or research code”), or boring (“The more excited I am to do the task, the more likely I am to not use Claude”). Many describe a trust progression, starting with simple tasks and gradually delegating more complex work—and while they’re currently keeping most design or “taste” tasks, this boundary is being renegotiated as models improve.

(…) Claude enables people to broaden their skills into more areas (of software engineering (“I can very capably work on front-end, or transactional databases... where previously I would've been scared to touch stuff”), but some employees are also concerned, paradoxically, about the atrophy of deeper skillsets required for both writing and critiquing code—“When producing output is so easy and fast, it gets harder and harder to actually take the time to learn something.”

(…) Some engineers embrace AI assistance and focus on outcomes (“I thought that I really enjoyed writing code, and I think instead I actually just enjoy what I get out of writing code”); others say that “there are certainly some parts of [writing code] that I miss.”

(…) Employees estimated that 27% of their Claude-assisted work wouldn't have been done without it. Engineers cited using AI for scaling projects, nice-to-haves (e.g. interactive data dashboards), useful but tedious work like documentation and testing, and exploratory work that wouldn't be cost-effective manually. As one person explained, they can now fix more “papercuts” that previously damaged quality of life, such as refactoring badly-structured code, or building “small tools that help accomplish another task faster.” We looked for this in our usage data analysis as well, and found that 8.6% of Claude Code tasks involve ‘papercut fixes.’工程师倾向于委派那些容易验证的任务，他们‘可以相对容易地嗅探检查正确性’、低风险（例如‘一次性调试或研究代码’）或无聊的任务（‘我对任务越兴奋，就越可能不使用Claude’）。许多人描述了一种信任进展，从简单任务开始，逐渐委派更复杂的工作——虽然他们目前保留大多数设计或‘品味’任务，但随着模型的改进，这一边界正在重新协商。(…) Claude使人们能够将技能扩展到软件工程的更多领域（‘我能非常胜任地处理前端或事务数据库……以前我会害怕碰这些东西’），但一些员工也矛盾地担心更深层次技能集的萎缩，这些技能对于编写和批评代码都是必需的——‘当产出如此容易和快速时，实际上越来越难花时间去学习某些东西。’(…) 一些工程师拥抱AI辅助并专注于结果（‘我以为我真的很喜欢写代码，但我想实际上我只是喜欢写代码带来的成果’）；另一些人说‘写代码的某些部分我确实怀念。’(…) 员工估计，他们27%的Claude辅助工作如果没有它就不会完成。工程师提到使用AI来扩展项目、锦上添花（例如交互式数据仪表板）、有用但繁琐的工作（如文档和测试），以及手动操作成本不高的探索性工作。正如一个人解释的那样，他们现在可以修复更多以前损害生活质量的‘小问题’，例如重构结构糟糕的代码，或构建‘有助于更快完成其他任务的小工具’。我们也在使用数据分析中寻找这一点，并发现8.6%的Claude Code任务涉及‘小问题修复’。

These responses were from a sample of Anthropic’s own software engineers, which meant that it was positively biased: if you work at a frontier AI lab, you are more likely to adopt AI technologies and you are also more likely to have a positive reaction to them.这些回应来自Anthropic自己的软件工程师样本，这意味着存在正面偏差：如果你在AI前沿实验室工作，你更可能采用AI技术，也更可能对其有积极反应。

However, over the course of the subsequent few months, broad AI coding agent adoption began to cause second and third-order effects throughout the industry:然而，在接下来的几个月里，AI编码代理的广泛采用开始在行业内产生二阶和三阶效应：

• Senior developers began to grapple with less conscientious colleagues who would inflict large, unreviewed AI-generated pull requests on teammates. Many of these colleagues were more junior engineers, relatively inexperienced in the practice of software engineering, who were running wild with the new affordances of AI agents. Some devs have had to deal with AI-pilled bosses with subpar engineering skills spraying buggy slop all across their codebase. Collectively, the industry began talking about how ‘code review’ was rapidly becoming the bottleneck for software development.高级开发人员开始应对那些不太认真的同事，他们会向团队提交大量未经审查的AI生成拉取请求。这些同事中许多是相对缺乏软件工程实践经验的初级工程师，他们正在滥用AI代理的新功能。一些开发者不得不应对AI中毒的老板，他们工程技能欠佳，却在代码库中散布大量错误代码。整个行业开始讨论‘代码审查’如何迅速成为软件开发的瓶颈。
• Open source projects began to be overwhelmed with ‘slop’ code contributions. One famous instance was the curl creator, Daniel Stenberg, “putting his foot down on all AI slop security reports” on 4th May 2025, as a result of a particularly bad submission. Just a few months later though, Stenberg reported a successful AI-augmented report from Joshua Rogers. “Mostly smaller bugs, but still bugs and there could be one or two actual security flaws in there. Actually truly awesome findings (…) I have already landed 22(!) bugfixes thanks to this.” On the other hand, the Zig project announced ‘the most stringent anti-LLM policy of any major open source project’ — and for good reason.开源项目开始被‘垃圾’代码贡献淹没。一个著名的例子是curl创建者Daniel Stenberg在2025年5月4日‘对所有AI垃圾安全报告踩刹车’，原因是收到了一份特别糟糕的提交。然而仅仅几个月后，Stenberg报告了来自Joshua Rogers的一份成功的AI增强报告。‘主要是较小的错误，但仍然是错误，可能有一两个实际的安全漏洞。实际上非常棒的发现（……）我已经因此合并了22个（！）错误修复。’另一方面，Zig项目宣布了‘任何主要开源项目中最严格的反LLM政策’——而且理由充分。
• Prominent developers began publishing field reports about how AI coding agents have accelerated their development work — and in some cases made possible bug fixes and feature implementations they would’ve never considered, since these would have taken too much effort and too much time.知名开发者开始发布关于AI编码代理如何加速开发工作的实地报告——在某些情况下，它们使错误修复和功能实现成为可能，而这些他们以前从未考虑过，因为需要太多精力和时间。
• Tech companies began to announce layoffs under the banner of AI adoption. The most prominent of this was Block, which announced a 40% cut in late Feb 2026, purportedly as a result of AI productivity gains. This was roundly criticised as cover for historically terrible business execution.科技公司开始以AI采用为名宣布裁员。其中最突出的是Block，它在2026年2月底宣布裁员40%，据称是由于AI生产力提升。这被广泛批评为掩盖历史上糟糕的业务执行。
• The public valuations of SaaS (Software-as-a-Service) companies crashed over the course of February 2026 in reaction to the advancement of AI coding agents.SaaS（软件即服务）公司的公开估值在2026年2月期间暴跌，以应对AI编码代理的进步。
• Cloudflare published a report on 24th February 2026, announcing that they had successfully cloned Next.js, a popular open source React framework that is owned by Vercel, a competitor, in ‘one week and with $1000 worth of tokens’. The new framework had zero dependencies on Vercel’s platform. This was notable because it eroded one of Vercel’s core competitive advantages.Cloudflare于2026年2月24日发布报告，宣布他们成功克隆了Next.js——一个由竞争对手Vercel拥有的流行开源React框架——‘用了一周时间和价值1000美元的令牌’。新框架对Vercel的平台零依赖。这值得注意，因为它侵蚀了Vercel的核心竞争优势之一。
• Somewhat related to Cloudflare’s move, AI-augmented ‘clean room’ software reimplementations began to emerge. This was alarming because such reimplementations could be released under a different license, allowing companies to get around software license restrictions.与Cloudflare的举动有些相关，AI增强的‘洁净室’软件重新实现开始出现。这令人担忧，因为这种重新实现可以在不同许可证下发布，使公司能够绕过软件许可证限制。

In response to this spread, software engineers began to fracture into three groups.针对这种蔓延，软件工程师开始分裂成三个群体。

The first group is the “never AIs”. This group consists of folks who have attempted to use AI for computer programming in the past, and have concluded that it cannot work. Perhaps they reject it for ethical reasons. Perhaps they work in companies with sloppy AI-use mandates, and they resist bad technology being foisted onto them. Or perhaps they cannot see a path for this fundamentally probabilistic technology to lead to real solutions. For whatever reason, they resist AI use and are justified in doing so.第一个群体是‘永不AI者’。这个群体包括那些过去尝试过将AI用于计算机编程并得出结论认为它行不通的人。也许他们出于道德原因拒绝它。也许他们在有草率AI使用指令的公司工作，抵制强加给他们的糟糕技术。或者他们看不到这种根本上概率性的技术如何能带来真正的解决方案。无论出于何种原因，他们抵制AI使用，并且这样做是有道理的。

The second group consists of ‘pragmatic AI adopters’. These software engineers see themselves as grounded folks who need to get stuff done. They use AI tools, but they continue to hold on to existing software development best practices. “The fundamentals have not changed” they say, “You still have to review every line of code you generate, because you are ultimately responsible for it.” They link to reports that show that software teams with good practices benefit more from AI than those with terrible software engineering practices. They heap scorn on those who hype AI uncritically. They have used enough AI to know that AI works well when applied in such-and-such manner, but frontier models continue to fail miserably on a range of idiosyncratic tasks. These field reports reflect the constraints of the real codebases they labour under.第二个群体由‘务实AI采用者’组成。这些软件工程师视自己为务实的人，需要完成任务。他们使用AI工具，但继续坚持现有的软件开发最佳实践。‘基本原则没有改变，’他们说，‘你仍然需要审查你生成的每一行代码，因为你最终要对其负责。’他们引用报告显示，拥有良好实践的软件团队从AI中获益更多，而那些软件工程实践糟糕的团队则不然。他们对不加批判地炒作AI的人嗤之以鼻。他们使用AI足够多，知道AI在某种方式下应用效果良好，但前沿模型在一系列特殊任务上仍然惨败。这些实地报告反映了他们所在真实代码库的约束。

You may or may not have noticed this, but every single field report I linked to, above, is a report from one of these folks. Mitchell Hashimoto (the founder of Hashicorp), Armin Ronacher (the creator of Flask and founder of the Pallets project), and Salvatore Sanfilippo (antirez, the creator of Redis) all belong to this group. They inhabit a frame where adopting AI is inevitable, but there is no need to radically update one’s understanding of the Software Development Life Cycle (SDLC).你可能已经注意到，上面我链接的每一份实地报告都来自这些人。Mitchell Hashimoto（Hashicorp创始人）、Armin Ronacher（Flask创建者和Pallets项目创始人）和Salvatore Sanfilippo（antirez，Redis创建者）都属于这个群体。他们所处的框架是：采用AI是不可避免的，但无需从根本上更新对软件开发生命周期（SDLC）的理解。

I identify the most with this second group. I was trained as a software engineer, and whilst I am not believable on the discipline (I was only ever a software engineer for a handful of years before becoming a business manager), the frame that these folks inhabit are familiar and comfortable. I like the idea of writing clean, beautiful code. I like it even though I have written literally thousands of lines of messy code under the weight of crushing deadlines, often casting aside my manager hat in order to ship certain deliverables on time. By my own calculations, my shit code has generated millions of dollars of profit for my old company — which should make the businessperson in me feel good. In truth, however, I mostly feel icky. My frame is “the collective knowledge of good software engineering is real, and it is worthwhile to make good software.”我最认同第二个群体。我受过软件工程师培训，虽然我在该学科上并不可信（我在成为业务经理之前只做了几年软件工程师），但他们所处的框架让我感到熟悉和舒适。我喜欢编写干净、优美代码的想法。即使我在紧迫的截止日期压力下写过数千行混乱的代码，经常为了按时交付某些成果而摘下经理帽子，我仍然喜欢这个想法。根据我自己的计算，我的糟糕代码为我的老公司创造了数百万美元的利润——这应该让商人感觉良好。但实际上，我大多感到恶心。我的框架是‘优秀软件工程的集体知识是真实的，制作优秀软件是值得的。’

And so it is the frame of a third group that has posed a challenge for me. Some folks in Commoncog’s private members forum call this the ‘software dark factory folks’. Folks in this group believe that it is possible to have AI coding agents write code with little to no human intervention. That is — AI agents generate code at a high velocity, AI agents review the code, and AI agents ship the code, with no human in the loop. The approach calls for “building the machine that builds the software.” I’ve linked to a few of their field reports before. For instance, on 29th September 2025, Microsoft Deputy CTO Sam Schillace published I Have Seen The Compounding Teams — which asserted that the ‘dark factory’ pattern was possible, though it takes the average team six months to get to this point. He followed this up with throwaway remarks on 16th March 2026 (The Rise of Taste) and 23rd March 2026 (Why Not vs What If) — roughly six months later, saying that he’d gotten Microsoft Research’s internal ‘dark factory’ agent harness working for himself. On February 11 2026, OpenAI published Harness engineering: leveraging Codex in an agent-first world. If you read that post carefully, you’ll notice lots of odd little details required to get such an approach to work, justifying Shillace’s ‘six months’ observation. And there are other such reports if you know how to look, sometimes from folks who are cautiously experimenting with the idea (Justin Cormack, Adam Jacob, Simon Willison on StrongDM).因此，第三个群体的框架对我构成了挑战。Commoncog私人会员论坛中的一些人称其为‘软件暗工厂’群体。这个群体的人相信，AI编码代理可以在几乎没有人为干预的情况下编写代码。也就是说——AI代理高速生成代码，AI代理审查代码，AI代理发布代码，没有人在循环中。这种方法要求‘构建构建软件的机器’。我之前链接过他们的一些实地报告。例如，2025年9月29日，微软副CTO Sam Schillace发表了《我看到了复合团队》——断言‘暗工厂’模式是可能的，尽管平均团队需要六个月才能达到这一点。他在2026年3月16日（《品味的崛起》）和2026年3月23日（《为什么不》 vs 《如果呢》）——大约六个月后——发表了随口评论，说他为自己让微软研究院内部的‘暗工厂’代理工具集工作起来了。2026年2月11日，OpenAI发表了《工具工程：在代理优先的世界中利用Codex》。如果你仔细阅读那篇文章，你会注意到许多使这种方法奏效所需的奇怪小细节，证实了Schillace的‘六个月’观察。如果你知道如何寻找，还有其他这样的报告，有时来自谨慎尝试这个想法的人（Justin Cormack、Adam Jacob、Simon Willison关于StrongDM的文章）。

What is really clear is that these folks are inhabiting a radically different frame compared to the second group. More importantly, folks in the second group cannot accept the frame inhabited by the software dark factory folks.非常清楚的是，这些人所处的框架与第二个群体截然不同。更重要的是，第二个群体的人无法接受软件暗工厂群体所处的框架。

I’m not the only person to have noticed the existence of these three groups, of course. The aforementioned Adam Jacob did a podcast recently where he described the three groups in nearly the same terminology, and reflected a little on how he relates to each of them.当然，我不是唯一注意到这三个群体存在的人。前面提到的Adam Jacob最近在一个播客中描述了这三个群体，几乎使用了相同的术语，并反思了他与每个群体的关系。

And I think it’s instructive to take a look at what Jacob has been saying, and how other software engineers from the ‘pragmatic AI adopters’ group are reacting to him. Here’s a March 17th 2026 LinkedIn post (all bold emphasis mine):我认为审视Jacob所说的话以及‘务实AI采用者’群体中的其他软件工程师如何回应他是很有启发性的。以下是2026年3月17日的一篇LinkedIn帖子（所有粗体强调均为我所加）：

I’ve seen a couple things floating around to the effect that “I’ve been using Claude and I’m not more productive than I was before, because it writes unmaintainable code.” I resonate with that experience — it’s the same one I was having for months, where what felt true was that this was good for prototypes, but fell apart under its own weight inevitably. If you’re using Claude Code/Codex/Cursor on a large existing code base, built by hand through careful crafting by a team, over the course of years (decades) — this is almost certainly your experience.

Contrast that with our experience building Swamp this way from scratch. We’re paying a lot of attention to architecture. We’re paying very little attention to the code. We’re using agents at every stage of the SDLC — we have skills that express our architecture patterns, design documents, adversarial review, comprehensive UAT. It’s the highest trust team environment I’ve ever been in, because each person is capable of shipping basically anything they want in a timeframe that feels bonkers (we shipped remote execution for workflow jobs in an afternoon, for example.) We spend as much time automating the SDLC as we do writing the product (I expect this to slow down eventually)

Today it’s hard to see how existing teams move to work like we’re working. Tomorrow it won’t be. Don’t fall into the false comfort of believing that because your current situation (socially, technically) makes this shift hard to do, it isn’t coming to your team eventually, or won’t work at scale. We will figure all of those things out as an industry.

The best thing to do today is experience it for yourself. It’s too early to solidify a pattern, or to claim perfect knowledge of the end shape. It’s changing every day. But consensus will emerge, because there won’t be 1000 working patterns.我看到一些东西在流传，大意是‘我一直在使用Claude，但并没有比以前更高效，因为它编写了不可维护的代码。’我对此有共鸣——这正是我几个月来的体验，感觉上它对于原型很好，但不可避免地会自行崩溃。如果你在一个由团队精心手工构建多年（几十年）的大型现有代码库上使用Claude Code/Codex/Cursor——这几乎肯定是你的体验。相比之下，我们从头开始以这种方式构建Swamp的体验。我们非常关注架构。我们很少关注代码。我们在SDLC的每个阶段都使用代理——我们有表达架构模式、设计文档、对抗性审查、全面UAT的技能。这是我经历过的最信任的团队环境，因为每个人都能在感觉疯狂的时间框架内发布他们想要的任何东西（例如，我们在一个下午内发布了工作流的远程执行。）我们花在自动化SDLC上的时间和编写产品的时间一样多（我预计这最终会放缓）。今天很难看到现有团队如何转向像我们这样的工作方式。明天就不会了。不要陷入虚假的安慰，认为因为你当前的情况（社交上、技术上）使这种转变难以实现，它就不会最终来到你的团队，或者无法大规模运作。我们将作为一个行业解决所有这些问题。今天最好的事情是亲自体验它。现在固化模式或声称对最终形态有完美了解还为时过早。它每天都在变化。但共识将会出现，因为不会有1000种有效模式。

If you feel some discomfort with his remarks, you’re not alone. From the comments to that post:如果你对他的言论感到有些不适，你并不孤单。从该帖子的评论来看：

This is your opinion and it is wrong.这是你的观点，而且是错误的。

“it doesn't work but tomorrow it will but I'm going to offer no evidence”?‘它现在不行，但明天会行，但我不提供任何证据’？

Are you suggesting that over the last two decades no company who is writing software has scaled? Because your claim is “if you’re not doing it precisely the way we’re doing it now, you won’t scale”… which… seems like perhaps too broad a claim.你是在暗示过去二十年没有一家编写软件的公司实现了规模化吗？因为你的说法是‘如果你不精确地按照我们现在的方式做，你就无法规模化’……这……似乎是一个过于宽泛的说法。

These are comments from folks who inhabit the ‘pragmatic software engineer’ frame, and they cannot accept anything Jacob is saying. Why? This is quite easy to understand, because we now have the language of the Data-Frame theory of sensemaking. Humans construct data within the context of a frame. Nothing Jacob says makes sense within the existing software engineering frame (see all the bolded bits above). The only way to understand Jacob (and Shillace, and others) is to construct a new frame — the one that they’re operating in. You’re going to need to find a few new anchors to construct their frame in order to accept what they’re describing.这些评论来自‘务实软件工程师’框架的人，他们无法接受Jacob所说的任何话。为什么？这很容易理解，因为我们现在有了意义建构的数据-框架理论的语言。人类在框架的背景下构建数据。Jacob所说的任何话在现有的软件工程框架内都没有意义（见上面所有粗体部分）。理解Jacob（以及Schillace等人）的唯一方法是构建一个新框架——他们正在运作的那个框架。你需要找到一些新的锚点来构建他们的框架，以便接受他们所描述的内容。

And you can already guess what I’m going to say. The danger is that it turns out this third group is right. If software dark factories are possible, then the entire practice of software engineering is going to change. But how can you take the software dark factory folks seriously when you encounter incredibly stupid coding agent behaviours in your own day-to-day work? Nothing they say lines up with your own frame; all their ‘data points’ are off-the-cuff remarks that may be rejected due to your own lived experiences.你已经可以猜到我要说什么了。危险在于，结果证明第三个群体是正确的。如果软件暗工厂是可能的，那么整个软件工程实践都将改变。但是，当你在日常工作中遇到极其愚蠢的编码代理行为时，你怎么能认真对待软件暗工厂的人呢？他们说的任何话都与你的框架不符；他们所有的‘数据点’都是随口评论，可能被你自己的亲身经历所否定。

“They’re lying,” you think to yourself. “They can’t possibly be right; their brains are eaten by hype.” And so you ignore them and stick to your existing frame.‘他们在撒谎，’你对自己说。‘他们不可能是对的；他们被炒作冲昏了头脑。’所以你忽略他们，坚持你现有的框架。

Technique One: Fill in an Alternate Frame技巧一：填充一个替代框架

Avoiding frame fixation sounds easy when it’s about another person’s domain. It’s less easy when a) it’s about your own domain, b) when the new frame goes against everything you believe about your own hard-won expertise, and c) when the new frame is fundamentally uncertain.当涉及他人的领域时，避免框架固化听起来很容易。但当a）涉及你自己的领域，b）新框架与你对自己来之不易的专业知识的所有信念相悖，以及c）新框架根本不确定时，就不那么容易了。

I want to talk about that last point for a bit. We do not know if these ‘software dark factories’ are possible. I’m not saying that the folks writing field reports are lying, or that the benefits they’re already seeing are fake. I’m saying that we can’t know what the tradeoffs are, and where the limits of this approach lies. Nobody can. This is a new technology with new affordances. Nobody can know what’s possible here. This is what uncertainty feels like.我想稍微谈谈最后一点。我们不知道这些‘软件暗工厂’是否可能。我不是说写实地报告的人在撒谎，或者他们已经看到的好处是假的。我是说我们无法知道权衡是什么，以及这种方法的极限在哪里。没有人能知道。这是一项具有新功能的新技术。没有人能知道这里什么是可能的。这就是不确定性的感觉。

But I think it’s also true that you need to take this ‘dark factory’ frame seriously. There are enough field reports now from enough unrelated people that indicate that something is going on. More importantly, the potential impact on your career — if you are a software engineer — is too large to ignore.但我也认为你需要认真对待这个‘暗工厂’框架。现在有足够多的来自足够多不相关的人的实地报告表明有些事情正在发生。更重要的是，如果你是一名软件工程师，它对你职业生涯的潜在影响太大，不容忽视。

Thankfully, the Data-Frame theory already offers us one way out: you don’t have to believe their frame. You may hold on to your current frame, and elaborate a second frame in parallel. Folks who believe humans are Bayesian updaters won’t have this cognitive move available to them — they will think that the way to integrate new data is to do careful updating on their priors, with a belief score assigned to new developments. But if you take the Data-Frame theory seriously, you’ll know that you can do what many experts across different domains do: hold an alternative frame in abeyance, and use the human brain’s natural tendency for confirmation ‘bias’ to elaborate said frame. You may then switch to (or discard) the second frame later if you wish.幸运的是，数据-框架理论已经为我们提供了一种出路：你不必相信他们的框架。你可以坚持你当前的框架，同时并行阐述第二个框架。那些认为人类是贝叶斯更新者的人将无法使用这种认知策略——他们会认为整合新数据的方法是在先验概率上仔细更新，并为新进展分配信念分数。但如果你认真对待数据-框架理论，你会知道你可以做许多不同领域专家所做的事情：暂时搁置一个替代框架，并利用人类大脑自然的确认‘偏见’倾向来阐述该框架。然后，如果你愿意，你以后可以切换到（或丢弃）第二个框架。

The thing that did it for me was a senior software engineer taking me aside and saying “Cedric, I don’t think you’re taking the implications of cheap code seriously enough.” That disequilibriated me sufficiently to rethink my beliefs. If we translate what this engineer was saying to the language of the Data-Frame theory, what he was saying was that one of the anchors of my current frame was now invalidated. And indeed, he continued: “So many of our existing practices are built around the idea that code is expensive to write. Code is cheap now. What does that change?”让我改变想法的是，一位资深软件工程师把我拉到一边说：‘Cedric，我认为你没有足够认真地对待廉价代码的影响。’这让我足够失衡，重新思考我的信念。如果我们把这位工程师的话翻译成数据-框架理论的语言，他是在说我当前框架的一个锚点现在无效了。确实，他继续说：‘我们现有的许多实践都是建立在代码编写成本高昂的想法之上的。现在代码便宜了。这改变了什么？’

Once you discard that anchor, it becomes easier to construct a new frame. This happened to me around three months ago. And then I started noticing something interesting.一旦你丢弃那个锚点，构建一个新框架就变得更容易了。这大约在三个月前发生在我身上。然后我开始注意到一些有趣的事情。

Nearly every software engineer who was open to this new frame had a prior professional experience where a core anchor in their domain was invalidated. In March, I interviewed a handful of senior engineers who were experimenting with this third frame. One of them told me: “When I was younger and the cloud was starting to take off, there was this new belief that servers could be treated as discardable. You know (the saying) ‘cattle not pets’? Well, the first time I heard this, I didn’t understand how it could be possible. It was crazy! Then we learnt about Netflix’s chaos engineering — and that seemed crazy! And yet it was possible, and it changed the way we did devops over the subsequent decade.”几乎所有对这个新框架持开放态度的软件工程师都有过之前的职业经历，其中他们领域的一个核心锚点被证明无效。三月份，我采访了几位正在尝试这第三个框架的高级工程师。其中一位告诉我：‘当我年轻的时候，云开始兴起，有一种新的信念认为服务器可以被视为可丢弃的。你知道（那句谚语）‘牲畜不是宠物’吗？我第一次听到这个时，不明白它怎么可能。这太疯狂了！然后我们了解到Netflix的混沌工程——那看起来也很疯狂！然而它是可能的，并在随后的十年里改变了我们做DevOps的方式。’

I was in university whilst this transition was happening, so I wasn’t affected by it; ‘cattle not pets’ had already become widespread when I graduated. The idea went something like this: once upon a time, servers — the computers that ran your websites, or your enterprise software — were expensive to provision. As a result, most servers were long-lived. The sysadmins who managed such servers would often run one-off maintenance scripts, or, hell, log into those servers to run maintenance commands manually. Over time, most servers became unique creatures that carried idiosyncratic configurations. It became scary to migrate off them, and it was often a major ceremony to provision new servers.这个转变发生时我正在上大学，所以我没有受到影响；‘牲畜不是宠物’在我毕业时已经广泛传播。这个想法大致是这样的：曾几何时，服务器——运行你的网站或企业软件的计算机——配置成本高昂。因此，大多数服务器都是长寿的。管理这些服务器的系统管理员经常运行一次性维护脚本，或者，见鬼，手动登录服务器执行维护命令。随着时间的推移，大多数服务器变成了携带特殊配置的独特生物。迁移离开它们变得可怕，配置新服务器通常是一个重大仪式。

Then, in 2006, Amazon launched AWS. What we now know as ‘the cloud’ emerged over the next decade. With the cloud came a new anchor, from which a new frame may be constructed: servers were cheap to provision. Hell, with AWS you could detect that your servers were overloaded, and programmatically spin up new servers on the fly. You could also reverse this: detect that load had gone down and spin those servers down again. Hence ‘cattle not pets’ — treat your servers as discardable cattle, not unique pets.然后，在2006年，亚马逊推出了AWS。我们现在所知的‘云’在接下来的十年中出现了。随着云的出现，出现了一个新锚点，从中可以构建一个新框架：服务器配置成本低廉。见鬼，使用AWS，你可以检测到服务器过载，并自动即时启动新服务器。你也可以反过来做：检测到负载下降并再次关闭这些服务器。因此‘牲畜不是宠物’——将你的服务器视为可丢弃的牲畜，而不是独特的宠物。

This change created an entirely different way to think about software deployments. It saw the rise of new tooling which enabled large scale server orchestration. It changed the contract between software developers and sysadmins. It enabled crazy new approaches to resilience, like Netflix’s Chaos Monkey — which was software that would randomly turn off servers within Netflix’s production environment, so that software developers would be forced to build resilient software.这种变化创造了一种完全不同的思考软件部署的方式。它催生了新的工具，实现了大规模服务器编排。它改变了软件开发人员和系统管理员之间的契约。它实现了疯狂的新弹性方法，比如Netflix的混沌猴子——这是一种软件，会随机关闭Netflix生产环境中的服务器，迫使软件开发人员构建弹性软件。

Everything I’m describing sounds trite today, but it was unimaginable just a few years earlier. The movement itself took five to seven years for the transition to spread throughout the entire software industry. Some folks worked in organisations that could adopt this new way of doing things quickly. Others found it harder. As with all socio-technical shifts, the social bits of the shift takes longer than you might expect.我今天描述的一切听起来很老套，但在短短几年前还是不可想象的。这一运动本身花了五到七年时间才在整个软件行业传播开来。有些人在能够快速采用这种新工作方式的组织中工作。其他人发现更难。与所有社会技术转变一样，转变的社会部分花费的时间比你预期的要长。

Many of the names I’ve cited above have come from this transition:我上面引用的许多名字都来自这个转变：

• Adam Jacob created Chef (the DevOps automation and server infrastructure management software) and was the co-founder of Opsware, the company that now controls Chef.Adam Jacob创建了Chef（DevOps自动化和服务器基础设施管理软件），并且是Opsware的联合创始人，该公司现在控制着Chef。
• Justin Cormack was CTO of Docker, and oversaw the transition from VMs to containers as the unit of software deployment. (His attempt at replicating Amazon’s object store service, S3, using ‘software dark factory methods’ is linked above. I suspect he’s elaborating a parallel frame with that project — he hasn’t fully committed to the software dark factory frame but wants to see what the limits are.)Justin Cormack是Docker的CTO，监督了从虚拟机到容器作为软件部署单元的转变。（他尝试使用‘软件暗工厂方法’复制亚马逊的对象存储服务S3的链接在上面。我怀疑他正在用那个项目阐述一个并行框架——他还没有完全致力于软件暗工厂框架，但想看看极限在哪里。）
• Sam Shillace, Microsoft’s Deputy CTO, did not come from the DevOps transition, but created the software that eventually became Google Docs. He writes, in a recent post reflecting on this AI transition: “I had the privilege of being on the founding team of what became Google Docs. It was an interesting experience in many ways, but one of them was experiencing firsthand the dissonance between people telling me it was a terrible idea (not just Writely, but the cloud overall), and the half million or so people who were using and loving it.”Sam Shillace，微软副CTO，并非来自DevOps转变，但创建了最终成为Google Docs的软件。他在最近一篇反思AI转变的文章中写道：‘我有幸成为后来成为Google Docs的创始团队的一员。这在很多方面都是一次有趣的经历，但其中之一是亲身体验了人们告诉我这是一个糟糕的主意（不仅仅是Writely，而是整个云），与大约50万正在使用并喜爱它的人之间的不协调。’

What is common here? It is this: they all experienced a transition where one of the anchors of their previous frame had been invalidated. And then their careers benefited massively from the transition. As a result, they are now pattern matching against that structure and are actively investigating this opportunity, hoping to benefit from yet another large transition.这里的共同点是什么？那就是：他们都经历了一个转变，其中他们先前框架的一个锚点被证明无效。然后他们的职业生涯从转变中受益匪浅。因此，他们现在正在根据这种结构进行模式匹配，并积极调查这个机会，希望从另一个重大转变中受益。

And if you know how to look, you’ll realise that folks with similar prior experiences all say as much, only using different words. Here is Marc Brooker, another senior engineer who experienced the transition from server, to cloud, to serverless (Brooker is a distinguished engineer at AWS; he built AWS Lambda, led the team that released Aurora DSQL, and helped create the Firecracker VMM):如果你知道如何寻找，你会意识到有类似先前经历的人都会这么说，只是用词不同。以下是Marc Brooker，另一位经历了从服务器到云再到无服务器转变的高级工程师（Brooker是AWS的杰出工程师；他构建了AWS Lambda，领导了发布Aurora DSQL的团队，并帮助创建了Firecracker VMM）：

Many of the heuristics that we’ve developed over our careers as software engineers are no longer correct. Not all of them. But many. What it means for a system to be maintainable. How much it costs to write code versus integrate libraries versus take service dependencies. What it means for an API to be well designed, or ergonomic, or usable. What it means to understand code. Where service boundaries should be. Where security and data integrity should be enforced. What’s easy. What’s hard.

We’ve seen this play out in small ways before. Over the last decade, I’ve frequently been frustrated by experienced folks who didn’t update their system design heuristics to match the cloud, to match SSDs, to match 100Gb/s networks, and so on. But this is the biggest change I’ve seen in my career by far. An extinction-level event for rules of thumb.我们在软件工程师职业生涯中开发的许多启发式方法不再正确。不是全部。但很多。系统可维护性的含义。编写代码与集成库与采用服务依赖的成本。API设计良好、符合人体工程学或可用的含义。理解代码的含义。服务边界应该在哪里。安全性和数据完整性应该在哪里强制执行。什么是容易的。什么是困难的。我们以前在小范围内看到过这种情况。在过去十年中，我经常对那些没有更新系统设计启发式方法以适应云、SSD、100Gb/s网络等的经验丰富的人感到沮丧。但这是我职业生涯中迄今为止看到的最大变化。经验法则的灭绝级事件。

If you take this frame seriously, what do you get? You get something like the following:如果你认真对待这个框架，你会得到类似以下的内容：

• Code generation is cheap now. What changes to the SDLC can we make to fully leverage this?代码生成现在很便宜。我们可以对SDLC做出哪些改变来充分利用这一点？
• We don’t know where the optimal tradeoffs lie. Initial attempts all seem to trade away human readability (and code quality measures that correlate to human readability) in favour of program correctness and development velocity.我们不知道最优权衡在哪里。最初的尝试似乎都以牺牲人类可读性（以及与人类可读性相关的代码质量度量）为代价，换取程序正确性和开发速度。
• We get there by a) not allowing human developers to touch the code, only the agent harness, and b) by limiting the degrees of freedom available to the AI. How to best limit the degrees of freedom available to the agent is a matter of ongoing discovery. (See Zero-Degree-of-Freedom LLM Coding using Executable Oracles by John Regehr for an outline of this approach)我们通过a）不允许人类开发者接触代码，只接触代理工具集，以及b）限制AI可用的自由度来实现这一点。如何最好地限制代理可用的自由度是一个持续发现的问题。（参见John Regehr的《使用可执行预言机的零自由度LLM编码》以了解这种方法的大纲）
• Since code generation is cheap, many of these projects seem to expect 100% test coverage as a minimum. Depending on the team, there’s also interest in lightweight formal methods, property-based testing (see the launch of Hegel), and deterministic simulation testing (see Antithesis).由于代码生成很便宜，这些项目中的许多似乎期望100%的测试覆盖率作为最低要求。根据团队的不同，还有对轻量级形式化方法、基于属性的测试（参见Hegel的发布）和确定性模拟测试（参见Antithesis）的兴趣。
• All documentation is checked into repo, in the form of greppable specs that are broken down by concern in a top-level table of contents (so as to not overload the context window).所有文档都检入仓库，以可搜索的规范形式存在，按关注点分解在顶级目录中（以免使上下文窗口过载）。
• The AI agent should be able to check their work and self correct. That means access to a web browser (for the user-facing parts of a web app), and server logs (to correct for bugs in deployment).AI代理应该能够检查它们的工作并自我纠正。这意味着访问网络浏览器（用于Web应用程序面向用户的部分）和服务器日志（以纠正部署中的错误）。
• To improve agent performance, the codebase is structured with strict boundaries and predictable structure. This structure is enforced with custom-generated linters and tests to ensure that data-flow doesn’t violate the chosen architecture. The OpenAI approach seems to be to enforce a unidirectional data flow. Data is always parsed at the boundary (an idea stolen from the Haskell community), and then data flow can only go in one direction in the codebase. It appears that you can get quite creative with how to enforce these invariants. From the OpenAI report: ‘In practice, we enforce these rules with custom linters and structural tests, plus a small set of “taste invariants.” For example, we statically enforce structured logging, naming conventions for schemas and types, file size limits, and platform-specific reliability requirements with custom lints. Because the lints are custom, we write the error messages to inject remediation instructions into agent context.’为了提高代理性能，代码库以严格的边界和可预测的结构组织。这种结构通过自定义生成的linter和测试来强制执行，以确保数据流不违反所选架构。OpenAI的方法似乎是强制执行单向数据流。数据总是在边界处解析（一个从Haskell社区借鉴的想法），然后数据流只能在代码库中单向流动。看起来你可以非常有创意地强制执行这些不变量。从OpenAI的报告来看：‘在实践中，我们通过自定义linter和结构测试，以及一小套“品味不变量”来强制执行这些规则。例如，我们通过自定义lint静态强制执行结构化日志记录、模式和类型的命名约定、文件大小限制以及特定于平台的可靠性要求。由于lint是自定义的，我们编写错误消息以将修复指令注入代理上下文。’
• Agents seem to replicate patterns that are already found in the codebase, so there needs to be a series of automated runs to clean up AI slop. These run autonomously, during lull periods, on a regular cadence.代理似乎会复制代码库中已有的模式，因此需要一系列自动运行来清理AI垃圾。这些运行在空闲期间按固定节奏自主进行。

Notice that a core anchor for this frame is simply: code generation is cheap. This means writing tests is cheap, using formal methods is cheap, creating linters and lightweight agents to enforce more subjective invariants is cheap. How do we compose these methods together to get high development velocity with high correctness and a tiny team? What are the limits of this approach? We don’t know, but these teams are finding out.请注意，这个框架的一个核心锚点仅仅是：代码生成很便宜。这意味着编写测试很便宜，使用形式化方法很便宜，创建linter和轻量级代理来强制执行更主观的不变量很便宜。我们如何组合这些方法以获得高开发速度、高正确性和小团队？这种方法的极限是什么？我们不知道，但这些团队正在探索。

Technique Two: Read Takes to Infer the Frame技巧二：阅读观点以推断框架

In Part 1 I wrote that you should stop reading takes, because they are of limited use — first, they are likely to be written for audience-building purposes (which benefits the author more than it benefits you), second, many of them are written for self-soothing reasons, and third, reading takes is not a good use of your time if your goal is to sensemake for the outcomes you care about.在第一部分中，我写道你应该停止阅读观点，因为它们用处有限——首先，它们很可能是为了建立受众而写的（这对作者的好处大于对你），其次，许多是为了自我安慰而写的，第三，如果你的目标是为你关心的结果进行意义建构，阅读观点不是很好的时间利用方式。

Now that we understand the Data-Frame theory, however, we may reintroduce takes into our information diet, albeit in a limited manner. The reason is that we now have a new tool in our sensemaking toolbox: we may use takes as a way to infer new frames.然而，既然我们理解了数据-框架理论，我们可以重新将观点引入我们的信息饮食中，尽管是有限的方式。原因是我们现在在意义建构工具箱中有了一个新工具：我们可以使用观点来推断新框架。

Try this: when you are reading a take, ask yourself “what frame is this author operating from?” Sometimes the answer is obvious, in which case you may skim the rest of the piece and toss it. But occasionally you might feel confused — you might discover that you are not able to answer this question with confidence. If you assume that the author you are reading is not dumb, it might be worth it to investigate the frame they are operating from. In fact, I argue that you absolutely should do so if a) it doesn’t take much work to generate this information, and b) the outcomes implied by this unknown frame might have implications for things that you care about.试试这个：当你阅读一个观点时，问自己‘这个作者是从什么框架出发的？’有时答案很明显，在这种情况下你可以浏览其余部分并丢弃它。但偶尔你可能会感到困惑——你可能会发现你无法自信地回答这个问题。如果你假设你正在阅读的作者不笨，那么调查他们所处的框架可能是值得的。事实上，我认为如果a）生成这些信息不需要太多工作，并且b）这个未知框架所暗示的结果可能对你关心的事情有影响，那么你绝对应该这样做。

Here’s a concrete example.这里有一个具体的例子。

Gabriella Gonzalez is a famous Haskell programmer. She is believable in every sense of the word. On 17th March 2026 she published an essay titled A Sufficiently Detailed Spec is Code.Gabriella Gonzalez是一位著名的Haskell程序员。她在各个方面都是可信的。2026年3月17日，她发表了一篇题为《足够详细的规范就是代码》的文章。

In the essay Gonzalez pushes back on the idea — currently publicised by ‘agentic coding advocates’ — that you can generate code purely from writing specification documents. Her argument references the famous Dijkstra observation that any attempt at using natural languages (such as English) to write computer programs is doomed to failure. From this, Gonzalez argues that spec-first programming cannot possibly deliver the benefits their promoters are selling because a) specification documents are not simpler than the resulting code (meaning they are not cheaper to write), and b) specification work is supposed to be more thoughtful than coding work — but if they are AI-generated, they will result in slop. After all, if you feed slop specs to an AI coding agent, you shouldn’t be surprised if you get slop code out the other end.在这篇文章中，Gonzalez反驳了目前由‘代理编码倡导者’宣传的观点——即你可以仅通过编写规范文档来生成代码。她的论点引用了著名的Dijkstra观察，即任何使用自然语言（如英语）编写计算机程序的尝试都注定失败。由此，Gonzalez认为规范优先编程不可能带来其推广者所承诺的好处，因为a）规范文档并不比生成的代码更简单（意味着它们编写成本并不更低），b）规范工作应该比编码工作更深思熟虑——但如果它们是AI生成的，结果将是垃圾。毕竟，如果你向AI编码代理提供垃圾规范，你不应该对另一端得到垃圾代码感到惊讶。

I will admit that I skimmed Gonzalez’s piece — not because I disagreed with it, but because I agreed. And of course I would. I first encountered Dijkstra’s argument whilst doing my computer science degree (I specialised in programming languages). I remember being persuaded then. Seen in this light, there was nothing new for me in Gonzalez’s take — she was writing from the perspective of the ‘pragmatic software engineer’ frame (albeit from a position of significant authority), and she was citing literature that is established canon in our field. I skimmed her piece and set it aside; there was little sensemaking value to examine arguments that I already agreed with, in a frame that I already inhabited.我承认我浏览了Gonzalez的文章——不是因为不同意，而是因为我同意。我当然会同意。我第一次遇到Dijkstra的论点是在攻读计算机科学学位时（我专攻编程语言）。我记得当时就被说服了。从这个角度看，Gonzalez的观点对我来说没有什么新意——她是从‘务实软件工程师’框架的角度写作的（尽管处于重要的权威地位），并且引用了我们领域内公认的经典文献。我浏览了她的文章并放在一边；检查我已经同意的论点和我已经居住的框架几乎没有意义建构价值。

Around the same time, I stumbled onto Hrishi Olickel’s RISC Won: Building Towards Data AGI. The article describes a year-long attempt at building a data analysis agent harness. Olickel’s account is notable because his journey begins before Claude Code is released, and much of the trial and error occurs before Claude Code becomes popular. This means much of the experimentation goes down paths that we know are agent harness dead ends today.大约在同一时间，我偶然发现了Hrishi Olickel的《RISC获胜：迈向数据AGI》。这篇文章描述了一次为期一年的构建数据分析代理工具集的尝试。Olickel的叙述值得注意，因为他的旅程始于Claude Code发布之前，并且大部分试错发生在Claude Code流行之前。这意味着许多实验走的是我们今天知道是代理工具集死胡同的路径。

In the piece is this paragraph:文章中有这样一段话：

The start of Q3 (June) is when we switch completely from writing code to writing specs. Almost all product development from this point on gets done by writing large, 5-10 thousand word specifications. We're betting that by Opus 4, code can be generated as needed, and iterations can happen faster and more collaboratively over English specifications.

This bet pays off.

We build specs for things we need internally that later models are able to simply one-shot.第三季度初（六月）是我们完全从编写代码转向编写规范的时候。从那时起，几乎所有产品开发都是通过编写大型的、5000到10000字的规范来完成的。我们打赌到Opus 4时，代码可以按需生成，并且迭代可以在英语规范上更快、更协作地进行。这个赌注得到了回报。我们为内部需要的东西构建规范，后来的模型能够简单地一次性生成。

Now this was a perspective I did not understand. What benefits would come from writing and iterating on specs so you may one shot later? Sure, I buy that AI models are improving over time, but why would you want to throw generated code out after every model improvement?这是一种我无法理解的视角。通过编写和迭代规格说明，以便将来一次性完成，会带来什么好处？当然，我相信AI模型会随着时间改进，但为什么每次模型改进后都要丢弃生成的代码呢？

If I was fully committed to the previous ‘pragmatic software engineer’ frame, I would have ignored this piece of data as “silly” or “not important to investigate”. But as mentioned earlier, I was open to the idea that code generation is now cheap and new affordances might exist as a result of this new anchor. In such a scenario is it valuable to pay attention to experimentation. It was also clear how this frame might be valuable to me: I run a business, I occasionally consult for others, and I hire software engineers. It is not difficult to imagine how I might profit from Olickel’s workflow — especially if I deploy it in various business experiments.如果我完全坚持之前“务实软件工程师”的框架，我可能会忽略这条信息，认为它“愚蠢”或“不值得研究”。但如前所述，我对代码生成现在很便宜、并且这个新锚点可能带来新的可能性持开放态度。在这种情况下，关注实验是有价值的。我也清楚这个框架对我有何价值：我经营一家企业，偶尔为他人提供咨询，并雇佣软件工程师。不难想象，我如何能从Olickel的工作流程中获益——尤其是如果我将它应用于各种商业实验。

Once you are open to the existence of a new frame, you may begin to seek out others who inhabit it. It didn’t take me long to stumble upon Marc Brooker’s Spec Driven Development Isn’t Waterfall. Notice that this is another take, though on the opposite side of Gonzalez’s. This shouldn’t be surprising, given Brooker’s history in the shift to the cloud. He writes (bold emphasis mine):一旦你对新框架的存在持开放态度，你可能会开始寻找其他持有该框架的人。没过多久，我就偶然发现了Marc Brooker的《规范驱动开发不是瀑布模型》。注意，这是另一种观点，尽管与Gonzalez的相反。考虑到Brooker在向云迁移方面的历史，这并不奇怪。他写道（粗体强调为我所加）：

This approach [spec driven development] has several advantages which I’ve written about in the past: keeping context on the bigger picture (a map, versus the turn-by-turn directions of vibe coding prompts), the ability to mix levels of formality and detail to meet the needs of a particular piece of software, serving as always-in-sync documentation, allowing implementation of the same code in multiple languages or with multiple frameworks, and the ability to lift what matters out of the muck of the implementation. One advantage, though, is looking to override all of these in importance: we’re seeing the largest improvements in velocity and delivery in teams and processes that can allow agents to run autonomously for long periods of time. Specifications do exactly that. By providing the agent with a clear map, we can set an agent off building without a human inside the tight loop of development and testing. The agent can also write higher quality, better designed, and better tested code by seeing the big picture. It knows what to test, and what good looks like.

Specifications aren’t up-front designs because you don’t need to, and probably shouldn’t, develop the entire specification upfront. Instead, specifications should be at the core of an iterative software development practice. Humans are still critical to this outer loop of software development, driven by refining and extending the specification. Perhaps most crucially, they own the internally conflicting nature of software requirements. Where conflicts and trade-offs exist, either technical or in product requirements, expertise and experience come into play.这种方法（规范驱动开发）有几个我过去写过的优点：保持对大局的把握（一张地图，而不是氛围编码提示的逐向导航），能够混合不同级别的形式化和细节以满足特定软件的需求，作为始终同步的文档，允许用多种语言或框架实现相同的代码，以及能够从实现的泥沼中提取出重要的东西。然而，有一个优点似乎比所有这些都重要：我们看到，在允许代理长时间自主运行的团队和流程中，速度和交付的改进最大。规范正是做到了这一点。通过为代理提供清晰的地图，我们可以让代理开始构建，而无需人类紧密参与开发和测试循环。代理还可以通过看到全局来编写更高质量、设计更好、测试更完善的代码。它知道要测试什么，以及好的代码是什么样的。规范不是预先设计，因为你不需要、也不应该预先开发整个规范。相反，规范应该处于迭代软件开发实践的核心。人类仍然对这个软件开发的外循环至关重要，通过完善和扩展规范来驱动。也许最关键的是，他们掌握着软件需求的内在冲突性。在存在冲突和权衡的地方，无论是技术上的还是产品需求上的，专业知识和经验就会发挥作用。

If Brooker has this frame, then it is likely that other senior engineers across the industry have also constructed the same frame. You may hunt for them.如果Brooker持有这个框架，那么很可能行业中的其他资深工程师也构建了相同的框架。你可以去寻找他们。

Finally, it is not expensive for me to generate more information. Olickel attended the National University of Singapore, my alma-mater. I helped create the largest hacker club on campus. It would’ve been possible to work that network to set up a conversation with him in order to ask, respectfully, about his experiences. And even if that were not possible, it would not be too difficult to send a cold email!最后，对我来说，生成更多信息并不昂贵。Olickel就读于新加坡国立大学，我的母校。我曾帮助创建了校园里最大的黑客俱乐部。我本可以利用这个人脉网络与他安排一次对话，以便恭敬地询问他的经验。即使这不可能，发一封冷邮件也不太难！

(In the end, I had no need to do that — a Commoncog reader set up a call with Olickel and I asked them to ask questions on my behalf.)（最后，我无需这么做——一位Commoncog的读者安排了一次与Olickel的通话，我请他们代我提问。）

But here is my point: this is a concrete example of using a take as signal of a new frame. Constructing that frame becomes easier once you detect its existence. Notice how the reward-effort tradeoff was high enough that it was well worth my time to investigate — and indeed I spent a fair bit of time reading the documentation of Hankweave, the harness Olickel released. It is in this manner that takes may still be useful.但我的观点是：这是一个将观点作为新框架信号的 concrete 例子。一旦你检测到它的存在，构建该框架就变得更容易。注意，回报-努力权衡足够高，值得我花时间调查——事实上，我花了不少时间阅读Olickel发布的工具Hankweave的文档。正是通过这种方式，观点仍然可能有用。

Let me be clear, though: takes are still not valuable in terms of direct information content — at least not from a sensemaking perspective. I didn’t spend much time on Gonzalez’s take, because I already understood the frame it was from. But takes are useful if you treat them as sources of embedded frames.不过，我要明确一点：观点在直接信息内容方面仍然没有价值——至少从意义建构的角度来看是这样。我没有花太多时间在Gonzalez的观点上，因为我已经理解它来自的框架。但如果你将观点视为嵌入框架的来源，它们是有用的。

Just … read them sparingly.只是……要少读它们。

Technique Three: Collect Fragments from Prior Technological Shifts技巧三：从以往技术变革中收集片段

In the previous instalment I argued that it is important to collect fragments from related domains, in order to improve at frame construction. Of course, a natural question is a) what fragments should you collect, and b) how do you find them?在上一篇文章中，我论证了收集相关领域的片段对于提高框架构建能力很重要。当然，一个自然的问题是：a) 你应该收集哪些片段，b) 如何找到它们？

Given that we’re talking about AI here, a natural source of fragments are past technological revolutions. Specifically, we want to look for:鉴于我们讨论的是AI，一个自然的片段来源是过去的技术革命。具体来说，我们要寻找：

• Examples of companies that won (or lost) as the result of the new technology.因新技术而获胜（或失败）的公司案例。
• Stories from the diffusion of these new technologies. Specifically: what changed, how long did the changes take, and how were various parts of society affected?这些新技术传播的故事。具体来说：什么改变了，变化花了多长时间，以及社会的各个部分如何受到影响？

You may want to supplement these with other fragments, specific to your industry and to your personal situation. This doesn’t have to take a huge amount of time — you could skim through biographies, or simply ask older folks to tell you the story of their experiences.你可能还想补充其他片段，针对你的行业和个人情况。这不需要花费大量时间——你可以浏览传记，或者直接请年长者讲述他们的经历。

At this point in the series I don’t have to explain why you might want to collect such stories. Of course, the common retort is “Why are you reading history? AI is a fundamentally new technology and it is unlike every other technological revolution that has come before.” But you are not collecting these fragments for naive pattern matching. You are collecting these fragments for frame construction. Ironically, frame construction enables the kinds of advanced pattern matching that experts do. Naturalistic Decision Making researcher Jared Peterson likes to say (my paraphrase) “expertise is fundamentally pattern matching, and experts are able to pattern match problems that they’ve never seen before.” How? Well, you already know how: the Data-Frame theory gives you the mechanism.在这个系列中，我不需要解释为什么你可能想收集这样的故事。当然，常见的反驳是：“你为什么读历史？AI是一种全新的技术，与以往任何技术革命都不同。”但你收集这些片段不是为了天真的模式匹配。你收集这些片段是为了框架构建。讽刺的是，框架构建使得专家能够进行高级模式匹配。自然决策研究者Jared Peterson喜欢说（我转述）：“专业知识本质上是模式匹配，专家能够匹配他们从未见过的问题。”如何做到？嗯，你已经知道了：数据-框架理论给了你机制。

With this in mind, you might see why I suggested the two categories of fragments above:考虑到这一点，你可能会明白为什么我建议了上述两类片段：

1. You’ll want to look for stories of technologically-enabled competitive advantage because new technology is both an opportunity and a threat. How have companies adapted to the affordances of new technology in the past? What were the problems? What did that look like?你会想寻找技术驱动的竞争优势的故事，因为新技术既是机遇也是威胁。过去公司如何适应新技术带来的可能性？问题是什么？那是什么样的？
2. You’ll also want to ground your perspectives in real stories of societal disruption. AI prognosticators tend to throw around simple stories of prior technological displacement. “We invented the automobile and then horses vanished … don’t be like the horse” they write. Such prognosticators are then surprised when they learn that more horses were deployed in WWII than in any other war in history, far outstripping the horses deployed in the Napoleonic wars, for instance. They might also be surprised to learn that railroad companies — the high technology companies of their day — employed 100 times more horses than automobiles two decades after the founding of the Ford Motor Company (and five decades after the invention of the automobile). This occured even as automobiles began displacing horses for public (and private) transportation in the rich capitals of the world, starting from 1917 onwards. The point is that technological diffusion is a lot weirder than you might think.你还需要将你的观点建立在真实的社会颠覆故事上。AI预测者倾向于抛出简单的技术替代故事。“我们发明了汽车，然后马消失了……不要像马一样”他们写道。然后这些预测者惊讶地发现，二战中使用的马比历史上任何战争都多，远远超过拿破仑战争中的马。他们可能还会惊讶地了解到，铁路公司——当时的高科技公司——在福特汽车公司成立二十年后（以及汽车发明五十年后）使用的马匹数量是汽车的100倍。即使汽车从1917年开始在富裕的首都城市取代马匹用于公共（和私人）交通，这种情况仍然发生。关键是，技术传播比你想象的要奇怪得多。

The good news is that you only need a couple of fragments in your head. I would aim for 10-20 calibrating cases. It may take a bit of effort to seek out fragments of cases, though. One good place to start is The Shock of the Old by technology historian David Edgerton. (Both horse anecdotes are taken from Edgerton’s book). Another good book to skim for fragments is Engines That Move Markets by Alasdair Nairn.好消息是，你只需要在脑海中记住几个片段。我的目标是10-20个校准案例。寻找案例片段可能需要一些努力。一个好的起点是技术历史学家David Edgerton的《旧事物的冲击》（两个马的轶事都来自Edgerton的书）。另一本可以浏览片段的好书是Alasdair Nairn的《驱动市场的引擎》。

But we intend to help you with this. Over the course of this year, we at Commoncog will begin seeking out, researching, and then publishing fragments in both categories. This service is intended for members; many cases will be published behind the paywall.但我们打算在这方面帮助你。今年，Commoncog将开始寻找、研究并发布这两类片段。这项服务面向会员；许多案例将发布在付费墙后。

If you have suggestions for books or cases please ping us in the forum.如果你有书籍或案例的建议，请在论坛中联系我们。

Wrapping Up总结

What have I shown you?我向你展示了什么？

I’ve made three arguments in this essay:在这篇文章中，我提出了三个论点：

1. First, in order to sensemake effectively, you’re going to have to commit to alternative frames that you might not necessarily agree with. It is tempting to stick to your current frame, and to reject all new developments as transient. But this is dangerous if the outcomes implied by these new developments may affect your livelihood. (Conversely, major shifts can often represent opportunities to advance your career, as mentioned earlier). I suggested two strategies to make it easier to commit to alternative frames: first, engaging in the reframing cycle does not mean you have to give up your current frame. You may continue to believe what you currently believe and elaborate an alternative frame in parallel; you should find this quite natural to do. Second, you should look for anchors that will allow you to construct that alternative frame (again, without necessarily accepting it). I gave an example of committing to the frame of ‘autonomous AI coding agents are possible’ when a senior engineer told me that I was not taking the notion of ‘code is cheap’ seriously enough. That anchor happened to work for me; it might not for you. The goal is to find one that works — again, assuming that the potential impacts are serious enough that you are motivated to do so. This brings us to …首先，为了有效地进行意义建构，你必须承诺接受你可能不一定同意的替代框架。坚持你当前的框架，并拒绝所有新进展为短暂现象是很诱人的。但如果这些新进展所暗示的结果可能影响你的生计，这是危险的。（相反，重大转变通常代表职业发展的机会，如前所述）。我提出了两种策略来更容易地承诺替代框架：第一，参与重新框架循环并不意味着你必须放弃当前框架。你可以继续相信你当前相信的东西，同时并行阐述一个替代框架；你会发现这很自然。第二，你应该寻找锚点，以便构建那个替代框架（同样，不必接受它）。我举了一个例子，当一位资深工程师告诉我，我没有足够认真地对待“代码很便宜”的概念时，我承诺了“自主AI编码代理是可能的”框架。那个锚点对我有效；对你可能无效。目标是找到一个有效的锚点——同样，假设潜在影响足够严重，以至于你有动力这样做。这引出了……
2. It is acceptable to read takes … if you are doing it for frame construction purposes. This is a nuanced point. The vast majority of predictions you read are still going to be wrong. During a technological shift, you will still encounter many writers who are opining on the ‘current thing’ for attention. Others will write for self-soothing reasons. These facts are not going to change. But you now have a new tool in your toolbox: instead of reading these opinions at face value, you may read them for frame construction reasons. You may ask: what frame are they operating from? Why do they hold such a frame? Are there data points that they’re using as anchors that I’m not seeing? Of course, you do not have to accept their frame, in the same way that you do not have to take their opinions seriously. But you may proceed to evaluate the frame they’re operating in.阅读观点是可以接受的……如果你是为了框架构建的目的。这是一个微妙的观点。你读到的大多数预测仍然会是错误的。在技术变革期间，你仍然会遇到许多为了吸引注意力而对“当前事物”发表意见的作者。其他人会出于自我安慰的原因写作。这些事实不会改变。但你现在有了一个新工具：你可以不是为了表面价值阅读这些观点，而是为了框架构建的原因阅读它们。你可以问：他们从什么框架出发？为什么他们持有这样的框架？是否有他们用作锚点而我没有看到的数据点？当然，你不必接受他们的框架，就像你不必认真对待他们的观点一样。但你可以继续评估他们所处的框架。
3. Finally, you may improve your sensemaking ability by collecting fragments from prior technological shifts. The goal is to calibrate your expectations of how change has happened in the past, so you are not tricked by ungrounded speculation in the present. Specifically, I proposed that you want to collect two types of fragments: first, stories of companies building competitive advantage and benefiting from the new affordances of the new technology. Second, stories of societal impacts and broader change as a result of new technologies. In both cases you want to pay special attention to the timelines involved.最后，你可以通过收集以往技术变革的片段来提高意义建构能力。目标是校准你对过去变化如何发生的预期，这样你就不会被当前无根据的猜测所欺骗。具体来说，我建议你收集两类片段：第一，公司建立竞争优势并从新技术的新可能性中受益的故事。第二，新技术带来的社会影响和更广泛变化的故事。在这两种情况下，你要特别注意时间线。

There’s nothing magical about better sensemaking. In truth, the various cycles of the Data-Frame theory are simply part and parcel of being human. You likely already do some form of this in some aspects of your life. The only thing we’ve accomplished here is to draw out some common sense implications of the Data-Frame theory, and we have applied them to the ongoing AI wave, a consequential new technology.更好的意义建构并没有什么神奇之处。事实上，数据-框架理论的各种循环只是人类的一部分。你可能已经在生活的某些方面做了类似的事情。我们在这里所做的只是阐明了数据-框架理论的一些常识性含义，并将其应用于当前的AI浪潮，一项重要的新技术。

The techniques outlined here may be adapted for other things in your business or in your life. Hopefully, after reading this series, you’ll know how to do just that. But on the topic of AI, at least, you are better equipped to sensemake the rapid changes that are happening here.这里概述的技巧可以适用于你业务或生活中的其他事情。希望读完这个系列后，你会知道如何做到这一点。但至少在AI这个话题上，你更有能力理解正在发生的快速变化。

Hopefully, you won’t lose your head.希望你不会失去理智。

Originally published 03 May 2026, last updated 07 May 2026.最初发布于2026年5月3日，最后更新于2026年5月7日。