物理天平分享 http://blog.sciencenet.cn/u/freefloating 天平的常态是失衡,天平的理想是平衡,我摇摆着,追求...

博文

从“写代码”到“定义问题”:AI Agent正在改变软件开发的瓶颈

已有 87 次阅读 2026-8-30 22:55 |个人分类:把问科研|系统分类:科研笔记

2026年8月26日,Lex Fridman 发布了与 DHH David Heinemeier Hansson的第二次5个小时长访谈;两人上一次对谈还是2025年7月。短短一年间,DHH 对 AI 编程的态度已经发生了非常明显的变化,某种意义上,这两次访谈之间的反差,本身就记录了过去一年 AI 编程范式变化的速度。

Lex Fridman 的播客长期关注人工智能、计算机科学、科学、哲学和技术人物,特点是访谈时间很长,往往持续数小时,因此嘉宾有机会把一个问题真正展开,而不是只给出几句适合社交媒体传播的结论。

DHH 则是软件开发领域一个很有意思的观察样本。他是 Ruby on Rails 的创造者,也是 37signals 的 CTO。过去二十多年,他一直以强调软件设计、代码简洁性和“漂亮代码(beautiful code)”著称。他并不是那种一开始就认为 AI 会取代传统编程的人。相反,他此前对于 AI 写代码相当谨慎。

但过去一年,他的态度发生了非常大的变化。

他说,2025 年底之后,AI 编程进入了一个完全不同的阶段。

这也是我认为这场访谈最值得关注的地方:它已经不再是在讨论“AI 能不能写代码”,而是在讨论一个更进一步的问题:

如果 AI 已经能够完成大部分代码实现,那么人类程序员究竟还在负责什么?

1. 从 Copilot 到 Agent:变化不只是“写得更多”

过去几年,人们熟悉的 AI 编程大多属于“助手(assistant)”模式。

程序员仍然是主要执行者。AI 帮忙自动补全一段代码,解释一个错误,生成一个函数,或者回答某个 API 应该怎么使用。

这种模式其实并没有改变软件开发本身的基本结构:

人设计,人实现,AI 提高效率。

DHH 认为真正的变化来自 AI Agent。

Agent 和传统代码补全最大的区别,并不是它一次可以生成更多代码,而是它开始能够承担一个相对完整的任务链:

理解问题,制定计划,阅读代码库,修改多个文件,调用终端和其他工具,运行测试,发现错误,继续修复,最后给出一个可以工作的结果。

人类逐渐不再需要告诉它每一步“怎么做”。

最初,人可能还会说:“这里建立一个 class。”;“用这个 loop。”;“数据库这样设计。”

但随着模型能力提高,DHH 发现这种过度指定实现方式(overspecification)有时反而会限制 Agent。

现在他更倾向于只描述问题和目标,例如:“这里太慢了。”;“我希望这个功能更简单。”;“我想要一个具有这种体验的编辑器。”

然后让 Agent 自己决定 implementation。

这其实意味着,AI 编程正在发生一次抽象层级的上移。

过去程序员主要回答:

How should this be implemented?这个东西应该怎样实现?

现在越来越多时候,人类主要回答:

What should exist?究竟应该做出什么东西?

2. “Software is product management”

DHH 在访谈里有一句我觉得非常重要的话:

“Software is product management.”

当然,这句话不能机械理解为“软件工程以后只剩产品经理”。

他的意思更接近于:

当 implementation 的成本快速下降以后,真正稀缺的能力会逐渐转移到另外一些问题上:

这个软件到底应该做什么?什么功能值得做?谁会使用它?什么东西过度复杂?

哪个方案更好?什么时候应该停止添加功能?一个产品真正想解决的问题是什么?

这些过去当然也很重要,只不过过去“把东西真正做出来”本身就已经非常昂贵。

一个想法可能需要五个程序员工作几个月。因此大量注意力自然集中在 implementation。

但如果未来一个模糊想法几个小时甚至几分钟就可以变成可以运行的 prototype,那么瓶颈就会发生变化。

你拥有十倍、百倍的实现能力,并不意味着你自动拥有十倍、百倍的好软件。

因为你也可能只是更快地制造出更多不值得做的东西。

这也是 DHH 对大型公司的一个有趣观察:许多公司其实从来不缺程序员,真正缺的是清晰的 vision、判断力和 taste。

3. “Taste”可能成为越来越重要的技术能力

Lex 和 DHH 都反复谈到一个词:taste,品味。

这个词放在软件工程语境里似乎有一点模糊,但实际上非常重要。

给一个人三个界面版本,他往往可以很快说:“这个最好。”

看一段程序设计,一个有经验的软件工程师也可能立刻感觉:“这个方案太复杂了。”

甚至还没有完全说清楚原因。

DHH 把这种能力称为一种 differential evaluation:与其要求人从零创造唯一答案,不如让 AI 生成几个候选方案,人类负责比较。

这可能会成为未来非常常见的工作方式:

  • AI 生成三个版本。

  • 人选择第二个。

  • AI 再沿着第二个版本继续发展。

  • 再产生几个方案。

  • 人继续判断。

过去人类主要承担 generation,计算机负责执行。

未来有些领域可能反过来:AI 负责大规模 generation,人类负责 evaluation、selection 和 direction。

4. 一个很反直觉的问题:传统编程知识还重要吗?

这场访谈里最有意思的一点,是 DHH 自己其实存在一种明显的张力。

一方面,他说自己现在越来越少亲手写代码。

甚至在新的 Omarchy Linux 项目中,他有一段时间几乎所有新增代码都由 Agent 生成。

他也发现,一个经验丰富的程序员有时反而会犯一个错误:

因为自己知道太多,就忍不住告诉 AI 每一步应该怎么实现。

而模型可能本来有更好的办法。

可是另一方面,DHH 自己仍然会看一眼 Agent 的输出,然后说:

“This looks too complicated.”“这个看起来太复杂了。”

Agent 往往随后承认:确实过度设计了,然后把实现砍掉一半。

这里就出现一个很值得思考的问题:

如果传统编程知识正在变得“不再需要”,为什么一个有二十五年经验的软件架构师仍然比普通人更容易发现这种问题?

我的理解是:编程知识可能不是消失,而是在改变作用。

过去,它首先是一种 production skill:你必须自己写 class、function、SQL、API 和 test,软件才能存在。

未来,它可能越来越像一种判断系统:

你未必亲手写代码,但你知道一个正常的软件系统大概应该长什么样。

你知道哪些复杂度是不必要的。

你知道哪里可能存在 coupling。

你知道某个修改为什么可能在另一个模块产生副作用。

换句话说:程序员脑子里的“software model”仍然有价值,只是手指亲自敲出每一行代码的价值正在下降。

5. “漂亮代码”还有多重要?

这又引出了访谈里另一个很有意思的问题。

DHH 过去一直强调 beautiful code。

为什么过去程序员如此在意代码简洁、可读、结构清晰?

一个重要原因是:

未来还会有人读它。

还会有人修改它。

还会有人 debug。

一个混乱的 codebase 会让下一次开发成本越来越高。

所以“漂亮代码”并不只是审美偏好,它长期以来有非常现实的经济价值。

但是,如果未来大量代码主要是由 AI 阅读、修改和维护,那么一个自然的问题就出现了:

Human-readable code 的价值会不会下降?

DHH 并没有简单回答“会”。

至少在现在,良好的 architecture 仍然非常重要。

复杂混乱的代码库同样会浪费模型的 context window、token 和推理资源,也更容易产生错误。

但这个问题真正有意思的地方在于:

我们今天奉为软件工程原则的很多东西,究竟有多少是“软件本身必然需要的”,又有多少实际上是为了适应一个历史条件:软件的主要维护者是人类。

如果这个条件改变,一些软件工程原则可能也会重新定价。

这可能是比“AI 会不会抢程序员工作”更值得长期观察的问题。

6. DHH为什么不建议年轻人预测未来?

访谈里还有一个我比较赞同的观点。

现在很多人都在问:

“那我还要不要学 Java?”

“要不要学 Rust?”

“还要不要读计算机?”

“未来什么岗位不会被 AI 替代?”

DHH 的回答非常简单:Don’t try to anticipate everything.不要试图提前预测一切。

因为现在连行业最前沿的人,也很难准确预测两个模型版本以后会发生什么。

一个今天需要专门学习数月的 Agent workflow,六个月以后可能已经被新的 harness 自动解决。

今天大家研究的 prompt engineering 技巧,一年以后也可能完全没有必要。

DHH 甚至认为,一个程序员如果过去一年完全没有关注 Agent,现在回来认真学习两周,也可能迅速重新接近前沿。

这和过去学习一个技术栈很不同。

以前 Ruby、Java、Linux、数据库等知识,可以积累很多年。

现在很多围绕具体 AI 工具形成的技巧,其半衰期可能非常短。

因此真正值得积累的,可能反而是那些不容易过时的能力:

  • 理解问题。

  • 判断结果。

  • 系统思维。

  • 产品意识。

  • 审美。

  • 表达模糊需求的能力。

  • 真正去做东西。

7. 编程会不会像骑马一样?

DHH 用了一个颇有挑衅性的类比。

未来手工编程,也许会有一点像今天的骑马。

人类当然仍然可以骑马。

很多人也非常喜欢。

这是一门技术,也是一种乐趣,甚至是一种艺术。

但现代社会已经不会因为“骑马很美”,就坚持把马作为主要交通工具。

同样,未来也一定有人继续手写代码。

有人会因为喜欢 Ruby 而写 Ruby。

有人继续为 Commodore 64 或 Game Boy 做程序。

有人把 programming 当 craft。

但是“值得做”和“经济上必须这样做”并不是同一件事。

DHH 自己过去是极端重视手工代码的人,但现在他说了一句很能说明这种转变的话:

“I became a programmer because I wanted programs.”

“我成为程序员,是因为我想要程序。”

换句话说,他最初真正想做的,并不是编写 if statement。

他只是脑子里有一些不存在的东西,希望它们变成现实。

过去唯一的办法是学习 programming。

如果未来自然语言也能把想法变成软件,那么他并不觉得自己背叛了编程。

反而像是终于回到了最初的目的。

8. 最值得关注的,可能不是“AI会不会取代程序员”

DHH 在这场访谈中也有不少非常激进的判断。

例如,他认为我们已经看到了不少类似 AGI 的迹象;他对 Linux 在 Agent 时代的未来极度乐观;对于软件生产率提升的速度,也明显比很多人更乐观。

这些预测最后是否正确,现在都很难判断。

但我认为这场访谈真正值得关注的,并不是这些最夸张的预测。

而是一个已经正在发生、而且相对具体的变化:

软件开发的瓶颈,正在从“如何把东西实现出来”,逐渐转向“什么东西值得实现,以及如何判断它实现得好不好”。

过去,idea 很便宜,implementation 很贵。

未来有可能逐渐变成:

implementation 越来越便宜,而好问题、好判断、好 taste 和真正 coherent 的 vision 越来越贵。

如果这个趋势继续下去,那么“程序员”这个职业未必会简单消失。

但是“程序员”这个词所代表的工作内容,可能会发生一次相当深刻的重新定义。

也许几年以后,我们再回头看今天,会发现真正重要的问题从来都不是:“AI 会不会写代码?”

而是:“当写代码不再是最困难的部分以后,人类究竟想让什么东西存在?”



https://blog.sciencenet.cn/blog-42659-1550231.html

上一篇:当无知开始以答案的形式出现:AI时代关于"知其不知"的一次追问




    
收藏 IP: 70.48.189.*| 热度|

1 杨正瓴

该博文允许注册用户评论 请点击登录 评论 (0 个评论)

数据加载中...

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2026-9-3 15:02

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部