摘要：OpenAI的“Codex”和“GitHub Copilot”可以在无需人工干预的情况下进行测试和修复错误，而Anthropic的“Claude Opus 4”、谷歌的“Jules”和亚马逊的“Kiro”等编码代理也正在陆续投入实际使用。

OpenAI的“Codex”和“GitHub Copilot”可以在无需人工干预的情况下进行测试和修复错误，而Anthropic的“Claude Opus 4”、谷歌的“Jules”和亚马逊的“Kiro”等编码代理也正在陆续投入实际使用。

随着编写代码行为本身的价值逐渐消失，工程师应该在哪里找到乐趣，又应该扮演什么角色？

中岛聪 (Satoshi Nakajima) 是一位自互联网诞生以来一直处于软件开发前沿的工程师，他谈到了自己在该领域从事人工智能工作时所培养的“独特的人类价值”。

我写代码已经很多年了，我意识到优秀工程师最终编写的代码的质量与其他工程师编写的代码的质量有很大不同。

在开发代码的过程中，代码不可避免地会变得越来越复杂，变得像意大利面条一样，因此需要频繁重构才能保持代码易于维护。这要求工程师能够意识到“代码越来越脏，需要重构”，并采取主动的措施。

然而，我目前还没有见过AI有这样的表现。AI很擅长“写出能用的代码”，但并不一定能写出考虑到可维护性和可扩展性的“好代码”。

我目前正在开发的 AI 原生软件MulmoCast （※）就亲身体验到了这一事实。

在开发MulmoCast时，我们使用了能够自由处理视频和音频的库“FFmpeg”。在FFmpeg中，图像和音频会按照它们添加到管道的顺序分配索引，之后引用时需要使用这些编号。这种规范非常繁琐，即使顺序发生轻微变化也可能导致操作中断。

AI 能够正确输出满足这些约束的代码，但是这些代码对于人类来说阅读和理解起来有些复杂，我一开始对此感到很困扰。

有一段时间，我们将开发留给了人工智能，但当软件变得有些复杂时，我们认为如果继续这样下去，它将变得无法维护，所以我们进行了大规模的手动重构。

具体来说，我们并没有直接处理 FFmpeg 命令，而是在其上叠加了一个小型结构，将索引抽象出来，将引用机制重新组织成一种人类易于理解的形式。这样一来，代码就更容易被人理解，也更容易维护和扩展。

这正是我在开头提到的“人类主动行动来维护代码质量”的一个例子。

(*) 一种演示工具，用于以多模式格式解释（或让其他人解释）各种想法，包括漫画、视频、播客、幻灯片和文档。

AI 现在是团队的一部分了。缩小范围并为其分配任务。

然而，对我来说，人工智能已经成为软件开发的有力伙伴。

前面提到的 FFmpeg 功能强大，但其脚本语言却难以掌握。因此，我们采取了先让“ChatGPT”或“Claude”编写代码，然后我们自己再将这些代码整合到开发中的方法。这个过程也是通过阅读 AI 编写的代码来学习并加深对库规范的理解。

虽然需要用FFmpeg拼接音频、叠加背景音乐、用图片生成视频等各种复杂的流程，但通过AI的运用，我们在开发开始后大约一个月就发布了Beta版，这样的速度如果没有AI的帮助是不可能实现的。

在软件开发中使用人工智能时，有时我会让它从头开始编写代码，有时我会让它在现有代码中添加功能，但在这两种情况下，我都会尝试“尽可能缩小范围，让它专注于一项任务”。最终，我可能会委托它处理更大范围的任务，但就目前而言，我感觉当范围缩小时，它能完成更高质量的工作。

顺便说一句，我会亲自审查AI编写的所有代码，只有在完全满意后才会将其纳入。从这个意义上讲，这与最近热门的“Vibe Coding”有所不同，而更接近于“聘请精通FFmpeg的初级工程师并让他们编写代码”的想法。

这种“高级（人类）与初级（AI）协作”的理念，是我目前开发风格的基础。因此，我并不太在意“人类从头开始编写代码”的含义。

代码尽量让AI来写，能填补的空白只有人类才能填补，这才是目前最高效的与AI交互方式。

至于目前由人类进行的重构，下一步，只要你要求，AI 就能做到，我希望，一旦它变得更聪明，甚至不需要要求，它也能做到。

人工智能甚至可以理解你输入代码的“想法”

人工智能的出现也极大地改变了工程师将自己的“想法”和“意图”融入代码的过程。

过去，工程师在设计或重构代码时，必须亲自为代码注入含义。但现在，人工智能甚至可以在一定程度上解读这种意图，并自动将其融入代码中。

其中，“Cursor”拥有出色的自动完成功能，这在重构时尤其有用。我经常重组代码，而Cursor能够理解我的意图并返回我期望的建议，这极大地提高了我的工作效率。

我们目前还没有采用未经审查的人工智能代码，但如果未来我们真的进入这样的时代，也不足为奇。就像我们在招聘工程师时，会根据其可信度而改变评价方式一样，我们与人工智能互动的方式或许也会随着我们自身的可信度而改变。

事实上，我的大儿子、BabyAGI 的开发者中岛洋平 (Yohei Nakajima) 在“氛围编码”这一术语被创造出来之前就已经开始练习了。

他将编码工作交给AI，几乎不做任何评审就直接开始开发。对他来说，代码“能用”比代码本身更重要。代码质量和易维护性才是次要的。

这与注重代码含义和结构的工程师的立场不同，但由于最初的目的和用途非常不同，所以我认为这没问题。

如果人工智能编写且无需人工监督的代码比例持续增加，那么不久之后我们就会看到无人能够理解其工作原理的软件的诞生。

在快速进化的过程中，人类的角色自然会随之发生变化，而“人类的角色就应该如此”这种想法并不可取。人工智能仅仅是一个工具，应该赋予它与其能力相符的任务，而人类只是简单地弥补人工智能无法完成的部分。

最终，人类将能够用自然语言向人工智能发出指令，并由人工智能编写所有代码。然而，这将是一个自然的进化过程，就像我们现在依赖编译器，不再自己编写机器代码一样。

但这是否意味着成为一名工程师所带来的快乐和成就感就消失了呢？我不这么认为。

就像用机器语言编写代码的乐趣变成了用 C 语言编写代码的乐趣，然后变成了用 Python 或 TypeScript 编写代码的乐趣一样，未来它将简单地转变为“通过使用自然语言发出指令让人工智能去做工作的乐趣”。

归根结底，工程师的根本乐趣在于一件事：“我能通过我的工作为世界提供什么价值？”即使在人工智能的帮助下，这个本质也不会改变。

真正发生重大变化的是所能提供的价值规模，以前需要100个、1000个工程师才能提供的价值，现在借助人工智能，一个人就能提供。

另一方面，人工智能的发展会减少能够提供价值的人的比例。这不仅适用于工程师，而且未来肯定会发生这种情况。

来源：夸克点评一点号