每日脉动：RoR 作者再次引发‘手写代码终结论’辩论

在我们开始之前：如果你碰巧在旧金山，欢迎于11月5日星期四参加我与 The Pragmatic Engineer 共同举办的 System Update 活动。这是由 Sentry 组织的一场晚间活动，参与者包括 OpenAI、Linear、DoorDash 和我本人。我们将以非公开（也就是说：不录音！）且坦率的对话形式，深入探讨他们在生产环境中运行的 AI 增强型自动化，以及进展如何。席位有限，你可以在这里 RSVP。Before we start: if you happen to be in San Francisco on Thursday, 5 November, join me on the System Update with The Pragmatic Engineer event. This is an evening with OpenAI, Linear and DoorDash and myself, organized by Sentry. We get into what AI-augmented automations they’re running in prod, and how it’s going, in an off-the record (that is: not recorded!) and raw conversation. Seats are limited, and you can RSVP here.

你好，我是 Gergely，这里为你带来一期额外的《务实工程师》通讯，免费阅读。在每一期中，我都会从资深工程师和工程领导者的视角，介绍大型科技公司和初创公司的相关动态。今天，我们将介绍上一周《脉搏》一期中四个主题之一。完整订阅用户已在七天前收到下面这篇文章。如果这封邮件是别人转发给你的，你可以在这里订阅。Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from the last week’s issue of The Pulse. Full subscribers received the article below seven days ago. If you’ve been forwarded this email, you can subscribe here.

Ruby on Rails 的创建者 David Heinemeier Hansson 上周在 Rails World 的主题演讲中发表了一番言论，引发了不小的轰动。他透露，在他的公司 37signals，手写代码已经过时了。
The creator of Ruby on Rails, David Heinemeier Hansson, caused quite a stir last week with comments in his Rails World keynote, when he revealed that coding by hand is dead at his company, 37signals.

这件事意义重大，因为 37signals 创建了 Ruby on Rails，而且他们以卓越的软件工艺闻名，尤其是在代码质量方面。此外，这还是一家拥有 27 年历史且实现盈利的企业。尽管拥有这样的背景，DHH 仍在开发者社区中引发了轰动，他说道：This is a big deal because 37signals created Ruby on Rails, and they are known for their software craft there, especially when it comes to code quality. It’s also a business that’s 27 years old and is profitable. Despite that pedigree, DHH caused a stir among the dev community, saying:

几周前，在 37signals，我们做出了一个决定：这明确意味着，我们已经不再手写代码了。我们已经放下铅笔，不再把手写代码视为创造产品这一日常业务流程的一部分。在 37signals，手写代码如今是一种例外状态。它就像在 Sentry 中看到一个 bug：这里出了问题；为什么 agent 没能产出我们想要的结果？好吧，也许在一小段时间里，我们仍会拿出那支旧铅笔，替它们点上几笔，但随后我们会修好机器，修好工厂，让一切重新运转起来。这是对已经发生之事的承认。

“At 37signals, a couple of weeks ago, we made the decision that it clearly means we’re done writing code by hand. We have gone pencils down on the idea that we were gonna write code by hand, as a normal course of business creating things.

Writing code by hand at 37signals is now an exceptional state. It is like seeing a bug in Sentry: something here went wrong; why was the agent not able to produce what we wanted? Okay, maybe for a little while, we’ll still get the old pencil out and dot it down for them, but then we fix the machine, we fix the factory, we get things going again. This is a recognition of what’s already happening.”

DHH 将 AI 工具逐渐成熟并具备强大编码能力，比作相机的出现对绘画艺术所产生的影响：DHH compared the maturation of AI tools into being highly capable at coding with the impact upon the craft of painting of the arrival of the camera:

2025年11月24日，我们迎来了属于这个时代的‘柯达布朗尼’。我们迎来了 Opus 4.5。一项人人都能负担得起的 AI 技术，让许多人第一次得以接触并体验与一种新形态的智能协作开发软件的感觉。对我而言，这是一个临界点。11月24日之前是一个世界，之后则是另一个世界。从今往后，历史书将把这一天标记为智能体时代的转折点。

“On November 24th, 2025, we got the “Kodak Brownie” of our era. We got Opus 4.5. AI technology, accessible in a harness that many people could afford to use and experience for the first time what it’s like to create software in pairing with a new form of intelligence. This was the tipping point for me. There was everything before November 24th, and then there was everything after. This is going to be the date that history books going forward will mark as the inflection point for the age of agents.”

他分享了 37signals 如何拥抱一个几乎完全不再手写代码的未来：He shared how 37signals has embraced a future where coding by hand is almost entirely absent:

• 拥抱原生移动应用而非 Web：众所周知，37signals 不看好原生 iOS 和 Android 应用，转而构建了 Web 版本。借助 AI，他们押注于原生应用将更容易由小团队构建，并且已经在开发新的原生应用。
  Embracing native mobile apps instead of web: famously, 37signals is bearish on native iOS and Android apps and has built web versions instead. With AI, they are betting on native apps being much easier to be built with a small team and are already building new ones.
• 将后端服务迁移到 Rust，而不是 Ruby：这是出于性能方面的考虑，也是因为智能体编写的 Rust 代码已经足够优秀。能从 Ruby on Rails 的创建者口中听到这番话，真是令人惊叹！
  Moving backend services to Rust, not Ruby: This is due to performance reasons and because agents write good enough Rust. That’s remarkable to hear from the creator of Ruby on Rails!
• Ruby on Rails 仍然适用于 Web 应用：37signals 并没有放弃 RoR，但这只是因为 Ruby on Rails 的“约定优于配置”设计让智能体能够轻松使用它。
  Ruby on Rails remains for web apps: 37signals is not leaving RoR behind, but only because Ruby on Rails’ convention-over-configuration design makes it easy for agents to work with it.

DHH 最后透露，他甚至已经不再认为自己是一名专业程序员（着重号为我所加）：DHH closed by revealing that he no longer even thinks of himself as a professional programmer (emphasis mine):

我已经不再从事专业程序员的工作了。我想大概是四五个月前，也许是三月。我花了整整四分之一个世纪亲手雕琢代码，并享受其中的每一刻。这并不是一件需要带着遗憾回首的事；这是应该带着喜悦回望，并接受它已经结束的事。对于绝大多数公司里的绝大多数程序员来说，亲手编写代码已经不再是一项具有经济生产力的事业。与之相对的，是一种全新的职业：成为专业的造物者，驾驭直到片刻之前还只存在于科幻作品中的智能。我们不得不重新审视的一件事，就是我们自以为了解的关于软件架构的一切。长期以来，我们使用的主要工具是抽象。到了智能体时代，抽象不再具有完全相同的意义。我们采用抽象，部分原因是为了避免重复自己；然而现在，重复的代价已经接近于零。

“I have retired from being a professional programmer. I think it was somewhere around 4 to 5 months ago, maybe March. I spent a quarter of a damn century chiseling code by hand and loving every moment of it. This is not something to look back upon with regret; this is something to look back upon with joy and accept that it is over.

Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies. On the other side of that is a new career as a professional maker of things, steering intelligence that was only available in science fiction up until a few moments ago.

One of the things we’re gonna have to revisit is everything we think we know about software architecture. The main tool that we’ve used for a very long time is abstractions. Abstractions don’t make quite the same sense in the age of agents. The reason we did abstractions was in part not to repeat ourselves; well, now the price of repetition has gone to near zero.”

值得注意的是，DHH 的主题演讲为一场由亲身且职业上都投入于软件构建这一技艺的工程师参加的会议选择了一个颇具争议的话题！It’s worth noting DHH’s keynote chose a spicy topic for a conference attended by engineers who are personally and professionally invested in the craft of building software!

手工编程的衰落早已被预言Decline of coding by hand is long predicted

在今年 1 月 6 日发布的《The Pragmatic Engineer》第一期中，我写道：In the first issue in The Pragmatic Engineer this year, on 6 January, I wrote:

当 AI 几乎编写了全部代码时，软件工程将会怎样？这不再是假设性问题，而是一股注定冲击科技行业的超级趋势。（……）坏消息是，变化可能会来得非常快。从 Boris Cherny 脑海中萌生 Claude Code 这一想法至今还不到一年，而类似的工具，如 OpenCode、Codex、Factory、Amp、Cursor，以及更多能力更强的智能体，已经在改变软件编写的方式。变化一直是科技行业工作的一部分，但我想不起曾有哪次变化如此迅速，或曾有哪次在整个行业同时发生！

“When AI writes almost all code, what happens to software engineering? No longer a hypothetical question, this is a mega-trend set to hit the tech industry. (...)

The bad news is that change will probably be rapid. It’s barely been a year since the idea of Claude Code was born in Boris Cherny’s head, and already similar tools like OpenCode, Codex, Factory, Amp, Cursor, and more capable agents are changing how software is written. Change has always been part of working in tech, but I cannot recall it being this fast, or happening across the whole industry at once!”

我得出这一结论，是基于我亲自使用 Opus-4.6 和 GPT-5.2 构建软件的经历，以及与一些经验丰富的工程师交流后的认识。这些工程师曾出于充分的理由抵制“AI 热潮”，但后来也开始意识到，如今 AI 在许多情况下已经能够生成“足够好”的代码。I concluded that this change was on its way, based on my own experience of building software with Opus-4.6 and GPT-5.2, and from talking with experienced engineers who had resisted “AI hype” for good reason, but who had come to see that AI can now generate code that’s “good enough” in many cases.

当时，我对人工智能代理为工程师编写大部分代码后将会发生什么，做出了一些预测：Back then, I made a few predictions about what will happen when AI agents are producing most of the code for engineers:

• 更松散的代码
  Sloppier code
• 不佳的软件工程实践更早造成伤害
  Weak software engineering practices hurting sooner
• 不是软件工程师的“编码员”需求较少
  “Coders” who are not software engineers see less demand
• 工程师更难实现工作与生活的平衡
  Tougher work-life balance for engineers
• 被迫快速成长为高级工程师的初级工程师
  Junior engineers pushed to become seniors, fast
• 计算机科学教育日益成为新员工的必备条件
  Computer science education increasingly required for new hires
• 代码和软件领域的大规模爆发，必须有人对此负责
  A massive explosion in code and software, for which someone must be accountable

到目前为止，这是一个混乱的过渡阶段，我们工程师需要为更多并非由我们编写、却已经投入生产的代码负责并承担责任。So far, it’s a messy transition and we engineers are responsible and accountable for a lot more code that we didn’t write, but which is in production anyway.

非工程师也开始涉足智能体Non-engineers also getting into agents

一月底，我分享了一篇与我颇有切身关系的深度分析：我哥哥创办的初创公司 Craft Docs 拥有 30 名员工和 15 名工程师，在 Claude Cowork 发布前两周、ChatGPT Work 上线前数月，就通过为非工程师构建名为 Craft Agents 的自有 AI 工具套件，果断转向了 AI。At the end of January, I shared a deepdive that was pretty close to home for me: my brother’s 30-person, 15-engineer startup, Craft Docs, made its own sharp pivot to AI by building their own AI harness for non-engineers – called Craft Agents – two weeks before Claude Cowork was released, and months before ChatGPT Work launched.

当使用 AI 感觉无法提高效率时，Craft 抵制住了这种诱惑；但随着 2025 年 11 月发布的模型问世，他们发现 LLM 不仅适用于编码，也适用于客户支持等非工程工作。在深入分析中，我更详细地介绍了由工程师推动实现的非工程使用场景，例如：Craft resisted the temptation to use AI when it did not feel productive, but with the model releases of November 2025, they found LLMs are not only useful for coding, but also for non-engineering work like customer support. In the deepdive, I went into more detail about non-engineering use cases (which engineers enabled) like:

• 使用代理自动分流错误报告
  Automatic triaging of bug reports with agents
• 已添加到所有工作流的数据增强功能
  Data enrichments added to all workflows
• 客户支持“技能”，例如处理功能请求
  Customer support “skills” like processing feature requests
• 无需开发人员即可构建网站的营销团队
  The marketing team building websites without devs
• 人力资源部门自动化繁琐工作
  HR automating tedious work
• 财务自动化个人工作流
  Finance automating personal workflows

Craft Docs 似乎很早就顺应了这一趋势：让工程和非工程团队的员工都接入 AI 工具平台。如今，有迹象表明其他公司也在采取同样的做法：2026 年 6 月，OpenAI 的财务、招聘和法务等非工程部门转而使用 Codex：Craft Docs seemed early to a trend that has become more widespread, by having both their own engineering and non-engineering folks onboard to an AI harness. Now, there are signs other companies are doing the same: at OpenAI, non-engineering units like finance, recruitment, and legal moved over to Codex in June 2026:

从某些方面来说，知道不仅软件工程领域的工具和工作流程正在快速变化，科技行业的其他职能也都在经历同样的变化，或许会让人感到些许安慰！In some ways, it could be comforting to know that it’s not only software engineering where the tools and workflows are quickly changing: every other function in tech is experiencing the same!

现在有点乱。It’s messy right now

就在上周末，一名大型科技公司匿名工程师的吐槽引发了业内许多人的共鸣。一位用户名为 voxium 的工程师发文称（重点为我所加）：Just last weekend, a rant by an anonymous engineer in Big Tech hit a nerve with many people in the industry. An engineer with the username voxium posted (emphasis mine):

当前的工程现状糟糕透顶。我入职一家大公司担任新职位已经半个月了。这里没人懂任何东西。规格说明、代码、测试、PRD、工单、工单处理结果、报告等等，一切都是由 Claude Code 制作的。我们团队里没人喜欢这样。他们被迫尽可能多地交付。我已经多次听到高层管理人员说，推送代码不是瓶颈，那我们为什么还这么慢？人们每天工作 12 到 13 个小时，只为了按下回车键。没人读任何东西。企业里的人类什么都不自己做。这里的每个人，真的每个人，从 L1 到 L7 的工程师，做的都是同一件事。和 Claude 对话。没有任何胜利感。没人解决 bug。实际上，已经没人再思考了。一切都由 LLM 完成。这让人感到极度耗损灵魂。说实话，如果至少能给我们时间检查代码、弄清楚各部分在做什么，我倒不会介意。但不，目标就是交付。无论会发生什么。

“The state of engineering right now is horrible. It has been half a month since I started a new role at a big company.

Nobody knows anything here. The specs, code, tests, PRDs, tickets, resolution of those tickets, reports, etc., everything is made by Claude Code. Nobody on my team likes this.

They are being forced to ship as much as they can. I have heard multiple times from higher management that pushing code is not a bottleneck, so why are we slow?

People are working 12 to 13 hours a day just to press enter. Nobody is reading anything. Humans in corporate are doing nothing on their own.

Everyone, literally everyone, from an L1 to an L7 engineer here is doing the same thing. Talk to Claude.

There is no sense of victory. Nobody is resolving bugs. In reality, nobody is thinking anymore. Everything is done by LLMs. It is so soul-sucking.

I would not mind it, to be honest, if we were at least given the time to check out the code and see what is going where. But no, the goal is to just ship. No matter what happens.”

这篇文章之所以引发共鸣，是因为在许多 AI 使用更加广泛的地方，工程师确实会把思考“外包”给 LLM，最终除了把某些东西交付到生产环境之外，什么都不在乎。This post rings true because it is happening at many places where there’s more AI usage, engineers do “outsource” thinking to LLMs, and end up not caring about anything else except shipping something to production.

质量下滑Quality in decline

自年初以来，软件质量几乎在各处都持续下降，其中很大一部分是由对 AI 的过度依赖造成的，或者更准确地说，是把思考和决策外包给了 AI。7 月，我在经历了一连串无法解释的服务中断后，将我的视频播客迁出了 Spotify，而 Spotify 的工程团队似乎并没有真正为解决问题的根本原因而感到自豪或承担责任。Since the beginning of the year, the quality of software has been degrading pretty much everywhere, much of it caused by over-reliance on AI, or perhaps more accurately, the outsourcing of thinking and decision making to AI. In July, I moved my video podcast off of Spotify after a series of unexplainable outages, and Spotify’s engineering team seemed to take no real pride or accountability in fixing the root causes of the issue.

就在本周，Uber 在 Uber Eats 应用中将一项新功能部署到了生产环境——一种在订餐时选择额外配料的新方式——似乎完全没有经过 QA 测试：Only this week, Uber shipped a new feature to production in the Uber Eats app – a new way to select extras with your food order – with seemingly no QA testing:

在 Uber Eats 的这个全新的“附加项选择器”中，我同时发现了三个问题：Inside this new “add-ons selector” in Uber Eats, I noticed three bugs at once:

• “最多选择 999 个”：没有工程师、设计师或产品经理费心检查过这样的情况：餐厅没有填写应添加多少种配料的数字，或者填写了一个大得离谱的数字。我的屏幕上允许选择的配料最多只有六种，而不是 999 种，所以我甚至无法为我的汉堡选择添加 999 个面包的选项。
  “Choose up to 999”: no engineer, designer, or PM bothered to check what happens when a restaurant does not fill out a number on how many toppings to add, or adds a ridiculously large number. The most toppings that my screen allowed to be selected was six and not 999, so I could not even choose the option of 999 buns for my burger.
• 溢出处理得很马虎。在我任职于 Uber 期间，一条经验法则是：即使经过本地化，文本也绝不会溢出。Basilcummaynaise（荷兰语中的罗勒蛋黄酱）打破了这一规则，但仍然发布了。
  Sloppy overflow. A rule of thumb, during my time at Uber, was that text will never overflow, even when localized. Basilcummaynaise (basil mayo in Dutch) broke this rule but still shipped.
• 选择器存在功能性错误。我最初尝试从我最喜欢的墨西哥餐厅点餐：点一碗以不加米饭或碎小麦为底的餐品。底料选项中有“米饭”“碎小麦”或“不加任何底料”，但选择“不加任何底料”会被算作额外配菜，而且应用不允许订购不含底料的餐碗。
  Functional bugs in the selector. I originally tried to order from my favorite Mexican place: a bowl with no rice or bulgur as the base. There’s the option to select “rice”, “bulgur” or “nothing” as the base, but selecting “nothing” counts as an extra side, and the app doesn’t allow the ordering of a bowl with no base.

我使用 Uber Eats 应用已经很多年了，但这是我第一次看到如此马虎的功能发布。我猜，负责开发这一功能的开发人员和产品经理都已经“摆烂”了，不再进行应有的质量保证，并且以为代理会把这一切都处理好。除此之外，实在没有其他方式可以解释：三个漏洞被发布给了所有客户，却似乎直到我发帖指出后才有人注意到。值得肯定的是，Uber Eats 团队主动联系了我，目前正在着手修复这三个问题。I’ve used the Uber Eats app for years, and this was the first time I saw such a sloppy feature release. I assume that devs and PMs building it have all “checked out”, stopped doing proper QA, and assume that the agent will take care of all of it. There’s no other way to explain three bugs shipped to all customers but seemingly noticed by nobody until I posted about it. To the Uber Eats team’s credit, they reached out and are looking into fixing all three issues.

软件工程将比以往任何时候都更加重要Software engineering to be more important than ever

我个人已经度过了代理接管编程活动所带来的震惊和悲痛阶段。起初，我以为这一变化会减少工程师的工作量。但出乎意料的是，工作量似乎反而在增加：I’m personally past the shock and grief stages of agents taking over the activity of coding. At first, I assumed this change would reduce the amount of work for engineers. But, counter-intuitively, that actually seems to be growing:

• 我们需要更好地了解 LLM 的特性。LLM 让人感到熟悉，因为它们能够以过去只有人类才能做到的方式生成文本。但它们的可靠性较低，仍然容易产生幻觉，还会受到能力煤气灯效应等诸多问题的影响。它们也可能成本高昂且速度缓慢。
  We need to understand the characteristics of LLMs better. LLMs feel familiar as they can produce text in a way only humans could do before. But they are less reliable, still prone to hallucination, suffer from capability gaslighting, and many other problems. They can also be expensive and slow.
• 新系统需要经过工程化构建。如今，具备代理能力的“软件工厂”可以根据所提供的输入生成代码。但如何验证这些代码？检测缺陷或各种问题的过程有多大程度可以实现自动化？这是一个全新的领域，我们需要构建新类型的系统，而这些系统往往基于旧有理念。其中一个例子是 OpenAI 的软件工厂，另一个是 Ramp 的 Inspect 内部编码测试框架。
  New systems need to be engineered. Agentic “software factories” can now produce code, based on the input provided. But how is this code validated? How much can detecting defects or various issues be automated? This is a brand new area, and we need to build new types of systems, often based on old ideas. One such example is OpenAI’s software factory, the other one is Ramp’s Inspect internal coding harness.
• 非确定性的 LLM 可以生成确定性的代码。我认为，一个尚未得到充分探索和重视的领域，是利用 LLM 生成的确定性代码，在智能体式“软件工厂”中替代对 LLM 的使用。例如：与其对所有 PR 请求运行成本高昂且速度缓慢的 AI 代码审查，不如让 AI 生成能够捕获大多数常见问题的代码检查器？如果这可行，那么复杂的检查规则相比 LLM 调用将运行得更快、更可靠，执行成本也更低。
  Nondeterministic LLMs can generate deterministic code. An area I feel is under-explored and under-appreciated is the use of LLMs to substitute LLMs usage in agentic “software factories” with deterministic code they generate. For example: instead of running AI code review that is expensive and slow on all PR requests, could AI generate linters that catch the majority of common issues? If this is possible, complex lint rules would run faster, be more reliable and cheaper to execute than LLM calls.

新一类系统和产品将由真正“懂得”LLM 和 AI 工程的工程师打造。我们看到，绝大多数风险投资资金正涌入 AI 公司，因为 AI 创造了新的商业模式和收入来源，并颠覆了“传统”软件。例如，谁能想到公司会为每位工程师在 AI 编程工具上花费数万美元？又有谁能想到，AI 推理服务商这一类别会从两年前几乎不存在，发展到如今如此庞大的规模？New categories of systems and products will be built by engineers who “get” LLMs and AI engineering. We are seeing the majority of venture funding pour into AI companies because AI creates new business models, new revenue streams, and disrupts “traditional” software. For example, who would have thought that companies would spend tens of thousands of dollars, per engineer, on AI coding tools? Or that the category of AI inference providers would become as massive as it already is from barely existing two years ago?

这一技术变革将重新塑造科技行业的部分格局：赢家无疑会大获成功，而选择不采取行动的团队和公司可能会在执行效率上被灵活敏捷的竞争对手超越并取代。从很多方面来看，这对我们这些紧跟技术发展的软件工程师来说是个好消息。如今，各家公司都在投资创新，并愿意以市场顶薪聘请能够帮助它们构建 AI 产品或实现 AI 原生化的软件工程师。This technological change will re-jig parts of the tech industry: the winners will surely win big, and teams and companies choosing inaction could be out-executed and displaced by nimble competitors. And in many ways, this is great news for us software engineers who keep up with the technology. Companies are now investing in innovation and are willing to pay top-of-market for software engineers who can help them build AI products or become AI-native.

阅读本期内容所属的完整《The Pulse》，或查看本周的《The Pulse》。本周刊的内容包括：Read the full issue of The Pulse this is from, or check out this week’s The Pulse. This week’s issue covers:

1. Firebase：全球性故障，以及 Google 糟糕的处理方式。后端变更后，Firebase iOS SDK 发生崩溃，导致所有使用 Firebase Analytics 的应用崩溃了 2 到 6 个小时。Google 没有更新状态页面，也没有提供任何事后分析报告；对于一家以出色的事故管理实践著称的公司来说，这令人费解。
   Firebase: global outage & poor handling by Google. The Firebase iOS SDK crashed after a backend change, crashing all apps which used Firebase analytics for 2-6 hours. Google did not update the status page or offer any postmortem, which is a head-scratcher from a company known for standout incident management practices.
2. OpenAI 借鉴 AWS 玩法的平台战略？OpenAI 正在成为一个平台，用户可以将 ChatGPT 的支出分配给 16 家合作伙伴提供的开放模型和 AI 服务，而不只是 OpenAI 的模型。人们有理由问，Anthropic 是否会考虑类似的平台战略。
   OpenAI’s platform play from AWS playbook? OpenAI is becoming a platform where it’s possible to allocate ChatGPT spend on open models and AI offerings from among 16 partners, not just OpenAI models. It’s fair to ask if Anthropic will consider a similar platform play.
3. 更多关于企业转向开放模型的数据。Vercel 的 AI gateway 显示，模型支出中有 60% 流向开放权重模型，OpenRouter 的数据也显示，开放模型的使用率高于闭源模型。
   More data on companies moving to open models. Vercel’s AI gateway shows 60% of model spend goes to open weight models, and OpenRouter also shows open models are being more used than closed ones.
4. 为什么 CTO 和 VPE 们正成批离职：另一种看法。如果问题不在于“创始人模式”，而在于那些热爱构建软件的人，觉得借助 AI 工具，自己单干（或和一个小团队一起）就能做到呢？
   Why CTOs and VPEs are quitting en masse: another take. What if it’s not “founder mode”, but about people who love building software, feeling like they can do it solo (or with a small team) with AI tools?

订阅我的每周通讯，即可在收件箱中收到此类文章。内容相当精彩，也是 Substack 上排名第一的软件工程通讯。Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 software engineering newsletter on Substack.