软件工程的核心并非编写代码，而是管理复杂性。AI擅长将想法转化为可执行指令，但真正的工程挑战在于决定哪些指令应该存在、它们如何交互、权衡成本与约束，以及系统如何在不崩溃的前提下持续演进。

软件工程的核心：管理复杂性，而非编写代码

人工智能的普及暴露了一个普遍误解：人们常将“写代码”与“构建软件”混为一谈。两者虽有重叠，但本质不同。写代码是将想法转化为计算机指令，而构建软件则涉及决定哪些指令应该存在、它们如何交互、哪些约束重要、决策成本如何、哪些权衡可接受，以及系统如何在自身限制下持续演进而不崩溃。

核心论点：真正的难点从来不是敲代码

以一个普通需求为例：“处理传入事件并更新数据”。技术讨论中会涌现一系列问题：同步还是异步处理？是否需要队列？需要精确一次处理还是至少一次即可？系统能否容忍最终一致性？处理失败怎么办？重试几次？消费者宕机三小时如何处理？事件顺序是否重要？当前和两年后的流量预期是多少？事件被重复处理会有什么后果？

这些问题与语法无关。编程语言的选择会影响团队流畅度、性能、可维护性等，但无法回答根本问题。真正的难点在于选择代表正确妥协方案的架构，而通常不存在普遍正确的答案。

同一问题可能有N种完全不同的正确解决方案

以两家公司构建相同功能为例：公司A有500用户、3名工程师；公司B有2000万用户、200名工程师。一家需要强一致性，另一家可接受最终一致性以换取可用性和吞吐量。一家需三周内交付，另一家期望系统运行十五年。一家已有Kafka、Kubernetes等基础设施，另一家仅有一个应用服务器和PostgreSQL数据库。

对一家公司而言技术上令人印象深刻的解决方案，对另一家可能是不负责任的。因此，架构问题不能简化为“实现X的最佳方式是什么”，而应是“在给定约束、团队、业务、基础设施、预算、风险及产品预期演进下，今天实现X最合适的方式是什么”。

AI生成解决方案，工程师拥有权衡

AI在软件开发中极为有用：生成样板代码、探索API、提出实现方案、发现潜在bug、解释陌生代码、生成测试等。但存在危险倾向：将工程判断本身委托给AI。你可以让AI设计系统、选择数据库、决定是否引入队列或微服务，但答案的存在并不意味着工程问题已解决。

正确决策依赖于大量上下文：文档中的、客户对话中的、产品历史中的、团队技能中的、三年前运营事故中的、预算和截止日期中的、合同义务中的、遗留系统奇怪行为中的，以及知道客户六个月后可能请求特定功能中的。有时仅存在于经验中：认识到理论上优雅的架构对维护团队而言将成为运营噩梦。这些无法通过向AI提示添加段落来捕捉。

没有无权衡的架构

工程很大程度上是决定你愿意承受哪些问题的学科。即使不在FAANG规模工作，项目也可能需要处理足够数据，使正确工程决策对维持性能至关重要。每个“简单”选择都伴随需考虑的因素：激进规范化数据库可能增加完整性但使查询复杂化；反规范化可能提高读取性能但增加同步复杂性；添加缓存降低延迟但引入失效问题；引入异步处理解耦组件但创造新故障模式；拆分微服务获得独立部署边界但引入分布式系统复杂性；激进优化可能提高性能但牺牲可读性；激进抽象可能减少重复但使系统更难理解；避免抽象则会出现相反问题。

这些都无法独立评估。每次优化都在某处消耗复杂性。工程师的工作不仅是让系统工作，而是决定复杂性应归属何处。

算法思维更重要，而非更不重要

在AI时代，算法思维变得更重要。这不是指记忆教科书算法，而是定义一套日常遵循的基本原则：分解问题、识别不变量、理解数据流、选择合适数据结构、推理时间和空间复杂度、识别争用、理解故障模式、识别哪些操作昂贵且真正重要、分离本质复杂性与偶然复杂性、理解假设不再成立时会发生什么。

AI可以在以前写一个实现的时间内生成十个实现。挑战在于将AI作为工具，通过有针对性的、受控的迭代应用这些原则，同时保持人在循环中。这使得选择正确实现的重要性提高了十倍。

编程语言是工具，不是身份认同

选择合适工具很重要，但工程讨论有时过度高估编程语言选择。在许多业务系统中，在两种合理语言间选择的影响远小于选择错误架构、数据模型或运营策略。选择团队深入理解的语言具有显著价值。不要基于LLM在某种语言上表现更好的假设做决策。始终将团队放在首位。

五个关键因素：流畅度、生态系统成熟度、可维护性、调试、部署。因此，我鼓励工程师不要对单一语言有宗教般忠诚，而应尽可能成为多语言者，将AI助手作为学习工具而非仅代码生成器，并始终双重检查官方文档。

真正的优化目标是系统的生命周期

另一个错误是仅针对当前需求优化软件。现代软件必须能应对用户、客户、流量、商业模式、法规、团队、基础设施的变化。今天看似不重要的功能可能两年后成为核心工作流。良好工程需要预见变化的能力，同时避免为可能永远不会到来的假设未来设计复杂抽象。这种平衡很难：需求变化的可能性有多大？应在何处有意引入灵活性？何处保持简单？哪些技术债务可接受？哪些可能变得结构性昂贵？现在应优化什么？应有意不优化什么直到测量证明其重要？

这是工程判断。没有AI能正确回答这些问题，也没有提示能让这些问题消失。

AI生成代码创造了新的所有权问题

AI使生成代码极其廉价，但生成代码和维护代码是两种不同的经济活动。工程师现在可以极快生成数百或数千行看似合理的代码。团队合并它们，测试通过，功能工作，生产力看似提高，但可能失去了关键东西：团队是否真正理解整体架构？理解数据结构？理解特定抽象存在的原因？理解故障行为？理解生成实现依赖的假设？六个月后能否自信地修改它而不需要另一个AI解释之前AI生成的代码？

如果答案是否定的，团队没有消除复杂性，很可能引入了其他复杂性，这些复杂性随时间推移变得越来越重要。

代码行数廉价，理解昂贵

历史上，生成代码相对昂贵，现在变得极其廉价，而理解系统正变得越来越昂贵。一个包含3000行AI生成代码的拉取请求仍然是系统认知表面积上3000行的增加。通过的测试套件不是答案，因为它给你虚假的信心，认为一切都在掌控之中，因为系统表面上按预期工作。

如果你交付它，你就拥有它

因此，强有力的技术管理应坚持一个简单原则：永远不要交付你不拥有的代码。这里的“拥有”意味着对代码库有完全理解，验证了每个部分。AI生成代码不应因为是用先进/昂贵/前沿的LLM模型快速生成而获得较低的审查标准。现在的挑战是确定是否（以及何时）值得投入时间审查如此大的拉取请求，还是通过更小的迭代缓慢前进，在受控的人机交互中开发小块应用逻辑。

软件工程可能实际上变得更难

AI使编程更容易，同时可能使软件工程更难。我们可以比以往更快地生成更多代码，但理解系统的能力没有以相同速度增长。这创造了新的瓶颈：这个组织实际上能理解和控制多少复杂性？我们使用的生产力指标已经失效：一个生成五倍代码的团队不一定有五倍生产力。早期LLM采用阶段看到的初始生产力提升，现在正以维护和演进中等复杂系统的成本为代价。从现在起，生产力不应通过生成多少软件来衡量，而应通过我们多有效地解决问题同时控制产生的复杂性来衡量。

AI应增加工程杠杆，而非取代工程判断

这都不是反对AI辅助开发。恰恰相反，AI可能是几十年来软件工程师获得的最强大的生产力工具。但我们应该利用这种杠杆花更多时间在工程上，而非更少。让AI编写重复的适配器、生成测试套件的第一个版本、解释陌生库、帮助调查错误、提出三种实现方案或重构机械代码，这些都是有用的。它是时间节省器、助推器、助手，三者结合。

代码从来不是产品

软件工程不是纯粹的学术学科。我们在这里服务用户，因此它是脚踏实地的实践，需要与比以往变化更快的现实世界保持联系。由你的团队决定AI生成代码如何、在何处以及何时融入开发流程。编程语言会演进，框架会消失，AI模型将变得极其强大，生成代码的成本将继续趋近于零。

但复杂性将永远存在。它属于那些能理解最多复杂性同时引入最少不必要复杂性的工程师。AI可以帮助我们达到那里，但它不能减轻我们对所交付内容的责任。

根据评论内容，总结如下主要观点及论据：

观点一：AI在软件工程中能力迅速提升，甚至可能超越人类 - 支持者认为AI不仅能写代码，还能管理复杂性和进行系统架构。评论1指出：“AI can also generate the architecture for you based on the requirements... it feels like it's better than most of my coworkers.” 评论11强调：“not only can AI write code. It can manage complexity... AI is about 60 to 70 percent as good as a human now. A year ago it was 20 percent. The gap is closing.” - 评论9认为AI是通用推理机器，能处理代码之外的事务：“It's a general reasoning machine, it surely can reason on many things beside the actual code.”

观点二：软件工程的核心是管理复杂性，而非单纯写代码 - 评论6简洁指出：“All modern engineering is about managing complexity.” 评论19进一步阐述：“Software complexity grows superlinearly... complexity management idea... verification is the central problem of software engineering.” - 评论2强调代码编写与工程不可分割：“The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer.”

观点三：AI可能加剧混乱，且存在风险 - 评论13指出AI是双刃剑：“AI writing code is a force multiplier... if you lack structure... that gets way worse.” 评论16描述管理层盲目推崇AI的危险：“leadership telling everyone to 'use moar AI' on everything... folks dropping into incident Slack chats saying... 'I asked Claude about this issue... here's the PR.'” - 评论4警告：“AI can of course do architecture... but oh boy will you have a bad time when your application breaks and neither you or AI can fix it.”

观点四：对AI取代人类工程师持怀疑或保留态度 - 评论2认为AI并非必需：“it's obviously not essential because we somehow managed to write code without it a few years ago. I would even say the code was better back then.” 评论3指出AI在复杂任务上仍有不足：“the actual hard and novel parts still aren't really done that well by AI (yet).” - 评论5质疑AI缺乏批判性思维：“do we really need this? I'm not sure I've ever seen an agent pushing back on a request.”

观点五：AI对工程师角色的影响存在争议 - 评论8认为AI能替代平庸工程师：“AI is more able to replace the average engineer more than this article admits.” 评论15则预测：“to manage the complexity you need far less swe.” - 评论17批评文章本身：“The article is AI generated and there's nothing new in it. Just a bait for boomers.”

其他观点 - 评论14提及OOP作为管理复杂性的历史案例：“OOP came about... it was a way to manage complexity and led to much better and grander software.” - 评论18简化软件工程本质：“Its about creating a programmatic tool or game that solves something or creates joy... The rest is just a way to make the above goal cheaper or easier.”