谷歌工程师抛出5个残酷问题：未来两年，软件工程还剩下什么？

软件行业正站在一个颇为微妙的拐点上。AI 已经从自动补全代码，演进为能够自主执行开发任务的智能体。在这一变化之下，初级开发者和高级开发者正同时被推入各自不同、却同样棘手的困境之中。对初级开发者而言，最大的挑战不在于会不会写代码，而在于还没来得及成长，练级空间就被压缩了。企业不再愿意为学习成本买单，初级岗位要么减少，要么被要求一上来就能独立产出。而对高级开发者来说，处境同样不好过。AI 并没有让他们更轻松，而是让责任进一步集中。当团队规模缩小、初级人手减少，高级工程师往往既要做架构决策，又要兜底 AI 和自动化系统带来的各种隐性风险，代码质量、性能、安全、合规。写代码的比例在下降，但判断、评审和决策的压力却在上升，一旦系统出问题，责任仍然落在人身上。接下来会发生什么，充满了不确定性。Addy Osmani，来自谷歌的一名软件工程师，在一篇文章中提出了 5 个可能在 2026 年前重塑软件工程的关键问题，并为每个问题给出两种截然不同的走向。文章链接：https://addyosmani.com/blog/next-two-years/这五个问题都指向同一件事，软件工程正在从写代码的职业，转变为驾驭复杂系统与 AI 的职业。未来不是单一答案，而是多种路径并存，谁能适应变化，谁就能留下来。初级开发者之问结论很直接：随着 AI 开始自动化入门级任务，初级开发者的招聘可能会出现崩塌；也可能随着软件渗透到几乎所有行业而重新反弹。这两种未来都存在，但对应的生存策略完全不同。像传统路径，学会编程、拿到初级岗位、逐步成长为高级工程师正在动摇。一项覆盖 6200 万名劳动者的哈佛研究发现，当企业采用生成式 AI 后，在六个季度内，初级开发者的就业人数下降了大约 9%–10%，而高级开发者的就业几乎没有变化。过去三年，大型科技公司招聘的应届毕业生数量减少了 50%。正如一位工程师略带讽刺地说：既然一个 AI 编码智能体的成本更低，为什么还要花 9 万美元去雇一个初级工程师？这并不只是 AI 的问题。像利率上升等宏观因素，在 2022 年左右就已出现影响，那时 AI 工具还未大规模普及。但 AI 加速了这一趋势。如今，一名配备 AI 辅助的高级工程师，产出已经相当于过去一个小团队的工作量。相比裁员，许多公司更常见的做法是悄悄地不再招聘初级开发者。反过来的情景是：AI 在所有行业，而不仅仅是科技行业，释放出对开发者的巨大需求。医疗、农业、制造业、金融业都开始大规模嵌入软件和自动化。AI 不是取代开发者，而是成为一种放大器，把开发工作扩展到过去几乎不雇程序员的领域。初级岗位会更多出现，但形式不同：那些能快速为特定细分场景构建自动化和集成方案的 AI 原生开发者。美国劳工统计局预计，2024 年到 2034 年间，软件相关岗位将增长约 15%。如果企业选择用 AI 来扩大产出，而不是单纯压缩人力规模，它们仍然需要人类去把握 AI 创造的新机会。但悲观情景的一个长期风险常常被忽视：今天的初级开发者，就是 5 到 10 年后的高级工程师和技术领导者。如果完全切断人才培养管道，最终会造成领导力真空。行业老兵将这种现象称为缓慢衰退，一个停止培养接班人的生态系统。如何应对？对于初级开发者来说，要让自己具备 AI 使用能力并保持多面性。证明一名初级开发者 + AI 的组合，能够匹配一个小团队的产出。使用 AI 编码智能体（如 Cursor、Antigravity、Claude Code、Gemini CLI）来构建更大的功能模块，但要理解并能解释其中的每一行代码，至少是大部分代码。把重心放在 AI 不容易替代的能力上：沟通能力、问题拆解能力、领域知识。将相邻岗位（如 QA、开发者关系、数据分析）视为切入口。建立作品集，尤其是包含 AI API 集成的项目。考虑学徒制、实习、合同制工作或参与开源项目。不要成为又一个需要大量培训的应届生，而要成为一个能够立刻产生价值、并且学习速度很快的工程师。对于高级开发者来说，初级人员减少意味着更多基础性工作会落到自己身上。要用自动化来应对日常事务，但不要什么都自己做。搭建 CI/CD、代码规范检查工具以及 AI 辅助测试，以捕捉基础问题。通过开源项目或辅导其他部门的同事，进行非正式的指导。如果未来初级岗位需求回升，要准备好高效地进行入职引导，并以结合 AI 的方式进行任务分配。你的价值不在于自己写了多少代码，而在于放大整个团队的产出。技能之问核心结论：当 AI 编写了大部分代码之后，编程基本功要么会逐渐退化，要么会因为人类开发者转向监督与把关而变得比以往任何时候都更重要。接下来的几年，将决定我们究竟是用理解力换速度，还是在效率提升的同时守住理解。如今，已有 84% 的开发者在日常工作中经常使用 AI 辅助。对许多人来说，面对一个 Bug 或新功能时的第一反应，不再是从零开始写代码，而是先写一个提示词，把 AI 生成的代码片段拼接起来。入门级开发者正在跳过最难的那条路：他们可能从未亲手实现过一棵二叉搜索树，也从未独立排查过一次内存泄漏。技能结构正在发生迁移：从实现算法，转向知道如何向 AI 提出正确的问题，并验证它的输出。职业阶梯的第一步，不再要求展示纯粹的编码能力，而是能够熟练地提示 AI、校验结果。一些资深工程师担心，这会催生出一代无法独立高质量写代码的开发者，一种事实上的去技能化。而 AI 生成的代码往往会引入隐蔽的 Bug 和安全漏洞，经验不足的开发者很容易忽略这些问题。另一种对立的情景是：当 AI 处理掉 80% 的常规工作后，人类将专注于最困难的那 20%。架构设计、复杂集成、创造性设计、边界情况 —— 这些仍然是机器单独难以解决的问题。AI 的普及并不会让深度知识过时，反而会让人类专家的价值更加凸显。这正是高杠杆工程师：他们把 AI 当作放大器，但必须对系统有深入理解，才能真正驾驭它。如果每个人都能使用 AI 编码智能体，真正区分优秀开发者的，是能否判断 AI 何时是错误的，或次优的。一位资深工程师曾这样说过：最好的软件工程师，不是写代码最快的人，而是最清楚什么时候不该相信 AI 的人。编程工作的重心正在转移：更少时间用来敲模板代码，更多时间用来审查 AI 输出是否存在逻辑错误、安全缺陷，或与需求不匹配的问题。关键能力逐渐变成软件架构、系统设计、性能调优和安全分析。AI 可以很快生成一个 Web 应用，但只有经验丰富的工程师，才能确保它遵循了安全最佳实践，没有引入竞态条件。在 2025 年，开发者社区的讨论明显分裂。一些人坦言自己几乎不再手写代码，认为面试和考核方式也应该随之演进；另一些人则认为，跳过基础训练会导致在 AI 输出失效时陷入更频繁、更痛苦的救火。整个行业开始期待工程师同时具备两种能力：AI 带来的速度，以及支撑质量的基础智慧。如何应对：对于初级开发者来说，要把 AI 当作学习工具，而不是拐杖。当 AI 编码智能体（如 Cursor、Antigravity、Claude Code、Gemini CLI）给出代码时，主动复盘它为什么能工作、哪里可能存在问题。偶尔关闭 AI 辅助，亲手实现关键算法。优先夯实计算机科学基础：数据结构、算法、复杂度分析、内存管理。一个项目可以做两遍，一遍借助 AI，一遍不借助 AI，对比差异。学习提示词工程和工具使用技巧。同时训练严谨的测试习惯：编写单元测试，在不立刻求助 AI 的情况下阅读堆栈信息，熟练使用调试器。深化 AI 难以复制的互补能力：系统设计、用户体验直觉、并发问题的推理能力。向外界证明，你既能借助 AI 高效产出，也能在它失效时解决棘手问题。对于高级开发者来说，要将自己定位为质量与复杂性的守门人。持续打磨核心专长：架构、安全、可扩展性以及领域知识。练习在系统中引入 AI 组件时的整体建模，并提前思考失败模式。持续关注 AI 生成代码中暴露出的新型漏洞。主动承担导师和评审者的角色，明确哪些场景可以使用 AI，哪些场景必须人工审查（例如支付或安全相关代码）。把精力更多放在创造性和战略性工作上，让初级开发者 + AI 的组合去处理常规的 API 对接，而你来决定应该构建哪些 API。投资软技能和跨领域知识，持续跟进新工具和最佳实践。最终，进一步强化那些让人类开发者不可替代的能力：稳健的判断力、系统级思考，以及培养他人的能力。角色之问核心结论：开发者这一角色，可能会收缩为一种有限的审计岗位（主要负责监督 AI 生成的代码），也可能扩展为一个关键性的编排者角色，负责设计和治理由 AI 驱动的系统。无论走向哪一种未来，创造价值都不再只是写代码本身。这里的两种极端非常鲜明。在其中一种设想中，开发者的创造性职责被明显削弱。他们不再真正构建软件，而是主要负责审计和看护 AI 的输出。AI 系统承担实际生产；人类开发者检查自动生成的代码，查找错误、偏见或安全问题，并批准部署。创造者变成了检查者，写代码的乐趣被风险管理的焦虑所取代。已经有报道称，一些工程师花在评估 AI 生成的 pull request 和管理自动化流水线上的时间越来越多，而从零开始写代码的时间却越来越少。编程逐渐不像是一种创造性的问题求解，更像是一种合规性工作。一位工程师曾无奈地感叹：我不想最后变成一个代码清洁工，只是收拾 AI 扔过来的烂摊子。另一种未来则要有意思得多：开发者进化为高层次的编排者，融合技术、战略与伦理责任。随着 AI 工人的出现，人类开发者承担起类似架构师或总承包商的角色，负责设计整体系统，决定哪些任务交给哪一个 AI 或软件组件，并将众多运转中的部件编织成一个完整方案。一位低代码平台的 CEO 曾这样描述这一愿景：在 Agentic 的开发环境中，工程师会成为作曲家，指挥由多个 AI 智能体和软件服务组成的合奏。他们不会亲自写下每一个音符，但会定义旋律 —— 系统架构、接口，以及各个智能体如何交互。这个角色本身具有跨学科和创造性：既是软件工程师，又是系统架构师，同时还是产品战略制定者。更乐观的看法是：当 AI 接管重复性劳动后，开发者的角色将被迫转向更高价值的活动。工作本身反而可能变得更有意思。总得有人决定 AI 应该构建什么，验证产品是否合理，并不断对其进行改进。最终走向哪一条路，很大程度上取决于组织如何选择整合 AI。把 AI 视为劳动力替代品的公司，可能会缩减开发团队规模，让留下来的工程师负责维持自动化系统运转；而把 AI 当作团队放大器的公司，则可能保持相近的人员规模，但让每位工程师承担更宏大的项目。如何应对：对于初级开发者来说，要主动寻找不只是写代码的机会。可以自愿参与测试用例编写、CI 流水线搭建或应用监控等工作，这些能力都与审计者 / 看护者角色高度契合。同时，通过个人项目保持对创造性编码的热情，避免失去构建的乐趣。培养系统思维：学习各个组件如何通信，理解什么样的 API 才算设计良好。多阅读工程博客和系统设计案例。熟悉代码生成之外的 AI 与自动化工具，例如编排框架和 AI API。提升书面和口头沟通能力，写文档时假设读者是另一个人。向资深同事请教时，不只问我的代码能不能跑，而要问我是不是考虑到了该考虑的事情。为自己做好准备，成为验证者、设计者和沟通者，而不仅仅是写代码的人。对于高级开发者来说，要主动拥抱领导力和架构层面的责任。塑造 AI 和初级成员遵循的标准与框架，制定代码质量清单和负责任使用 AI 的规范。持续关注 AI 生成软件在合规与安全方面的新问题。把重心放在系统设计和集成能力上，主动梳理跨服务的数据流并识别潜在失效点。熟练使用各种编排平台，如 Kubernetes、Airflow、无服务器框架以及智能体编排工具。进一步强化技术导师的角色：更多代码评审、设计讨论和技术规范输出。打磨快速评估他人（或 AI）代码并给出高层次反馈的能力。同时培养产品和业务意识，理解为什么要做某个功能，以及用户真正关心什么。可以旁听产品经理的工作，或参与用户反馈会议。通过原型开发、黑客松或前沿技术研究，保护并延续自己的创造热情。从写代码的人，进化为指挥全局的指挥家。专才还是通才之问核心