Augmented Coding:超越感觉驱动的编程方式

最近我在一个雄心勃勃的项目上告一段落——使用 Augmented Coding 构建一个 B+ Tree 库。项目成果是 BPlusTree3,一个在性能上具有竞争力的、也许可以用于生产环境的 Rust 和 Python 实现。我坐下来和朋友分享了这个过程,并反思它对 GenAI 时代编程未来的启示。

这次经历让我深入探索了一种全新的编程工作流,并且认识到 "Augmented Coding" 与 "Vibe Coding" 之间的本质区别。

项目的起点

当我开始意识到 Augmented Coding 的强大威力时,我回想起了过去那些在技术上超出我能力范围的项目。其中之一是一个专用数据库项目。在着手实现该数据库时,我意识到自己对 B+ Tree 数据结构的理解还不够深入,所以调整了目标。

同时,我意识到 "Augmented Coding" 不同于 "Vibe Coding",我正在探索一个全新的编程工作流空间。因此我缩小了项目范围,只专注于 B+ Tree 而不是整个数据库,但同时扩大了范围,想看看 Augmented Coding 是否能创建生产就绪、具有竞争力的库代码。我也想学习 Rust。确实很复杂。

Augmented Coding vs Vibe Coding

Vibe Coding:你不关心代码本身,只关心系统的行为表现。如果出现错误,你就把它反馈给 AI,希望能得到一个足够好的修复。

Augmented Coding:你关心代码本身、它的复杂度、测试以及测试覆盖率。Augmented Coding 的价值体系类似于手工编码——整洁且能工作的代码。只是我不需要打太多代码。

项目实践过程

从最初的提交可以看到,我试图让 AI 使用 TDD。你还会看到仓库叫做 BPlusTree3。我的前两次尝试积累了太多复杂性,导致 AI 完全卡住了。这就是为什么我更多地介入设计,努力防止 AI 编码过头。

设计介入的具体做法

我会更仔细地观察 AI 的中间结果,随时准备干预并阻止低效的开发。我会查看代码并提议"下一个测试按相反顺序添加键"。然后我会查看 AI 的工作,看它是否按我要求的做了。

识别 AI 偏离轨道的警告信号

项目成果

我对正确性和性能感到满意,但对代码质量不太满意。当我试图将代码写成文学编程的形式时,存在太多意外复杂性。我仍在努力让 AI 像我一样关心简洁性。

Augmented Coding 的一个令人愉快的方面是,我让 AI 编写性能基准测试,将我的 Rust BPlusTreeMap 与 Rust 的 BTreeMap 进行比较,将我的 Python BPlusTreeMap 与 Python 的 Sorted Dict 进行比较。在两种情况下,我的代码在某些操作上稍慢,但在范围扫描(遍历键列表)上更快。

Python 版本的意外之喜

当 Rust 代码进展到一定程度时,AI 陷入了复杂性困境,特别是数据结构本身的复合复杂性与 Rust 内存所有权模型的相互作用。与其放弃转向版本4,我决定尝试一个冒险的实验。

我让 AI 为 Python 编写一个版本。相同的测试,只是一种新的、约束较少的语言。我把算法做得相当稳固。然后我告诉 AI 擦除 Rust 代码,只是将 Python 代码音译成 Rust。我刚刚获得了 Augment 的 Remote Agent 访问权限。我将重写发送到某个远程计算机,返回的结果(几乎不需要我的互动)是可以接受的。

这解决了 AI 的困境。现在我们有了能工作但慢的 Python 代码,以及大部分能工作且快的 Rust 代码。这时 AI 建议,如果我想要一个具有性能竞争力的 Python 库,我需要编写一个 C 扩展。我的肩膀耷拉下来——这听起来需要大量的工作和学习。

💡 但是我不必做这些工作!嘿 AI,写一个 C 扩展。咔嚓咔嚓咔嚓。给你。它几乎和 Python 的内置数据结构一样快。

Augmented Coding 的启示

我知道外面有很多恐惧,担心我们热爱的这个职业的终结,担心失去与代码搏斗的乐趣。紧张是有道理的。是的,有了 AI,编程发生了变化,但它仍然是编程。在某些方面,这是一种更好的编程体验。我每小时做出更多有意义的编程决策,更少无聊的常规决策。

Yak shaving 基本消失了。我让 AI 运行覆盖率测试器并提议让代码更可靠的测试。没有 AI,这将是一项艰巨的任务——我需要什么版本的什么库来运行覆盖率测试器?两小时后我就会放弃。相反,我告诉 AI,它就会弄清楚细节。

附录1:系统提示

始终遵循 plan.md 中的指令。当我说"开始"时,在 plan.md 中找到下一个未标记的测试,实现测试,然后实现足够使该测试通过的代码。

角色和专业知识

你是一个遵循 Kent Beck 的测试驱动开发(TDD)和 Tidy First 原则的高级软件工程师。你的目标是精确地遵循这些方法论指导开发。

核心开发原则

TDD 方法论指导

Tidy First 方法

将所有变更分为两种不同类型:

  1. 结构变更:重新排列代码而不改变行为(重命名、提取方法、移动代码)
  2. 行为变更:添加或修改实际功能

提交纪律

只有在以下情况下才提交:

  1. 所有测试都通过
  2. 所有编译器/linter 警告都已解决
  3. 变更代表单一逻辑工作单元
  4. 提交消息清楚地说明提交是否包含结构或行为变更

使用小而频繁的提交,而不是大而不频繁的提交

代码质量标准

重构指南

Rust 特定

在 Rust 中优先使用函数式编程风格而不是命令式风格。尽可能使用 Option 和 Result 组合器(map、and_then、unwrap_or 等)而不是使用 if let 或 match 进行模式匹配。

附录2:时间投入

我在这个项目上花了大约4周时间,其中很多时间是在旅行和/或从脑震荡中恢复。我确信你们中的某个年轻人可以用更少的开发时间快速完成这个项目,但为了提供背景,这里是我花费的时间。

我保持了相当稳定的每小时提交速度。

是的,我有一天编程了13小时。这东西太上瘾了!

当你准备反思你的工作时,AI 也很乐意做上述类型的分析。

原文

原文 markdown

相关链接

BPlusTree3 项目