Linux之父 Torvalds直指编程的核心价值：无论工具如何进化，最终仍需通过代码实现逻辑。Linus在2000年以此终结架构争论，即强调代码是技术落地的唯一标准。用什么工具也好、人也好，编的东西是骡子是马，拿出来溜溜。

长期以来，“编程终结论”的论调便不绝于耳，这已然成为一个老生常谈的话题。回溯至20世纪90年代中期，彼时人们认为计算机辅助软件工程（CASE）工具会终结编程，随后第四代编程语言（4GL）也被寄予了这样的期望。

之后，“低代码”工具兴起，人们畅想所谓的“公民开发者”能够无需专业工程师参与，自主构建应用程序。

而如今，生成式人工智能与大型语言模型（LLM）的出现，又为这一缺乏新意的陈旧观点添了把柴，使其再度甚嚣尘上。 

总体而言，生成式人工智能将构建起一种全新的抽象模式，极大地简化应用程序的开发流程。

从早期的汇编代码，到更为现代化的编程语言和开发工具，软件开发经历了漫长且持续的进化历程。

在这一发展过程中，一个显著的特征是更为强大且高效的开发环境不断涌现，同时稳健的工程实践也得以广泛应用，这些都显著提升了开发效率。

如今，我们正站在新一代人工智能工具的起点上，这些工具将重塑软件工程师的角色定位。

甚至有人断言，软件工程师这一职业将不再必要。

毕竟，人工智能具备横向扩展的能力，无需休息休假，在培训速度上也远超人类工程师。而且，该领域的工具正朝着愈发复杂的方向发展，最终有望形成由人工智能驱动的“代理”团队，它们能够根据人类给出的提示自动生成代码。

人类工程师准备缴枪了吗？->

不可否认的是，当前一些新兴的人工智能工具确实展现出了强大的功能，令人眼前一亮。以Github副驾驶为例，它就像是被注入了强大动力的堆栈溢出，功能更为强大。

你可以根据自身需求对聊天机器人进行定制，无需再耗费精力去查找如何构建特定功能的资料。

这看似是一个渐进式的变化，从集成管道到单元测试套件，各类可用的样板文件都能轻松生成。然而，我们必须明确认识到，开发生产力工具与完全取代软件工程师这两个概念之间存在着本质的区别。

"Any fool can write code that computers understand. Good programmers write code humans can understand."（包括机器在内也可以写出让机器可以读懂的代码，但优秀程序员写的代码必为人所理解）From Martin Fowler（《重构》作者）

即使AI已经具备能力生成代码，可读性与维护性仍依赖人类工程师的智慧。

生成式AI到底是否擅长编码？->

在生成式AI展现出强大功能后，人们很容易陷入集体困惑，从人类智力的角度如何去解读它们的能力？

大型语言模型（LLM）在编写样板文件方面表现出色，这是因为它们经过了海量代码示例的训练，这些代码示例涵盖了数百万行的实际实现工作。然而，当你尝试借助LLM构建一个完整的系统时，就会遭遇这些模型固有的自然限制。

生成式AI的使用难题->

生成式人工智能在实际应用中面临诸多挑战。它们具有非确定性和不可预测性，会出现“遗忘”现象，给出不一致的反馈，偶尔还会产生“幻觉”，并且容易被误导。尽管它们的能力在不断提升，但认为它们已经踏上了无需人类干预就能构建系统的“康庄大道”，这种观点可能是错误的。 

"Premature optimization is the root of all evil."（过早优化是万恶之源）From Donald Knuth（《计算机程序设计艺术》作者）

Knuth在1974年就警告：技术演进中工具与方法要保持平衡。生成式AI虽简化开发，但滥用可能导致架构失衡，需遵循工程实践的本质规律。

软件工程“AI巅峰”或已过去->

事实上，我们甚至可能已经度过了软件工程的“AI巅峰”。

近期的一项研究发现，GPT - 3和GPT - 4在问题解决能力方面出现了显著下降。

这体现在生成代码的准确性上，能够无需修改直接准确执行的代码数量减少了。

此外，最近的研究还指出，Github Copilot对代码质量产生了不利影响，主要原因是它导致了代码变动和复制粘贴行为的增加。 

人类编码不可或缺->

如果人类停止编码，人工智能生成的代码可能会陷入不可持续的困境。

缺乏可用的培训数据是生成式人工智能面临的一个已知问题。向模型提供合成数据会导致“模型折叠”现象，即模型的性能会随着连续迭代而下降。模型自噬障碍就如同生成式人工智能的一种“繁殖缺陷”，模型在接受自身生成内容的训练后会出现“自我吞噬”的情况。如果像栈溢出这样的编程交流社区变得冷冷清清，我们又该如何培养下一代编码“代理人”呢？ 

"The only way to learn a new programming language is by writing programs in it."（学习新语言的唯一方法是编写程序）From Dennis Ritchie（C语言之父）

即使AI辅助生成代码，程序员仍需通过实践理解技术本质。

并且AI的经验来自于人类，而人类的经验积累不可替代。如果真的有一天AI已经反转到可以自己完美的准确创新式编程，那么整个人类将告别历史舞台，而不仅仅是程序开发这一个领域。

AI难以产出优质软件->

生成式人工智能工具在某些简单场景下往往能给出不错的表现，这使得对它们的能力进行客观、清醒的评估变得更加困难。

简单的用例通常能被它们正确处理，从而赢得人们的赞誉。然而，一旦引入现实世界的复杂性和对细致入微解释的需求，它们的表现很快就会大打折扣，不再那么令人印象深刻。

"Programming is like sex. One mistake and you have to support it for the rest of your life."（编程如性，一错毁终身）From Michael Sinz（微软首席架构师）

生成式AI可能引入隐蔽错误，在没有十足把握规避其编程风险的前提下，在企业内使用大规模AI编程替代人工并应用将面临承担巨大风险。

关于生成式AI作为“低代码”工具及编程革命的思考->

有人认为，提示工程（Prompt Engineering）能够成为一种“低代码”工具，进而赋予新一代“公民开发者”开发能力，但这种想法可能忽视了构建系统的现实情况。 

“低代码”工具的确让构建基本应用程序变得简单易行，可在处理复杂问题时，它们往往会让问题变得更加棘手。生成式人工智能在这方面也不例外。

在实际应用中，人们很容易陷入过于复杂的提示设定里，花费大量精力后，发现还不如自己直接编写代码来得高效。

软件工程并非只是简单地对一堆书面指令进行解释。

它要求从业者具备广泛领域的知识，深入理解软件的使用方式，还要拥有强大的创造性问题解决能力。

准确解释意图、充分理解上下文在软件工程中至关重要。

生成式人工智能虽然能做出一些令人惊讶的成果，但它无法像人类工程师那样对环境有细致入微的感知和理解。 

伊森·莫利克曾言：“AI不是好软件，它是相当好的人。”这话请反复读三遍...就理解了AI与软件之间的区别。AI它也是个人，不过是能够编程的代理人...它同样会犯经验性错误，甚至马大哈。

也即，生成式人工智能系统的工作方式与可重复的标准化软件不同。

我们习惯了确定性系统每次都能以相同的方式运行，所以很容易对生成式人工智能产生误解。由于没有手册能帮助我们了解这些系统的工作原理，我们只能通过实际使用来摸索。 

这意味着，在你具备一定专业知识并能提供有效指导的领域，生成式人工智能往往能发挥更大的作用。从这个角度看，你可以把它们当作合作伙伴，将部分工作委派给它们。生成式人工智能是可以与我们合作的对象，但它不太可能完全取代人类，更不可能在没有专业指导的情况下，完美给出结果。

编程革命未来是否会来临呢？->

不用说未来，或许编程领域已经发生了一场革命，而且从过去到现在一直进行中。

毕竟，如今我们很少再谈论“计算机程序员”，而是更多地提及“软件工程师”，这一细微差别意义重大。这表明创造性解决问题和横向思维(比如业务架构）在软件工程中将发挥更重要的作用，而生成式人工智能在这些方面并不擅长。 

在过去，没有计算机科学学位的人也能从事软件开发工作。许多软件工程师在学生时代学习的是如何批判性地评估书面资料、形成一致的论点，而非编写代码。

这种多元化的思想为行业带来了积极影响。而使用生成式人工智能构建系统的想法，与软件工程中日益重视的敏捷协作、精准沟通和自我进化等理念背道而驰。软件工程不会回到原始的粗糙状态，相反是在朝更为精益的方向进化中，用户对软件的体验要求也越来越高。

不过，生成式人工智能在构建未来系统方面确实有着重要作用。它可能会催生一些新的抽象概念，加速软件工程中现有的发展趋势，帮助我们提高生产力，构建更可靠的系统。

对于没有软件工程背景的人来说，一些简单的用例可能会变得更容易理解。但我认为，这并不像“编程的终结”那样具有吸引力，也不应成为我们过度追捧的噱头。

从汇编到生成式AI，编程工具持续进化，但无论时代如何进步，技术抽象提升的是效率，而非取代人类对逻辑的掌控。

编程的本质是“解决问题的艺术”，这一内核在工具迭代中愈发凸显  。正如乔布斯的最后忠告：Stay hungry, stay foolish ，技术终将服务于人类创造力，而非反之。