迈向自驱动的代码库
摘要
这篇文章探讨了AI代理如何自动化软件开发,讨论了当前AI编码工具的炒作周期,并建议未来工程将更专注于创造力和架构决策。
暂无内容
查看缓存全文
缓存时间: 2026/09/17 18:13
# 走向自动驾驶代码库 | Detail
来源:https://blog.detail.dev/posts/towards-self-driving-codebases/
智能体能够一次性解决那些真正有趣的游戏问题。在适当的限制下,智能体可以在复杂代码库中执行令人惊叹的迁移任务,甚至用新语言进行重写。但几乎所有“真实”的软件工程工作,目前仍由人类工程师主导。我们该如何实现让系统自主处理更大比例的工作,而无需人类时刻关注呢?
理论上,智能体应该能够自行构建完整的软件系统。为何在实践中表现如此糟糕?需要哪些新的基础要素才能使其运转?这条路能走多远?
## 超越“最大化令牌使用”之后是什么?
今年上半年,许多工程团队将大量工作转嫁给智能体集群与对抗循环。结果却相当令人失望:生产了海量可疑代码,而非开创性的卓越软件。所有这些令牌消耗的投资回报率,充其量只能说是勉强持平。
用技术成熟度曲线(Gartner Hype Cycle)的阶段来看,我们正处于“幻灭低谷期”。我们正在摸索如何兑现几个月前那个乌托邦式愿景——一个尚未在实践中奏效的蓝图。
(Gartner技术成熟度曲线展示标准采用阶段:技术触发期、期望膨胀峰值、幻灭低谷期、稳步爬升复苏期、生产成熟高原期)
接下来会发生什么?在历次技术采纳周期中,答案始终如一:摸索最佳实践,厘清我们闪亮的新工具适配何种任务(而非用它去敲螺丝),然后创造出那些在拿到新玩具时未曾意识到其必要性的基础构建模块。
一个有助我们理清思路的诊断性问题是:当软件能够自主驱动时,工程师们该做什么?
一个常见答案是:设置循环!我们曾编写代码,后来编写提示词,现在则设置智能体循环并大量使用`/goal`指令。
我认为这是误解。当前,搭建一个能产生正向软件变更而不烧钱的可行软件循环,之所以需要大量工作,主要是因为工具链尚未成熟。当我们拥有合适的组成部分时,这些循环将易于搭建、易于信任且具有成本效益。这不会是我们时间的主要去处。
相反,最有价值的工程工作将是*拥有好点子*。重要的想法仍然来自软件工厂之外。事实上,这整台机器的目的,就是最小化我们需要思考的非高价值事物。
- **杀手级功能依然是缔造公司的关键。**Cursor Tab、Descript的转录编辑、OpenRouter为推理供应商抽象统一计费接口,这些都是缔造公司的创意。除了创造力,好点子还需要对问题的深刻理解和领域专长,工程师需要为此贡献。[1]
- **杀手级架构依然具备高杠杆效应。**正确的简化能避免后期的复杂性激增,这体现为更少的缺陷和更便捷的产品迭代。少许前瞻性能让高价值功能在后期唾手可得。致力于构建更准确的数据模型、在关键位置添加队列、或为更优的产品测试方式搭建框架,仍蕴含巨大价值。
## 哪些部分应实现“自动驾驶”?
在“拥有好点子”之外,我们应努力将代码库工作转移到GPU上。例如,智能体能否独立处理这些完整职责?
- **检测并修复大多数缺陷。**例如:用户通过SSO登录时新功能无法正常工作;批量删除与单个删除对页面顶部行数更新不一致。智能体应该能捕获并修复这些缺陷。大多数缺陷往往具有*明确的预期语义*——我们无需人类工程师来判定软件应有的行为,甚至可能不需要文档或规格说明。
- **调试生产环境错误。**当出现错误时,智能体应能将其关联到近期提交、流量变更、基础设施差异或意外条件,并通常能为我们修补它。后端基本上不应再抛出500错误,浏览器控制台日志也应基本无错。
- **优化智能体。**我们到底应该在智能体提示词上投入多少精力?Braintrust、Raindrop、Arize或Langfuse能否隔离常见的智能体病态模式,提出更新建议,进行回测并部署?
- **前端一致性。**任何应用的视觉语言都应内部一致。应用应使用统一的字体、颜色、图标和间距。设计系统应自我引导并强制执行,人类仅作确认性决策。
- **应用精致度。**应用应按用户预期行为。Ctrl+点击应在新标签页打开链接。禁用按钮应提供原因说明。表单字段刷新后应得以保留。UI在移动端应合理渲染。UI应支持屏幕阅读器导航。此类基础体验预期多达数十项。
- **增长优化。**迭代表单转化率、优化用户引导流程、批量生成营销页面。存在一系列行之有效的实验方案,智能体应为我们执行这些方案。[2] 这并非暗示增长工作已死——它正焕发新生!但工作内容将更像策划与攻坚,而非单纯优化CTA。增长团队设定目标,智能体不仅针对代码迭代,更通过向用户展示变更并从中学习来适应现实,我们则得以聚焦更高层次的想法。
列表仍在延续。GitHub Copilot为我们提供了代码行级的自动补全,而智能体将为我们提供完整产品的自动补全。
## 缺失的基础要素
若要实现这一切,开发技术栈需要一些新的基础要素。这些都将成为标配:
- **智能体可读的开发环境。**绝大多数缺陷源自智能体无法察觉的区域(https://blog.detail.dev/posts/ai-bug-types/)。如果你的应用有智能体无法端到端演练的第三方集成,那些集成就会有缺陷。如果你的代码库没有良好的智能体-浏览器环境配置,整个前端对智能体而言就是盲飞区。诸如此类。
- **全局记忆。**智能体犯许多愚蠢错误其实没关系。不可接受的是它们反复犯同样的错误。如果你需要告诉智能体审计日志表是仅追加的,不应就地更新,这没问题;但如果你后续需要告诉每一个触及该区域的智能体,你就又回到了处理底层工作的循环中。我们需要建立能跨工具链工作的记忆系统——代码审查机器人需要知晓你在两周前纠正了编写该区域代码的智能体。当你斥责一个SRE机器人执行了不安全的生产操作时,智能体需要理解原因,并且所有未来的智能体都需要知晓这一纠正。全局记忆主要是等待工具改进的问题。要么我们会创建开放标准,要么我们会使用整合了日常智能体、审查者及所有必要功能的套件,或两者兼有。
- **代码库腐化预防。**智能体是否留下了死代码?是否存在做同一件事的五种方式,而本应只有一种?类型系统是否直观?数据模型是否与我们要交付的产品对齐?必须有东西处理这一切,否则代码库将开始陷入混乱。
我们仍然需要上一个时代的多数基础要素,例如APM(但将主要由智能体通过读取日志来查询,而非依赖小部件丰富的UI)、CI(但需更好的合并队列)以及A/B测试(但应可由智能体操作)。
## 如何构建智能体可读的开发栈?
工程团队当下需要投入大量精力之处,在于创建极佳的云端开发环境,使智能体能够以各种必要方式演练代码,甚至在可能知晓缺陷之前。**目前,开发智能体的制约因素是其运行环境,而非模型与框架本身。**
换言之:智能体已经足够出色,能够完成更多工作,*前提是*它们运行在足够好的环境中。但它们会在视线之外制造缺陷:例如智能体没有系统化方法复现的竞态条件,以及智能体对数据形态一无所知的慢查询。[3]
智能体存在盲区,就会犯错,从而限制信任度,导致工作需要更严格的审查,进而限制了我们能够委派的范围。
因此,工程团队当下能做出的最重要投资,就是让他们的开发环境对智能体极其友好。然而,目前这是一条充满重复性杂活和临时方案的无底洞,缺乏量化进展的方法。修复这些开发环境缺口需要好点子和专注的工程投入。具有代表性测试数据的本地开发环境是个动态目标。设计易于编写良好测试的新抽象层也绝非易事。诸如此类。这项工作充满挑战!
这项工作同样具有代码库特异性,并且至今仍是只有极少数人能熟练掌握的技艺。这也是许多软件工厂令人失望的原因之一。我们需要更好的方法来进行此类投资。
这意味着,帮助团队为智能体准备其开发工具链蕴含巨大杠杆效应。工程团队如何知晓哪些是唾手可得的成果?他们应如何优先处理工作以使其工厂运转更佳?如何衡量工作成效?若能将这门艺术转化为科学,帮助工程团队循序渐进地取得进展,工厂的轰鸣声将开始响起。
以下是我们对前进路径的最佳推测:
1. 挖掘代码库缺陷。精准识别那些重要的缺陷。
2. 修复缺陷。追踪那些使得验证修复正确性或缺陷真实性变得困难的缺口。
3. 利用修复这些缺陷的轨迹,来确定我们需要做的工作优先级,使代码库更适应智能体。
换言之:Detail的秘密计划是创建一个能自我引导其工作的产品,然后利用这些工作帮助工程团队明确应进行何种投资以及其效果如何。
如果我们能为任何代码库引导出一套有用的工作示例(例如,工程团队希望修复的缺陷),我们就能用它来确定提升任何代码库对智能体友好度的高投资回报率方法。我们可以衡量一个代码库的“智能体就绪”程度。工程师可以专注于改进其开发环境中的关键缺口,直至几乎所有底层缺陷都能被自主处理,然后他们就能聚焦于真正的高价值工作:构思功能创意,并设计能简化实现的抽象方案。
这将引领我们走向“生产成熟高原期”,也是未来六个月顶级工程团队的运作方式。不是最大化令牌使用,绝不是禁止AI,而是采用类似流程,逐步提升智能体就绪度,并渐进式地移交更多工作。
我们今天将发布这项工作的部分内容,你将看到这些理念随着我们构建这一愿景,持续融入我们的产品中。
## 这并非新事物
技术进步源于将底层关注点移交由系统为我们管理。
2010年代,我们将软件迁移至云端,从此不必再关心其物理运行位置,甚至无需知晓每个服务运行于哪个虚拟实例。更小、更专注的工程团队如今能构建成功的软件产品。我们得以栖身逻辑层,而平台处理其余一切。但我们经历了类似的过渡期,初期同样混乱,并在此过程中摸索出许多缺失的基础要素。
过去配置CI/CD需要数月,但如今我们拥有合适的基础要素和成熟的工具,除非你在迁移银行大型机之类,否则这只需一个下午。“循环”也将经历类似的转变。
我们正在招聘!如果你希望加入这段旅程,请体验:https://detail.dev/
---
[1] 如果“品味”曾经是差异化因素,现在则不然。但好点子仍然是。
[2] 某些应用领域已被充分理解。对于电商网站,你需要购物车放弃提醒邮件、“另外N名用户正在浏览!”小部件、划掉的锚定价格与更低价格并列等等。智能体应为我们执行这些方案。
[3] 智体还会出于防御任何可想象歧义的需要(而不知哪些风险真实存在),产生大量不必要的防御性代码。
相似文章
AI代理是否让构建软件比理解软件更容易?
一位开发者反思了AI编码代理如何能够快速构建和修改软件,但开发者往往失去对代码库架构和决策的理解,从而带来新的工程挑战。
@OpenHandsDev: 软件工程中下一个生产力飞跃不会来自工程师手动提示更多的编码代理。它……
文章讨论了未来软件工程的生产力将来自能够自主处理代码审查和测试等任务的AI代理,使开发者的角色转向监督。
软件开发正从“你能写代码吗?”转向“你能让正确的系统存在吗?”
文章认为,随着AI使代码生成变得更便宜,软件工程的价值从编写代码转向定义、监督、验证并拥有最终系统,这有利于积极采用AI工具的工程师,同时提高了验证标准。
🚀 开源开发者们:让我们一起打造一个让所有其他 AI 副驾驶都显得过时的编程代理。
文章呼吁开源开发者们共同构建一个超越现有 AI 副驾驶的卓越编程代理。
AI编程工具是在让开发者变得更好,还是仅仅加速了糟糕的判断?
一篇观点文章探讨了像Claude Code和Copilot这样的AI编程工具是否真正提升了开发者的技能,还是仅仅加速了有缺陷的决策,并强调了需要新的指标来评估工程中的人机协作。