从手写代码到AI管理的软件:DHH用Claude重写Python库
Rails 创始人 DHH 让 Claude Fable 5 以多智能体方式把 Python 库 TerminalTextEffects 重写为 Rust,Codex 也完成类似任务。这一实验显示,程序员的价值正从手写代码转向定义目标、系统设计和验证 AI 生成的软件。

从手写代码到AI托管软件:DHH用Claude重写Python库
引言
一年前,Rails创始人David Heinemeier Hansson(DHH)还是捍卫手写代码乐趣的知名开发者之一。
如今,他的立场已大不相同。
在与Claude Code和Codex相处更长时间后,DHH最近使用Claude Fable 5将Python库TerminalTextEffects用Rust重写。据源文章报道,该项目消耗了约1100万token,且主要以无人值守的智能体工作流完成。
结果令人瞩目:启动时间据报道从87毫秒降至2毫秒,渲染速度提升约9.6倍。
这次实验也引发了一个更大的问题。如果一位经验丰富的程序员可以将大规模重写任务交给AI智能体,并在几乎不直接干预的情况下获得可用的结果,那么五年后程序员究竟还需要做什么?
把键盘交给AI,然后退休?
DHH与去年立场之间的对比显而易见。
2025年5月,他发表了**“编程应该是一种感觉!”**,主张AI应更接近结对程序员:适合查看API、回答问题、帮助解决特定问题,但不应取代编写代码本身的行为。
源文章引用了更强烈的立场:如果开发者最终不得不把键盘完全交给AI,DHH表示他宁愿退休。
在与Lex Fridman的六小时对话中,DHH还描述了当AI反复为他生成代码时,失去“肌肉记忆”的感觉。
其中一个例子涉及构建Linux发行版。他让AI多次生成同一个Bash条件语句,却发现自己因为并未亲手动过这个语句,内心并不觉得真正学会了它。
这为他带来了一个更深层次的问题:AI辅助编程是否会逐渐削弱开发者学习软件工程的方式?
但据源文章称,到2026年4月,他的立场已转向智能体优先的工作流。
如今,他在公开探讨:当键盘不再是主要交互界面时,软件开发会是什么样子?
Claude Fable 5拆解Python库并用Rust重建
DHH选择的项目是TerminalTextEffects(TTE),一个终端视觉效果引擎,既可作为命令行应用程序使用,也可作为Python库使用。
TTE提供文本移动、颜色、渐变、动画及其他终端视觉效果。其公开仓库将其描述为终端视觉效果引擎,并记录了CLI和Python库两种用法。
源文章称,DHH要求Claude用Rust重写该项目。
由此产生的Rust项目名为ttfx,已置于DHH的Omarchy组织下。据文章介绍,新版本可运行37种效果,打包为约3MB的可执行文件,无需Python运行时。
据报告的执行为时约3小时11分钟。
Rust实现包含约21,000行主要代码,接近原始Python版本的规模。
代码库。
工作流程也与传统的“AI 自动补全”截然不同。
来源文章提到,八个代理在独立分支上并行工作。它们各自阅读代码、生成实现、编译结果、运行测试、修复失败,然后进入下一轮。
从这个意义上说,“一次完成”的描述并不意味着AI通过单个生成就产出了所有内容。而是指DHH移交了任务,让代理自行承担开发循环。
Codex 被赋予了同样的任务
DHH用Codex重复了这个实验。
根据来源文章,一个提示词就足以产生另一个强劲的结果。不过,据报道,Codex版本耗时约长30%,成本约为43美元,约合290元人民币。
这种比较很有价值,因为它将注意力从“AI编程要么神奇要么糟糕”这种简单化的观念上移开。
两个不同的编程代理可以被赋予相同的广泛任务,并产出可用的结果,同时在速度、成本和工作流程行为上有所差异。
Anthropic团队也注意到了这个实验。
据报道,Claude Code的创造者Boris Cherny公开回应了这一结果,而Anthropic研究员Thariq询问DHH在重写中投入了多少规划或工作流设计。
DHH的回答可以说是最令人惊讶的部分。
他说他基本上让Claude制定计划,然后就放手不管了。
没有精心设计的预建工作流,没有一长串手动定义的里程碑,也没有持续的干预引导。
这种方法是刻意采取不干预的态度。
一次完成并不意味着盲目
这里有一个重要的区别。
一个完全自主的编码任务仍然依赖于代理拥有足够的信息来判断成功的标准是什么。
来源文章称,DHH首先要求Claude制定计划,然后让代理自行执行、测试和迭代。
这更接近于委派一个软件工程项目,而不是要求自动补全系统生成接下来的十行代码。
这种代理式开发风格在很大程度上依赖于:
- 具有可理解结构的代码仓库。
- 强大的自动化测试套件。
- 清晰的构建和运行命令。
- 创建分支和合并更改的能力。
- 能够检查失败并重试的代理。
没有这些基础,“一次完成”的自动化就会变得不可靠得多。
更大的展示:Bun的百万行迁移
TerminalTextEffects仍然是一个相对较小的项目。
因此,来源文章指向了一个更大的案例:Bun,由Jarred Sumner创建的JavaScript运行时。
Bun历来围绕Zig构建。在2026年,其代码库经历了一次向Rust的重大迁移,并广泛使用了AI编码代理。
来源文章将这一工作描述为大约百万行的迁移,在不到两周的时间内完成。
后来的公开记录证实,Bun的Rust重写已合并到其主仓库中。GitHub上关于重写的拉取请求于2026年5月14日合并,此次迁移用Rust优先架构取代了此前的Zig优先构建路径。
迁移比简单的“AI 重写了 Bun”要更加细致。
Jarred Sumner 的公开叙述,经 Simon Willison 总结,描述了一个复杂的主体性工作流,其中包含了动态任务拆解、试运行、对抗性审查以及反复验证。
这是一个有意义的区分。
大规模 AI 辅助软件迁移仍然需要大量的工程架构。区别在于,一旦周边系统设计得足够完善,大部分实现工作现在可以委托给智能体。
代码的边际成本正趋于零
源文章从这些例子中得出了一个更大的结论。
随着编码智能体能力的提升,生成另一个实现的边际成本持续下降。
生成代码正变得越来越便宜。
测试、重构、语言间移植以及针对缺陷的迭代,越来越可以由智能体并行完成。
这改变了软件开发的成本结构。
问题不再仅仅是:
我们能雇佣多少开发人员来编写这段代码?
它越来越变成:
一位开发人员可以将多少有用的软件任务委托给一组 AI 智能体?
这就是从 AI 辅助编程向 AI 管理式软件开发 的转变。
下一代的程序员可能更像驯龙师
显而易见的恐惧是,如果直接编写或阅读代码的人变少,程序员就会消失。
源文章认为,这个结论过于简单。
“没有人手写代码”并不意味着“没有程序员”。
工作内容可以发生转变。
与其花费一天中大部分时间逐行实现功能,开发人员可能会将更多时间用于:
- 定义需要构建的内容。
- 设定约束和接口。
- 设计测试体系。
- 审查架构和权衡取舍。
- 检查 AI 生成的代码是否确实正确。
- 决定哪些应当自动化,哪些不应当自动化。
在这种模式下,稀缺的技能不再是敲击语法。
而是知道 什么值得构建,以及正确的行为究竟意味着什么。
当 AI 编写代码时,什么变得有价值?
如果实现变得越来越廉价,其他技能就变得更加有价值。
产品判断力
仍然需要有人来决定什么问题值得解决。
AI 可以快速生成十个实现,但这并不能告诉你哪个问题具有商业价值,哪个权衡取舍至关重要,或者哪个功能应该优先构建。
系统设计
智能体可以编写函数和类,但更大的系统仍然需要边界、接口、数据模型、部署规则和可靠性要求。
测试
AI 能生成的代码越多,自动化测试就越重要。
如果没有强大的验证层,提高编码速度只会增加可能出错的代码量。
技术方向
必须有人告诉智能体要遵守哪些约束。
这包括性能预算、兼容性要求、安全边界、依赖关系以及长期维护目标。
换句话说,人类的角色在抽象层次上向上移动。
未来可能更少关于编码,而更多
关于引导
源文章中的示例指向了编程的另一种定义。
开发者可能仍然需要深入理解代码,但主要产出不再必然是源文件本身。
产出是使正确软件得以出现的需求、约束、测试与判断系统。
这就是为什么即使手工编码变得不那么核心,经验丰富的工程师仍然可能具有价值。
那些理解架构、故障模式、用户需求和系统行为的人,将更有能力指挥自主编码代理。
常见问题
DHH 真的用 AI 重写了 Python 库吗?
据源文章所述,是的。Rails 创始人 David Heinemeier Hansson 使用 Claude Fable 5,通过一种高度放手的多代理工作流,将 TerminalTextEffects 从 Python 重写为 Rust。
什么是 TerminalTextEffects?
TerminalTextEffects(简称 TTE)是一个终端视觉特效引擎,也可作为 Python 库使用。其公开文档描述了文本移动、颜色、渐变、动画及其他终端视觉处理的效果。
Rust 重写与普通 AI 编码有何不同?
源文章描述了多个代理在独立分支上工作、编译代码、运行测试、修复失败并合并结果。关键区别在于,AI 处理了大部分开发循环,而不仅仅是建议零散的代码行。
Codex 也完成了重写吗?
源文章称,DHH 给 Codex 分配了同样宽泛的任务,也获得了另一个出色的结果。据称耗时大约多出 30%,成本约为 43 美元。
Bun 也是用 AI 代理重写的吗?
是的。Bun 的大规模 Zig 到 Rust 重写是在大量 AI 代理辅助下完成的,重写后的 Rust 优先代码已于 2026 年 5 月合并入主仓库。
如果 AI 编写大部分代码,程序员会消失吗?
不一定。可能的变化是,程序员花在输入实现细节上的时间减少,而花在定义需求、约束、架构、测试和验收标准上的时间增多。
在 AI 编码工作流中,哪些技能最重要?
强大的系统设计、测试、调试、产品判断力,以及定义清晰约束的能力变得尤为重要。知道如何审查和验证 AI 生成的代码也至关重要。
相关工具
- Claude Code:Anthropic 的代理式编码环境,用于仓库级软件开发工作。
- OpenAI Codex:OpenAI 的编码代理,用于多步骤软件开发任务。
- TerminalTextEffects:源文章中讨论的 Python 终端特效项目。
- Bun:一个 JavaScript 运行时,于 2026 年完成了从 Zig 到 Rust 的重大重写。
- Rust:用于重写 TTE 和 Bun 实现的系统编程语言。
相关链接
- TerminalTextEffects GitHub 仓库:TTE 的官方源码仓库。
- [TerminalTextEffects
文档](https://chrisbuilds.github.io/terminaltexteffects/):该项目的使用和开发文档。
- Bun GitHub 仓库:Bun 的官方源代码仓库。
- Bun Rust 重写拉取请求:已合并的 Zig 到 Rust 迁移拉取请求。
- Rust 官方网站:Rust 语言的官方文档和生态系统资源。
- Claude Code:关于 Anthropic 编程代理的官方信息。
摘要
DHH 的 TerminalTextEffects 实验是一个有用的例子,展示了 AI 编程代理如何改变软件工作的单元。开发者不再要求 AI 一次只编写一个函数,而是越来越多地将整个重构和迁移工作委托给代理团队。
Bun 的重写则在更大的规模上指向了同样的方向:当仓库、测试、工具和工作流程足够强大时,AI 现在可以参与广泛的、多步骤的软件工程工作。
最大的变化可能不是 AI 编写了更多代码,而是程序员的工作从编写代码转向定义代码应实现的目标并证明其确实实现了目标。