AI 时代的工程师需要具备什么能力?Augment Code 给出了他们的招聘标准

如果 agents 已经能写 99% 的代码,那该怎么招工程师 ?这就是今天讨论的话题,实际上大家普遍不觉得 AI 时代就不需要人了,AI 只是开始接管写代码这个事情,但是代码也只是软件工程的其中一环,就目前 AI 的发展趋势上,人还是需要的,只是人的角色在发生变化 。

这也是 Augment Code 公司的观点:当 Agent 已经能承担大量执行的工作后,工程师的核心竞争力,就需要从「把代码写出来」转向「决定该做什么、怎么做、如何保证结果可靠」,也就是 AI-native 工程师 ,不再纠结于前端后端,不在区分 Android 还是 iOS ,React 还是 Vue,Go 还是 Elixir ,更多关注的是:

产品理解能力、架构判断、协调沟通和 Agent 推进的能力。

对于这个变化,Augment Code 也归纳出一个对比:

  • 传统工程是写代码、实现方案、解决问题、强调个人产出
  • AI-native 工程里更多是定义意图、编排 agents、选择正确的方向、强调系统级结果

也就是 人的角色正在从 author 转向 architect 和 editor 。

而这次最有意思的是,Augment Code 给出了他们招聘 AI-native 工程师的几个核心评价标准。

Product & Outcome Taste

首先是,你是不是在做正确的东西?,他们认为,代码生产后面越来越便宜,最贵的错误反而是"方向错了",所以工程师要更会理解用户问题、消解模糊需求、可以做到在实现之前先定义结果。

这相当于把优秀工程师的上限,从「执行得漂亮」改成「问题选得对」。

System & Architectural Judgment

其次就是这个东西能不能活过生产环境?

Augment Code 觉得,agent 很擅长写出「能跑的代码」,但不擅长判断项目长期是否健康、架构是否能承受规模、运维风险会不会在后面爆掉等。

这个也是未来 AI-native 工程师的核心能力,因为很多线上系统的问题,从来不是「写不出来」,而是有许多边缘情况需要标注出来,例如:

  • 隐性耦合
  • 性能退化
  • 迁移风险
  • 可观测性不足
  • 局部正确但全局失配

而 agent 经常会产出 "locally correct code that's globally incoherent" ,也就是局部看起来是可以的,但是放到整体就不协调了。

Agent Leverage

这个范畴问的是你能不能把 AI 真正转化成工程吞吐?不是"会不会用 AI",而是:

  • 能不能把问题拆成 agent 能做的形式
  • agent 跑偏时能不能及时纠正
  • 产出后能不能高效验证

这个角色里,你像带一个「干活非常快、但有时会自信地犯错 」的下属,AI 场景下工程师之间的差距不是「谁会用 Claude / Codex / Cursor」,而是谁能让同样的模型、同样的工具,稳定地产生更高质量结果。

Communication & Collaboration

这也是很重要的一环,因为 AI 都接管执行了,那人的在物理世界的最大作用就是沟通,你能不能把意图说清楚,同时让不同角色快速形成共识?

因为实现速度快了,所以项目瓶颈会前移到问题定义、tradeoff 澄清、跨职能对齐等场景,Augment Code 觉得:最快的团队不是代码写得最快,而是最快达成清晰共识的团队。

Ownership & Leadership

然后就是责任,AI 不会背锅,而人才是背锅主体,所以这里的问题就是你是不是对结果负责,而不是只对任务负责 ?,过去优秀的工程师也不是只完成自己的代码,而是会主动处理未来可能存在的阻碍,例如:构建速度慢、流程模糊、系统间断裂等情况。

这本质上是在强调:agent 时代不缺「做任务的人」,缺的是「把整个链路打通的人」。

Learning Velocity & Experimental Mindset

最后就是你的进化速度能不能跟上工具变化速度?

Augment Code 认为,今天的工具三个月后可能就过时了,所以最重要的是高频实验、快速调整工作流、愿意放弃旧的工作方式。

当然,这会是一个很累的工作模式。

可以看到,所以维度里 Augment Code 都很少提到代码能力,至少写代码能力不是一个单独维度,因为它已经不是首要区分项,因为它认为,代码能力正在从"筛人主轴"退化成"基础设施能力"。

所以具体到场景上,Augment Code 在会在面试里问类似问题:

  • 候选人能不能快速澄清一个模糊问题
  • 能不能提前识别架构风险
  • 能不能有效引导并验证 AI 产出的工作

然后他们把候选人划成四类画像:

  • AI-Native Systems Engineer:偏基础设施、架构、系统稳定性
  • AI-Native Product Engineer:偏产品品味、用户理解、结果导向
  • AI-Native Applied AI Engineer:偏模型理解、agent 能力和工作流增强
  • AI-Native Early Professional:偏学习速度和 agent-first 的成长方式

从这个分类可以看出来,Augment Code 也不是追求找到一个"万能 AI 工程师",而是在找围绕 AI-native 组织重新分工。

最后总结来说,核心观点就是:写代码这个执行成本已经越来越轻了,什么框架什么语言都不是重点,重点是人的架构思想,产品理念和管理协调能力,遇到深度问题或者难点,有没有办法指定 Agent 走出困境,这是他们认为未来新时代的能力。

最近的字节武汉和得物相关的消息,也在表现出前后端融合的情况,所以也许未来的开发,真的就是 AI-native 。

当然,就目前看 Github 已经被很多 Vibe Coding 的 AI 项目充满,而这些项目普遍 README 写的很好,但是存在不少效果难评,这对于 AI 来说也是很大的污染。

所以这对于人来说,也是价值所在,你的决策能力就是你的价值体现。

链接

www.augmentcode.com/blog/how-we...

相关推荐
茶底世界之下1 分钟前
林间步道要不要加暗角?用 Awaking 把强度收在20%
前端·ios·图片资源
执子念的飞鱼1 分钟前
纯前端预览 275 种文件格式是怎么做到的
前端·vue.js·react.js
2601_965969063 分钟前
不会复杂公式,也能用AI整理表格和做基础数据分析吗?
人工智能
season_zhu5 分钟前
Skills For Real Engineers 系列之一:先配好项目,再让 ask-matt 帮我选技能
ios·openai·ai编程
七夜zippoe7 分钟前
Spring AI 是什么?Java 工程师的 AI 开发第一站
java·人工智能·spring·ai·开发
xier_ran7 分钟前
【infra之路】AI 编译器学习笔记(十四):为什么要 tiling,以及矩阵计算单元的“固定“
人工智能·笔记·学习
szxinmai主板定制专家8 分钟前
储能 EMS、微网控制器选型:RK3588、RK3576、RK3568+FPGA 怎么选?多网、多 CAN、EMC 设计权衡
人工智能·深度学习·机器学习·fpga开发·工业网关·rk3576·电力网关
2501_926978339 分钟前
人机通信协议--人和机器之间的交互想象
人工智能·经验分享·算法·ai写作
行者全栈架构师12 分钟前
【鸿蒙心迹】互动卡片全链路——把核心功能放到桌面(FormKit 实战)(HarmonyOS 7.x)
前端·算法·架构
java1234_小锋14 分钟前
【技术专题】HTML5 网页技术 - HTML5 表单基础以及增强
前端·html·html5