我是 08 年毕业的，到现在，已经过去了超过 18 年。但是，我开始学软件的时间，要早得多，并且是从 VB 开始的，正儿八经接触的第一门编程语言是 C，毕业使用的是 Groovy on Grails 做的网站（可远不如现在的毕业生们使用的高大上技术了），在这篇文字里面有所介绍。如今在 AI 火遍全世界的年代，我会想起当时我是怎样学写软件的，更感慨的是，对于选择软件工程师作为职业的我来说，真的幸运地赶上了好时代。这个时代的激动人心，是前无古人的。
跳出琐碎的具体事件，如果我们站到非常高的视角，想想整个世界软件工程的演进，可以分成这么几个阶段：
首先是五六十年代的手工业时代，硬件是催化剂，随着硬件性能提升，极易崩溃的软件称为了瓶颈，这才有了把工程化从传统产业搬到软件上的第一个阶段。在这个阶段末，北约会议中提出了 “软件工程” 的概念。
接着是结构化编程时代，相当于是七八十年代，标志性的事件是 C 语言和 Unix OS 的诞生，Dijkstra（就是那个最短路径算法的作者）提出了 goto 语句的害处。从此大家都认可软件应该自顶向下、模块化编写。这段时间很多的观点也是我大学里面逐步接触到的。
接着九十年代到 2010 年代中期，互联网行业爆发，软件工程飞速发展，跨平台的 Java 语言诞生，敏捷的概念开始兴起。这段时间最浓墨重彩的两个词是 OO（面向对象）和 Web，我觉得从我的技术背景和积累来看，主要的知识内容就是那个年代产生的。
第四个阶段就是 2010 代中到 2020 年代初，大致可以归纳为云计算和云原生时代。这也算是记忆犹新，不过我自身的这方面的技术更新并不快。其中标志性的事件，我认为就是 Docker 和 Kubernetes 的开源。职业路线上，慢慢专注于 platform 和 infra 以后，我已经较少开发纯 web 的项目或者软件了，技术方面涉及云原生的可以说越来越频繁。
第五个阶段，处于刚兴起的一个大阶段，就是AI 驱动的时代，这可以说是说算是从 2022 年的 ChatGPT 爆发开始算起，依然非常早期。华尔街和资本把它炒的火热的程度，兴许可以说仅次于当年的互联网泡沫。自然语言开始成为编程语言，开发效率爆发，编程语言的 “语言” 特性本身，逐渐变得廉价，代码生成成本越来越低。
如果把这几个阶段的技术摆出来，再从一个随着时间演进的高屋建瓴的角度看，还能发现一些变化的规律：
第一个是抽象层级越来越高。
比如一开始是硬件机器语言、汇编语言；然后结构化编程阶段的 C 和 Unix，屏蔽了许多硬件指令的复杂性；接着就是互联网阶段的 JVM，做到一次编写，到处运行这样跨平台；而云平台的 Kubenetes+Docker 则是让运行环境和资源一并打包；到了 AI 则是让人类语言翻译成传统编程语言这一步都省了，基本上的最高的抽象层级了，也是最接近人类思维模式的形式。
第二个是软件复杂程度的爆炸。
从最早的直接接触硬件的操作，到逐步引入高级编程语言、面向对象等等对抗软件复杂度，再到治理方面使用 Kubernetes 等编排技术整合各种各样的微服务，最后是 AI 时代使用大模型来接管人类大脑对于软件整体体系的认知。
在 AI 的这个阶段，软件工程师的价值在哪里，这个行业的未来会怎样，和很多这行的人一样，我也在反复思考这个问题，比如这篇。
关于这个问题，如果尝试站得高一点，拨开那些具体技术和实践的迷雾，只是从软件工程和软件工程师的本质去思考问题，那么软件工程这一个行业，很很多工程行业一样，其实并没有什么特别的——技能会被替代，行业反而会持续进步。每一类具备普遍性的问题，每一种能够得到大规模使用的技术，都会关联到一种职业。所以，如果思考软件工程师这个职业是否会被淘汰掉，不如思考软件工程这个技术领域是否会被淘汰掉？进而再思考，软件领域所解决的问题是否会被淘汰掉？
显然，是否定的。
我来尝试解释一下。来想想看，软件工程诞生的动机是什么？一个词来概括，就是复杂性。人类的需求是社会进步的动力，这是无止境的。而正是因为需求不断进展，软件不可避免地变得越来越复杂，人类就迫切需要一个可以重复和实践的办法，来保证软件交付的时间和质量，这才有了软件工程。
再来思考未来，未来的软件是怎样的暂且不论，可以确定的是，未来需要软件解决的问题依然在变得更为复杂，那么未来软件的本身也自然需要更为复杂，于是，为了保质保量交付，为了社会化大规模实践和推广最佳的方法，软件工程就需要持续存在，并且也将更为复杂，专业门槛只会更高。这就是最本质的软件工程和软件工程师不被淘汰的逻辑。只不过，那时的技术未必是现在的技术，那时对于工程师的要求未必是现在对于工程师的要求。这一点结论，其实和 AI 本身没有关系，也可以是其他技术手段，只不过 AI 恰好成为了这个时代扣动扳机的那个角色。
再把视角缩回到 AI。我们时常听到 AI 替代论和 AI 自我进化论。在某些领域，AI 确实会不断替代当前软件工程师在软件工程中所扮演的许多角色，很多技术问题也能够通过 AI 完成解决，而 “人” 只需要很低程度的参与；不过，也有很多领域，广泛存在确定的逻辑壁垒，让 AI 自我迭代和强化变得非常困难。具体说，AI 自己来生成代码，并且使用它来进行训练，不断强化，它就会缺乏人类真实的应用场景，本质上也无法产生针对真实的改进和创新。这种模式，一定程度上可以视作封闭系统的自我更新，极易放大微小的误差，最终结果天差地别，形成不可思议的谬误。
把时间维度放到未来几年到十几年来看，我觉得 AI 还是更适合作为一个辅助者的身份，软件工程师来做抽象，做统筹，做高屋建瓴的规划性工作，让 AI 成为一个辅助者、好帮手，帮助完善内容，作为智囊团提供建议和实施者搞定经过人类审核分派的具体任务。社会依然需要软件工程师这样的角色，甚至需要更多，只不过他们的技能树可能会发生大幅变化。软件工程师对于问题的简化能力、抽象能力、规划能力，将得到前所未有的重视。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
我大学学习软件工程专业。说实话这并不与其他计算机、软件相关专业有什么区别，赖以谋生的手段是一样的（例如 J2EE），且与软件工程本身关系不大。
在我的浅薄理解下，所谓的软件工程是一种” 可以让一大群的非天才程序员，能够组团完成仅由一两个天才程序员就能完成的宏大工作” 的管理科学。
而软件工程专业的课程，只是在教会大家一些早在几十年前就被提出的方法论，然后被大家在工作中 “有形无实地实施”、“偏激地加码”、“甚至彻底违背”。
（好在在我身处的公司，一起编码的伙伴即使算不上天才，也都是平均以上水准。即使靠着变形的 “工程”，大部分情况也出不了太大的问题。）
———-
氛围编程的到来，让软件工程重新变回了混沌但焕发生命力的时代。没人知道怎么做是对的，但未来一定会诞生新的最佳实践。
尤其是模型、agent 本身的变化也很快，还没有趋于稳定。
在软件开发流程里，一些软件工程的核心内容没有变化，例如软件的复杂度没有改变；需求、设计等环节依旧存在。
但是还有一些是变了的。例如，软件工程很多理论有默认的设计前提，即 “编码开发、修改的代价很大”。所以要把更多的东西、精力投入在前期的需求分析、设计上。
AI 时代，” 编码开发” 的代价被前所未有的降低了；代码检视、审查、测试等环节的压力被大幅放大；结构化的、完备的设计文档的价值提高。这些转变。可能会引导工程模式发生新的转变。
包括大家特别讨厌的” 定制软件” 需求，可能会变成新的主流，大幅促长整体软件市场的大小。
其他在技术选型决策上也会发生转变：
编程语言的选择方面，也会把 AI 训练语料丰富度、token 效率、编译测试等效率等方面纳入考量。
架构选型上，需要把上下文控制、测试效率等方面纳入考量。例如重新审视诸如微服务架构的拆分粒度问题。
工程师需要的抽象层级也提升了。团队不再需要” 码农”，而是需要更多偏向” 架构师”、” 全栈工程师”、” 团队 leader” 的角色，对工程师认知的深度、广度都提出了新的要求。
———-
我倾向于未来，AI 编程能力的进步会陷入某种瓶颈。
因为用于训练的数据，几乎全部由 AI 生成，会导致某种类似于” 过拟合” 的情况。
在全新的创新领域里，AI 能辅助生成建议，但依旧需要人类工程师的智慧参与，才能为 AI 的进步注入新的活力。
同时，这个时代对” 新手工程师” 是很不友好的。我很难想象新入行的工程师积累足够的” 直觉”，来察觉到 AI 决策的错误、阻止一场场灾难的画面。我见过很多新员工，只是充当” 线上系统日志” 到” 编码 agent 输入框” 之间的搬运工，他们成为了体系的瓶颈而非价值，也很难从这样的实践中积累经验。
所以我目前的感觉，是软件工程师这个职业，可能会断层，并出现越老越值钱的情况。