我读了戴夫·基斯对这位软件工程师的悼词，心里不断回到一个问题上。我们究竟是在告别什么？糟糕的正则表达式？为糟糕的数据编写另一个一次性解析器？为了没有明显原因而记忆一些奇怪的语法？为了构建系统所期待的特定咒语而损失一个下午，然后才能做你已经理解的事情？如果这些是死亡的内容，我不确定它是否需要葬礼。戴夫的论点比标题所暗示的更为乐观。到最后，他再次打开了棺材。技能仍然是我们的。工程师仍然对交付负责。也许，他写道，我们在墓碑上刻了错误的名字。我跟大多数观点都同意。我只是不认为我们完全需要墓碑。在我看来，这并不像是软件工程师的死亡。更像是一种重生。代价从来不是目的地 软件工程一直包含许多工作，只有松散地与正在解决的问题相关。你需要将一小堆丑陋的数据从一个系统移到另一个系统，因此你花了一整天的时间学习 CSV 解析器的边界情况。你确切知道一个服务应该做什么，但首先你必须记住六个月没触碰的框架的语法。你理解这个bug，但修复它被埋在一个陌生的代码仓库布局、三层间接引用和一个没有人记录下来的测试命令后面。我们之所以在这项工作上做得很好，是因为我们不得不这样做。其中一些甚至是有趣的。最终找到正则表达式或找到一行让整个系统行为奇怪的代码是非常令人满意的。但艰难并不等同于有价值。这其中的大多数只是我们在理解问题与更改系统之间所付出的代价。这从来不是目的地。如果一个代理可以处理更多的翻译，我并没有变得不再是工程师。我有更多的时间来处理那些最初需要工程师参与的部分。 工作转移 我每天都在使用编码代理。它们可以比我更快地在代码库中移动，在几秒钟内生成解析器，并且通常会记住我原本会查找的库调用。它们也会做出错误假设，误解本地约定，自信地使用不存在的API，并在测试修改内容之前就宣布胜利。打字变得更容易了。工程并没有消失。我仍然需要足够了解系统，以知道在哪里寻找。我必须意识到可行答案何时是错误的。我必须决定一个更改应该属于应用程序、插件、操作仓库，还是根本不属于。我要重现失败，选择权衡，测试结果，并支持进入生产的内容。代理可以写解析器，但仍然需要有人解释糟糕的数据，注意何时一行无声无息地消失，并决定当现实违反格式时该发生什么。这就是软件工程。这是我在《我不打每个字你读到的》一文中写到的同样转变。这项工作并没有消失。它转移了。现在更少的工作需要手动生成每个字符。更多工作是在方向、判断、验证和责任中进行。 我在学习更多，而不是更少 我担心的一个问题是，去掉艰难的方式也去掉了学习。如果机器写代码，任何人如何培养出判断代码是否正确的直觉？这确实是一个真实的风险。你可以接受出现在 diff 中的任何内容，不运行任何东西，不学习任何东西，以一种曾经不可能的速度交付垃圾。你也可以利用同样的工具，走进以前太昂贵而无法探索的计算领域。我用代理重写了一个 TypeScript 程序为 Rust，跨仓库追踪生产基础设施，了解陌生的数据库行为，构建终端工具，并测试那些本不该投入免费周末的想法。通过这些项目，我并没有从中知道更少的 Rust、更少的 Linux 或对涉及系统的了解更少。代理处理了足够的语法和脚手架，使我能够继续探索那些有趣的线索。学习循环变得更紧凑。问一个问题。检查答案。运行代码。破坏它。阅读实现。纠正假设。再试一次。这并不能替代理解。这是找到你理解边界的极快方式。责任在于我们继续跨越那个边界。如果我们只利用代理来避免知识，我们会成为更糟的工程师。如果我们利用它们更快地到达下一个问题，我们可以成为更优秀的工程师。 画布变大了 我发现最令人兴奋的部分不是同一个任务需要更少的时间，而是完全不同的项目现在可以融入人类的生活。软件在一个创意到其第一个有效形式之间，一直有着不寻常的高成本。即使是一个小创意，也可能需要一种新的语言、一个框架、一个身份验证系统、部署、测试和一堆填充材料，才能让你找出这个创意是否可行。