作者被要求用LLM加速维护仅有exe的遗留软件

每年年初都是充满魔力的时刻，可能性无穷无尽，对新一年的期待令人兴奋不已。在我日常的工作中，团队刚从2024年成功发布一款大型产品中走出，所以进入2025年时我们确实是轻装上阵。就在这时，一个问题找上了我——一个以不祥措辞开头的问题：

“feel”这个词上稍微带点语调，永远是煤矿里的金丝雀。这是一种坦白：尽管这是你第一次听到这个问题，但它肯定不是第一次被问起。唯一的区别是，这一次轮到你来回答了。在这个案例中，问题是：

问题

你之前尝试过用LLM来做软件开发。我们有个产品确实需要更新，但我们没有时间也没有专业知识去处理它。

你怎么看接手这个项目，用LLM来加速开发？

这个技术栈完全不在我的能力范围内。那是一套任务关键的Visual DB2K软件，我们手头有一些源代码，但不足以从头构建。我们唯一完整的副本是一个.exe文件，除了最初安装的那台电脑之外，我们在任何电脑或虚拟机上都无法让它运行起来——它被小心翼翼地从一个版本的Windows迁移到下一个版本，历经了25年。我们手头的源代码是这期间一系列渐进式补丁，用来维持这个东西运转，直到唯一的维护者——一位长期承包商——能对它做点什么，把它升级到现代技术栈。

那位承包商几年前去世了，于是某个人就成了我。

2018年3月，“agent”这个概念还不算成型。人们很容易忘记agentic开发进步得有多快。Claude Code当时还是一个使用3.7 Sonnet的封闭研究预览版——说实话，Anthropic那时甚至还不是主要玩家。要说开发者在用AI，主要也就是：

话虽如此，考虑到给我的时间线、我能依据的东西少得可怜，以及我对这个技术栈有多不熟悉（db2k发布时我才大约19个月大，到我3岁时它就被dBase PLUS取代了），当时的游戏规则就是利用一切能利用的东西，把自己从坑里挖出来。我看着LLM的角色从内容索引和向量化，发展到轻量的“总结这些文件”生成Markdown，再到大约6个月内变成完整的代码编写。一个重要的转折点发生在我接到这个问题大约8个月后：项目上的大部分代码已经由LLM编写。

等到真正的基于agent的开发进入许多同行的视野时，我一直在努力走在前沿，思考发展到今天这个阶段开发会是什么样子。第一波是纯技术路线：我的LLM入门演讲是基于对Anthropic第一波agentic文档的理解构建的。“如何开展你自己的人质谈判”则是在agent的能力达到了你可能从一个非常初级的软件开发实习生身上看到的水平之后出现的，氛围也从“这些东西怎么工作？”转向了“它们会取代我们吗？”。

当我写那篇入门演讲时，我故意没有填完最后一节。它提出了一个问题，在当时纯粹是猜测，试图回答还为时过早。然而，我认为现在是时候认真尝试一下了：

我接下来要说的话对很多人来说是显而易见的，但对我这一代软件工程师来说却很容易忘记：曾经有一段时间，计算机远不是通用性或普遍可及的。1945年ENIAC的发明是第一次任何计算机能运行程序（复数），但更换程序意味着要重新接线，而且它绝不是你能放进车库的东西，更不用说桌面了。这种局面一直持续到70年代家用电脑成为一个可想象的念头。到那时候，我会说软件是一种手工艺品：内部开发，针对特定用例。说实话，我能找到的最早的通用操作系统的引用是IBM的OS/360，1964年发布。

我说手工艺，是最字面意义上的意思。想象一下数字宅基地：如果你需要一个程序，你最好准备好自己写。那段时间，人们在杂志附页里分享BASIC游戏。如果你想玩那个游戏，你得把印刷的文本逐字敲进终端然后运行。

一旦对计算机硬件的需求高涨，对计算机软件的需求也随之而来。像任何其他市场一样，供给必须跟上，而任何东西的手工生产从根本上与高供给不相容。物理商品的手工生产被工业革命的工厂所取代，所以你可能会想象某种软件工厂作为手工开发的替代。但软件不是汽车车轴或大头针——那么软件工厂到底会是什么样子？

大约在这个时候，像《编程作为理论构建》这样的论文开始发挥作用：工程师不再从数据结构和算法的角度思考软件，而是从想法如何逐步变成可运行软件的角度思考。我们也确实看到了你可能会在工厂车间看到的传统管理结构：一线工人、经理和高管：

这个三层结构会让一家公司处于其增长的第二阶段——不再是一小撮高管直接做事，而且有足够多的不同部分或举措来支撑多个团队。它不再是手工艺；现在是工厂布局的开始：

到这个时候，软件工程和生产工程的关注点开始碰撞。瀑布式和精益/敏捷等思想流派开始发挥作用，GitHub Projects、Jira等项目管理板成为全公司的标配。目标很简单：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）