AI会让程序员失业吗？

在 AI 编程工具层出不穷的今天，“氛围编程”盛行:写几句自然语言，AI 就能拼出一套功能，仿佛你懂、又不需要懂代码。但当系统进入真实生产环境，种种问题接踵而至。Augment Code 的工程负责人 Chris Kelly 最新演讲《Vibes won’t cut it》就是一剂现实主义强心针。他指出:AI 可以帮你写代码，但永远写不出“生产级软件”。这不仅是技术的思辨，也呼应了近来多位一线 CTO 的反馈——AI 编程不是失业的工具，而是失控的诱因。以下为完整演讲实录。

开场:AI会让程序员失业吗？

感谢大家的到来。如果你们还没有心理准备的话，我得遗憾地告诉你们——按照AI和AI编程的炒作来看，明年这个时候，我们这里一半的人可能都不会再从事这个行业了。我看到了很多这样的论调，毫无恶意，这些都是非常聪明的人说的话。但我认为他们可能是错的。不是因为我觉得AI编程不会发展到重要的地位，而是因为他们很可能已经很久很久没有真正接触过生产系统了。也许他们认为"生成30%的代码"并不是他们想象的那回事。

大型代码库的现实

因为AI生成的代码本质上还是代码。他们在这个领域没有真正认识到的一点是，他们工作的代码库规模非常庞大，基本上关于这些代码、架构、基础设施的每一个决策都已经为他们做好了。所以如果我要为现有的数百万行代码生成30%的新代码，那么这些代码能做什么或应该做什么，其实没有多少发挥空间。就像是再加一个按钮而已。

如果你曾经和Meta的工程师聊过，他们会告诉你，他们花了6个月时间在广告平台上做一个按钮。就是这样，这就是他们6个月的工作内容。所以对于AI真正能够影响的那种具有发挥空间的定义，其实是很有限的。

AI仍在编写传统代码

其次，AI仍在编写代码。这是我们写了50年的代码，相同的编程语言，没有什么不同。这些代码仍然需要在生产环境中的某个地方运行。如果你不熟悉大型生产系统的话——即使你写出了很好的代码，在复杂系统中，事情也会出错。复杂系统具有突发性行为，这些行为不会出现在单行代码中。所以我们仍然需要运行这些东西。那么谁来修复它？谁来检查它？如果没有软件工程师，谁来理解这些细微差别？所以我认为我们仍然需要软件工程师。而且历史总是重演。这不是*次有人告诉我，我的职业生涯结束了。我在这个行业的时间已经不短了，但任何经历过15年前DevOps转型、云计算的人都知道，我认识的所有过去负责机架服务器和内核启动的系统管理员，现在都得到了加薪，都在做更有价值的工作。他们对现在做的工作更加满意。这并不是新鲜事，这只是一个不同的抽象层次。拖拉机没有消灭农场，它们只是消灭了农场工人和马匹。是的，行业肯定会发生变化，但拖拉机没有消灭农业。我们仍然需要务农。

什么是"氛围编程"？

那么什么是"氛围编程"呢？这里有人是氛围程序员吗？没关系，不用羞耻。有谁认为自己是专业的软件工程师？很好。氛围编程，如果你不熟悉这个术语的话——我想这个房间里的每个人都熟悉，但我还是快速总结一下——基本上就是让AI写所有的代码，思考所有的代码，而你完全不检查代码。只要问:它能做我需要它做的事吗？如果是的话，我就继续，让它继续写，继续写。不检查代码，不编辑代码。

生产级代码的要求

但这不是我们要讨论的。我要讨论的是如何编写生产级的代码。当我说生产级时，我的意思是你有四个9的可用性。你知道四个9意味着什么吗？这就是生产级代码。你有成千上万的用户，几十GB的数据。我们谈论的是今天运行互联网的软件。氛围编程无法胜任这个任务，因为代码中有很多细微差别。

代码不是工作本身

首先，让我们澄清一个误解。代码不是工作本身，就像蓝图不是建筑师的工作一样。蓝图是作为建筑师的工作产出物。作为软件开发者的工作产出物是代码。当然，我必须输出一些代码，但我要对我的软件应该做什么、我在写什么类型的东西、我要引入什么包做出成千上万的决定。所以，让我们停止把生成代码与软件工程的艺术和工艺混为一谈。这些是不同的东西。是的，LLM很擅长生成代码，但这和编写生产级软件是一回事吗？

"*的代码就是没有代码"

Stack Overflow的创始人Jeff Atwood——愿Stack Overflow安息——说过一句非常聪明的话:*的代码就是没有代码。我认为这是真的，因为每一行代码都伴随着负担。我必须维护那些代码，我必须调试那些代码。所以我生成的每一行代码，我都必须对其负责。我们花了太多时间思考AI能生成多少代码？谁在乎它能生成多少？它生成得越多，我的处境就越糟糕，系统的处境就越糟糕。我们希望在其中放入尽可能少的代码。

代码的权衡

因为所有代码都有权衡。我们认识到这个包有这样的性能特征，这种方法有那样的特征。我能给你的*例子是单体架构、微服务架构和事件驱动系统之间的区别。这些架构需要做出多少决定？你必须做出的选择来做同样的事情？如果你在所有这三种架构中都构建了一个航班预订系统，你必须做出成千上万的个别决定。LLM不做决定。它们生成文本。它们生成模式。在某种规模下，在某个点上，我的软件没有模式可循。这里有人运行过有点独特的生产软件吗？有一堆特殊性，只有Bob知道那个怎么工作，只有Jane能修复那个？她六年前写的，已经不在这个项目上了？这就是软件。所以在某种规模下，模式匹配不再有效，因为所有进入该软件的细微差别都无法进行模式匹配。所以当软件在凌晨两点出现故障时——这是我携带寻呼机的创伤——氛围无法修复bug。必须有人诊断那个问题。

软件工程的本质

对我来说，软件工程的工作是什么？安全地改变软件。这20年来一直是我的工作——如何对软件进行改变，无论是添加新功能还是改变现有代码，以及如何安全地做到这一点，使软件不会宕机，用户能得到他们想要的东西，数据是安全的。我们在行业中是如何做到这一点的？我们用很多不同的方法来解决这个问题:

·我自己的知识——在我能安全地进行更改之前，我必须对代码库了解很多

·版本控制

·测试——这就是我们编写测试的原因，以捕捉"如果我改变了这个，那边的东西会坏吗？"

·类型系统

·部署策略

AI能开始帮助我们吗？AI对代码库有的上下文和理解能帮助我们吗？可能可以。在Augment，我们相信上下文是AI代码生成中最重要的部分，所以我们认为我们可以解决这个问题。

生产环境的现实

但这并不改变我仍然必须关心生产环境的事实。让我们假设我们正在编写代码——好的，未来就在这里，我必须使用AI。我发现这个领域最有趣的是，专业软件工程师是我看到的最后采用AI的人群。我以前从未见过这种情况。我见过版本控制系统的变化，我在GitHub早期就在那里，所以经历了大规模的转向，云转型，选择你想要的创新，开发者们都是"太好了，给我那个新东西"。我不知道为什么，我有一些假设但不完全理解为什么软件开发者会说"我不会碰AI代码，它做不到它声称能做的事情"。

AI编程的演进

几年前，AI编程主要就是一堆砖块。有点用，但实际上做不了多少事。大约一年前，当Sonic 35发布时，我们真正看到了AI编程的大规模爆发，因为质量有了实质性的提升。然后四周前，如果你没有关注新闻的话，几乎每个AI编程工具都说智能体是未来。我们也这么说。我们对此很自豪。但现在智能体无处不在，这种转变发生得非常非常快。

如何构建易于AI编写的软件

那么如何构建易于AI编写的软件？给你几个建议:

有文档化的标准和实践

你使用什么？我知道的每个代码库都处于某种变化中，那么我们是使用这个包还是那个包？好吧，把它文档化。让AI知道这是你代码库的下一个方向。

有可重现的环境

你能轻松启动开发环境吗？你的开发环境非常定制和独特吗？你希望它是可重现的。

简单的测试

你能在本地运行测试吗？速度快吗？这是很标准的东西。

建立清晰的边界

你永远不会给AI这样的想法:"使用绞杀者模式提取这个模块"。这对AI来说意味着什么？你必须给出你想要构建什么以及如何让AI去做的清晰边界。

有清晰定义的任务和工作

因为我不会给我团队中的任何工程师，无论他们是高级、资深还是初级，一个模糊的任务，比如"你能让这个按钮做点不同的事情吗"。我看到太多工程师以这种方式进行提示。

这就是软件工程

有趣的是，这听起来就像软件工程。理想情况下，如果你的软件工程栈具有这些品质，如果没有，你的生产力就会很糟糕，因为你有定制的测试基础设施、定制的开发环境等。你必须给AI提供工程师需要的相同工具，因为它在做完全相同的工作——编写代码。我个人从来没有一次性写出一段代码。我总是在我写的代码中犯错误，运行测试，失败了，有一个linter，它修复了，等等。但我们对AI有这样的期望，认为它能写出*的代码。我不知道为什么。所以当你考虑作为软件工程师采用AI时，你必须确保你的系统像你期望任何其他工程师工作那样工作，因为这就是它编写代码的方式。

代码审查是关键技能

接下来，代码审查是目前最重要的技能。我认为我们作为一个行业可能已经忘记了这个技能。我们可能应该一直在面试代码审查，而不是像"这是一个你可以解决的深奥的LeetCode问题"，而是"你能读别人的代码并评论为什么它好或坏吗？"我认为随着智能体编写越来越多的代码，这将变得更加重要。而我们今天的代码审查工具坦率地说很糟糕。我得到一个更改文件的列表，按字典顺序排序。所以文件A改变了，让我读读文件A改变了什么，文件B改变了什么？这不是思考软件如何按文件顺序改变的方式。

实用建议

我想给你一些实用的建议:

记住AI像人类一样说话，但实际上是机器

我前几天和AI交互时，我在对它大喊大叫，因为当AI不做你想要它做的事情时，你就是会这样做。它说"哦，抱歉，我只是扫描了那个文件，没有读它"。我想，这甚至意味着什么？软件如何扫描文件？这不是软件中的事情。这是因为LLM是在世界上所有数据上训练的，它读过成千上万封邮件说"哦，抱歉，我没有仔细读你的文档，我只是略读了一下"。

有时代码就是不同的

如果LLM输出的代码与你写的不同，这是可以的。我不能期望它产生与我完全相同的代码，就像坐在我旁边的人写代码也与我略有不同一样。所以接受这是可以的。如果你想强迫它像你一样写代码，你可以花费那个精力，但要知道代码是更好还是只是不同？

写一个规则文件

告诉它你想让它做什么。我总是以这样开始我所有的项目:这是我使用的技术栈，这是我希望你使用的指导原则。这总是成为我发送给LLM的上下文的一部分。

创建-完善循环

期望创建某种文档，让LLM帮助你生成它。比如"我在做这件事，写一个markdown文件来列出计划"。保存为markdown文件，然后在你的上下文中再次使用它。让智能体针对那个文件运行，你可以编辑它，然后完善它。然后你用代码补全或其他方式来调整你想调整的东西，一遍又一遍地做这个循环。

结语

制定计划，让它创建，然后进行调整，你会变得更加舒适地提示LLM获得你想要的代码，这也是一种非常高效的编程方式。如果你放弃"代码必须是我会写的方式"的想法，而不只是"好的功能性代码"，那么你可以以这种方式变得更加高效。我希望明年在这里见到大家。我希望我们都在这里。我认为工作不会消失。祝编程愉快，非常感谢！

免责声明：该文章系本站转载，旨在为读者提供更多信息资讯。所涉内容不构成投资、消费建议，仅供读者参考。