AI 不会取代程序员。但它已经取代了你被雇佣的工作。
Source: Dev.to – AI won’t replace programmers, but it already replaced the job you were hired for
请提供您希望翻译的完整文本内容，我将为您翻译成简体中文，并保留原始的格式、Markdown 语法以及技术术语。谢谢！
工作描述的谎言
职位发布的说法
使用 React 和 TypeScript 构建响应式网页应用。
实际工作内容
了解产品经理真正想要的（不仅仅是他们说的），与设计团队协商技术约束，对产品经理未预见的权衡做出判断，并处理规范中未提及的 47 个边缘情况。
编码一直是最容易的部分。AI 只是让这一点变得显而易见。
AI 能做的事（诚实一点）
我不会假装 AI 在编码方面不行——那是自欺，而自欺是付不起房租的。
在 2026 年，AI 可以：
- 编写一次就能正确运行的 CRUD 接口。
- 根据描述或截图生成 React 组件。
- 编写能够真正捕获错误的单元测试（前提是提示得当）。
- 在保持行为不变的前提下重构代码。
- 调试大多数常见错误模式。
- 搭建项目脚手架、CI/CD 和部署配置。
这大约覆盖了典型开发者一天工作量的 60 %–70 %。这并非微不足道，而是相当可观。
AI 不能做的事（短期内也不会）
1. 理解组织背景
产品经理说：“让结账更快。”
- 初级开发者： 构建一个更快的结账页面。
- 高级开发者： 询问，“用户是因为页面慢而流失，还是因为我们要求的信息太多？让我先查看分析数据再写代码。”
AI 会为你构建一个飞快的结账页面。它不会质疑结账页面是否是真正的问题。
2. 对糟糕想法说“不”
上周，一位产品经理让我添加一个功能，这需要在每次 API 调用时连接四个表。他们说：“这只是一字段。”
我说了不，并提出了替代方案：在后台任务中预先计算该数据并以非规范化方式存储。用户体验相同，数据库负载降低 100 倍。
AI 不会说不。AI 会构建你所要求的任何东西。它是团队中最顺从的工程师——而有时你需要的是会提出反对意见的人。
3. 做出不可逆的决定
我们应该为这个新服务使用 PostgreSQL 还是 MongoDB？两者都可行，但决定会影响未来五年的开发，并取决于：
- 我们团队了解什么？
- 我们的基础设施已经支持什么？
- 随着业务变化，数据模型将如何演进？
AI 可以列出利弊。但它无法在你的团队、业务和未来的上下文中权衡这些。权衡——判断——才是工作。
4. 在凌晨 3 点调试分布式系统
生产系统宕机。错误日志相互矛盾。三个服务相互指责。客户给 CEO 发邮件。
你需要这样的人：
- 提出假设，系统性地测试，并与团队沟通。
- 在信息不完整的压力下做决定。
- 明白“看似不可能”的错误通常是 DNS 缓存问题或时钟漂移问题。
AI 可以帮助完成单个调试步骤。但它无法指挥整个生产事故。暂时做不到，也在短期内不会实现。
5. 建立信任
工程是团队运动。你的产品经理需要相信，当你说**“这需要两周”**时，真的会花两周——不是因为你夸大了估计，而是因为你考虑了集成测试、边缘情况以及支付 API 文档错误的事实。
AI 可以估算任务复杂度，但它无法建立让产品经理信任估计的关系。
新的职业阶梯
旧的阶梯
| 级别 | 职责 |
|---|---|
| 初级 | 编写代码 |
| 中级 | 编写高质量代码 |
| 高级 | 编写代码并做架构决策 |
| 资深 | 做出影响整个组织的决策 |
新的阶梯
| 级别 | 职责 |
|---|---|
| 初级 | 使用 AI 实现解决方案，理解 AI 的代码，验证其正确运行，处理边缘情况 |
| 中级 | 将模糊的问题拆解为 AI 可解决的子任务，审查并改进 AI 输出，做出局部设计决策 |
| 高级 | 决定要构建什么（而不仅是如何构建），将业务需求转化为技术策略，对不好的想法说“不」 |
| 资深 | 塑造组织的技术方向，对技术进行押注，构建供其他工程师在其上构建的系统 |
注意： 在每个层级，工作内容都向上移动。前一级的工作被 AI 吸收，剩下的只有判断、沟通和决策。
如何应对（实用建议）
如果你是初级
你的竞争优势不在于写代码——现在 AI 已经可以做到这一点。你的优势在于：
- 理解要构建什么 – 参加产品会议。了解为什么做出决策，而不仅仅是要构建什么。
- 检验判断力 – 当 AI 编写代码时，不要只运行它。要阅读代码。问自己“可能会出什么问题？”在生产环境出现之前先发现 bug。
- 沟通 – 编写清晰的 PR，提出有价值的问题，解释你的决策。这现在占工作的大约 50%。
如果你是中级
你正处于压力区：已经足够资深，单纯“写代码”已经不够；但又还不够成熟，可能尚未培养出判断力。
- 练习决策 – 对每个任务，在请求 AI 之前先写下你的做法。然后与 AI 的建议进行比较。它们有什么不同？为什么？
- 了解业务 – 获得晋升的工程师懂得收入、客户痛点和市场动态。花时间与产品、销售和支持团队合作，看到更大的全局。
如果你是高级或资深（Staff）
- 掌握“要做什么” – 将高层业务目标转化为技术策略。
- 敢于拒绝 – 成为说“否”或“我们重新考虑”的把关人。
- 指导 AI 使用 – 教导组织在保持判断力的前提下，最大化利用 AI。
Bottom Line
AI 可以处理大量的 implementation 工作，但 human 方面——上下文、判断、谈判和信任——仍然是工程价值的核心。专注于培养这些技能，你将在 2026 年及以后保持不可或缺。
对模糊感到不适
在你的层级上，最有价值的技能是把模糊的“我们需要更好的分析”转化为具体的技术方案。
如果你是高级工程师
你可能还不错，但你的工作正在发生变化：
更多时间用于策略，少些时间用于实现
如果你仍然自己编写 60 %+ 的代码，可能并没有充分发挥你的本职工作。
成为乘数效应的推动者
你的价值不在于你写的代码，而在于你所做的决策，这些决策能让十位工程师免于构建错误的东西。
教授判断力，而非语法
当你指导新人时，不要教他们如何对链表排序，而是教他们如何判断一个功能是否值得去实现。
真正的威胁不是 AI
威胁不是 AI 替代程序员，而是 AI 提升了门槛。
当每个人都能用 AI 构建 CRUD 应用时，知道如何构建 CRUD 应用就不再有价值。有价值的则是：
- 知道该构建 哪种 CRUD 应用
- 让它 可靠
- 随着业务变化对其进行 演进
AI 不会取代程序员。
会使用 AI 的程序员会取代不使用的程序员。
能够 思考 的程序员会取代只能 编码 的程序员。
那不是预测，而是已经在发生。
同意吗？不同意吗？我想听听不同职业阶段的人的看法。AI 如何改变了 你的 日常工作？欢迎评论。