在人工智能辅助开发的时代，人们很容易相信我们正在进入一个人类在编程方面的努力将变得过时的黄金时代。
提示取代了代码，大型语言模型在几秒钟内生成了整个系统。然而，在这光鲜亮丽的外表之下，却隐藏着一个微妙而关键的问题：理解力的侵蚀 ——而理解力是真正软件工程赖以生存的深层且往往痛苦的学习和推理过程。
价值在于旅程
在软件工程中，最终成品——应用程序、服务或系统——固然重要，但如何 实现最终成品也同样重要，甚至更为重要 。
编写、调试和重构代码的过程，通常会在过程中丢弃部分解决方案，这不仅仅是机械的工作，而是一种认知训练。它教会我们如何将事物串联起来。正是通过这种努力，我们才能对自己的理解建立信心，并获得应对复杂性所需的思维模型。
就像学习数学一样
这与我们学习数学的方式类似。数学并非通过阅读或观察他人解题就能真正掌握。我们通过实践——自己解决问题、犯错、不断尝试——来精通数学。这才是知识真正属于 我们的原因。大多数学生无法被动地吸收数学知识，而是通过努力学习获得的。软件工程也不例外。
氛围编码的幻觉
我们现在正经历着一种所谓的“氛围编码”的转变 ——用自然语言描述我们想要的东西，然后让人工智能生成代码。虽然这在某些情况下可能很有效，但也极具诱惑力。
当我们不仅将打字工作，甚至思考工作都外包给人工智能时，我们就失去了代码的语境。我们跳过了挣扎的过程，也跳过了理解的过程。结果或许有效，但也可能像个黑匣子，脆弱不透明。这并非工程，而是希望。
虽然对于已经了解其中利弊的经验丰富的开发人员来说，这可能是一个有用的生产力工具，但对于仍在学习的人来说，它却存在风险。如果没有花费大量时间去思考逻辑、调试错误以及了解事物的运作方式和原理，新工程师可能看起来很高效，但在关键时刻却缺乏深度去适应、修复或设计好问题。
这与更换组件不同
有人认为，人工智能辅助开发与从汇编语言到高级语言的转变没有什么不同。但这种类比并不成立。
是的，高级语言确实加快了开发速度。但更重要的是，它们让代码 更容易被人类理解。这才是真正的创新。我们发明的最好的语言和工具不仅仅是向机器表达想法，而是 以有效的方式将这些想法相互交流。
这就是为什么“代码整洁”、命名约定、文档和架构清晰等原则至关重要。机器可以运行任何语法上有效的代码。但人类需要能够 推理、调试和改进的代码。我们编写软件不仅是为了执行，也是为了协作和维护，而这两者都需要理解。
精通无捷径
软件工程新手不应该被鼓励跳过最难的部分。相反，他们应该拥抱这些难点。他们应该练习从零开始构建想法，进行实验，编写代码，打破常规，并学习调试。阅读他人代码与编写自己的代码同样重要。这样，你才能培养对代码好坏、优雅与脆弱的感知能力。
人工智能绝对可以协助这个过程——解释不熟悉的概念、生成样板文件或总结文档。但它不应该被用来取代思考。精通并没有真正的捷径。今天看似快速的流程，明天可能会变成瓶颈，因为一旦出现问题而无人知晓原因。
责任与信任
接下来是更深层次的问题——责任 和 信任。当人工智能生成关键软件时，谁对结果负责？
想象一下，一枚价值五亿美元的火箭由人工智能生成的代码引导。或者一架商用飞机。或者一辆自动驾驶汽车。如果出了问题，如果一个漏洞导致了坠机，我们能怪罪人工智能吗？当然不能。责任仍然在于人类。但问题是：在不容许失败的系统中，我们能信任人工智能生成的代码吗？
即使我们说“必须审核”，也并非灵丹妙药。任何经验丰富的工程师都知道，审核一个包含数百个自动生成文件的拉取请求，比一开始编写代码 更耗时，而且通常耗费更多的脑力。如果我们用人工智能审核来简化这一流程，我们又回到了最初的起点：信任机器来验证机器。
对软件的信任不仅仅在于它能否运行，还在于我们是否足够了解它，能够承担起它的责任。如果没有人能坦诚地说“我知道它是怎么运作的”，那么我们构建的就是一种负担，而不是一个系统。
为什么公司仍然需要工程师
您可能听过首席执行官宣称“未来人工智能将编写我们的大部分软件。 ” 在某些组织中，由于 智能自动完成功能（又名 Copilot） ，这种情况已经发生。
但请仔细听听他们 没有 说些什么。他们并没有说人工智能将 取代 软件工程师。
这是因为他们深知一个基本道理：他们不能失去 软件和系统所依赖的知识、 责任和 信任 。每个人工智能生成的解决方案背后，仍然需要人类的智慧来确保其正确性、可维护性和完整性。为此，软件工程师的角色及其专业知识仍然不可或缺。
增强，而非退位
人工智能在未来的软件工程中将扮演重要角色——但它应该成为合作伙伴，而非代理。它应该扩展我们的推理能力，而不是取代它。
未来不应将工程师变成快速打字员。而应致力于实现更深入的设计思维、更快速的探索和更明智的决策。真正的工程不仅仅是编写可用的代码，而是构建我们理解、可演进且可信赖的 系统。
评论