编辑 | 姜篇
吴恩达：“I actually don't miss coding by hand.”
吴恩达：说实话，我已经不怀念亲手写代码了。
吴恩达谈自己已经不怀念亲手写代码
在Supabase Select的对谈里，吴恩达说完这句话，又讲了一个很多开发者熟悉的反常识变化：Coding Agent让他能做更多事，想做却没时间做的项目也越来越多。他甚至觉得，自己做事的速度在变快，想做的事却增加得更快。
他没有说“人人都不用学编程了”。
吴恩达的团队看了上万份招聘信息，访谈了开发者，列出AI工程师需要的四类能力：做出并部署AI应用、理解软件工程、使用Coding Agent，以及参与决定产品究竟该怎样做。
其中有几处值得展开。他说，Agent的用法三个月就能变一轮，系统上线后的监控与工程取舍却没这么快过时；代码写得更容易以后，难题会前移到“做什么”；原型可以迅速做完扔掉，碰到真实客户和敏感数据就得换一种做法。访谈最后，他还提醒：让聊天机器人替人完成任务，未必能让人学会任务背后的东西。
这场对谈由Supabase联合创始人兼CEO保罗·科普尔斯通主持，下面按访谈的几个话题整理原意。
“不怀念写代码”，但项目清单更长了
主持人问吴恩达，还会不会怀念以前那种沉浸式写代码的感觉：卡在一个问题上，翻Stack Overflow，折腾几个小时后终于解开。
吴恩达：我其实并不怀念手写代码。现在有另一种进入状态的方式：睡前启动一个Coding Agent，让它工作，第二天早上看它做出了什么。我得承认，我似乎更喜欢现在这种感觉。
主持人紧接着说，AI本该让人更高效，自己的待办项目反而变多了。吴恩达也有同感。
吴恩达：我有太多想做却没时间做的项目。我们的能力在增长，但我个人的目标可能增长得更快。
他表达的意思是想做的事变多了。
Coding Agent让吴恩达能更快把想法做成原型。过去因为时间不够而搁置的项目，现在也有机会尝试。可项目越列越多，他还得决定：这些项目里，哪个值得先做？
上万份招聘信息，筛出了四种能力
主持人请吴恩达介绍团队正在做的AI工程技能图谱。吴恩达先澄清，“AI工程”并不只是一个岗位名称：前端、后端、移动开发和DevOps工程师，也会用到这些能力。
吴恩达：我们研究了超过一万份职位描述，做了数十次结构化访谈，也进行了调研。最后把做好AI工程所需的能力归为四类：构建和部署AI应用、软件工程基础、使用Coding Agent，以及参与决定要构建什么、怎样构建。
他特别指出，AI应用和传统应用有一处不同：调用模型后，开发者不能预先确定每次会拿到什么结果。服务能响应，只是第一道关；表现是否稳定，还需要监控、错误分析和持续评估。
吴恩达：做AI应用的人，需要知道怎样监控系统表现，怎样系统地分析错误，再用评估结果推动下一轮改进。
至于软件工程基础，吴恩达列举了事务和数据读写等知识。
Agent能替人写大量代码，理解这些概念的人，才更容易发现它是否选错了方案。第四类能力听上去像产品经理的工作，他后面专门解释：不是让所有工程师转岗，而是让工程师也能参与决定下一步做什么。
Agent读得到代码，但看不到客户的表情
主持人问：如果Agent越来越能干，人的哪些技能还值得培养？吴恩达并没有列一串“AI永远不会”的能力清单。
他说，有些事情会继续交给Agent，连今天需要人来管理的一部分Agent工作，未来也可能由Agent自己接手。
吴恩达：几年前大家热议“提示词工程师”，仿佛人得掌握一套神秘咒语才能指挥模型。但模型也会学会这些咒语。我认为更重要的问题是：在一项任务上，人是否掌握着Agent没有的背景信息？
他举了一个例子：你和客户谈需求时，说完某句话，注意到对方脸上出现一个微妙的表情；或者你还记得五年前读过的市场报告，知道用户其实更在意另一件事。这些线索不会写在代码仓库里。
吴恩达：我们在构建应用时，知道大量Agent不知道的事。人很擅长在需要做决定时，从这些分散的背景里找出有用的部分。
视频评论区有人提醒：复杂项目的历史取舍可能已经埋在多年代码里，任何一个人都说不全。
吴恩达讲的“上下文优势”因此不能只靠记忆维持；开发者也得把客户反馈、历史约束和决策原因，逐渐写成团队与Agent都能使用的材料。
Coding Agent的用法变得最快，工程基本功没那么快过时
主持人担心，工具迭代太快，AI工程课程是不是每个月都得重写。吴恩达承认，Coding Agent的用法确实变化迅速；但部署、监控、更新系统所需的许多知识，变化没有宣传声量那么快。
吴恩达：这份技能图谱里，变化最快的是Coding Agent。我们今天写代码的方式，和三个月前、六个月前都不一样。但怎样构建和部署AI应用、怎样监控和更新系统，其中不少基础知识变得慢得多。
吴恩达区分Coding Agent的快速变化与部署、监控等相对稳定的知识
吴恩达自己已经把不少数据分析工作交给Agent。他说，不必再亲手写那些Pandas处理代码，Agent却会作出奇怪的决定，甚至得出奇怪的结论。他把问题落到工程取舍上：成本与延迟、速度与可靠性，常常不能同时取到最好。
吴恩达：如果你不理解基础，往往连这里存在什么取舍都不知道。Coding Agent已经替你做出一串选择，你可能直到后来被结果反噬，才知道它作过这些选择。
所以，团队看一个Agent提交的改动，不能只问“跑通没有”。还要弄清它为了跑通放弃了什么。吴恩达谈工程基础，并不是要把开发者拉回手写每一行代码，而是希望有人能看见代码背后那些没写在成功提示里的代价。
吴恩达谈成本、延迟、速度、可靠性之间的取舍
写得越快，越需要有人决定做什么
主持人请吴恩达解释技能图谱里的“shaping the build”，也就是参与决定产品做什么、开发过程怎么推进。
吴恩达：构建一件东西变容易了，瓶颈就不那么在“做出来”，而在“决定做什么”。借助AI，前端工程师能做更多后端工作，后端工程师也能做一些前端。开发者的工作范围正在扩大。
扩大到哪里？吴恩达说，开发者如果做完功能，还得等产品经理层层转述客户反馈，再决定下一个版本，整个过程仍然很慢。能够直接和几位用户谈一谈、理解他们的反馈，再继续往前做的工程师，会更有效率。
吴恩达：这不意味着工程师都应该成为产品经理。但能作出一些产品决策、也能思考架构决策的工程师，比只负责实现一个狭窄任务的人能做得更多。
他把“参与构建”讲得很具体：现在是先做一个最小可用版本，还是该投入可长期运行的架构？应该继续写，还是先去找客户？后端技术选型没把握时，是不是先研究再动手？这些决定没有一个能靠“让Agent多写点代码”自动解决。
吴恩达谈开发瓶颈向“决定做什么”移动
先写长规格，还是让Agent直接开工？
主持人追问：既然工程师要参与这些决定，动手前究竟该花多少时间写设计？吴恩达没有给统一流程。他说，答案取决于项目所处的阶段，以及一个决定做错后能否撤回。
吴恩达：早期项目里，只要能负责任地控制风险，就把想法交给Coding Agent，做出一个粗糙原型，看看会发生什么。可以把它扔掉，再做一个，快速学到东西。但这不包括泄露敏感数据，或让试验造成坏的后果。
到了系统要长期运行的阶段，他会换一种节奏：认真考虑客户要求、数据读写、安全设施和架构。吴恩达认识擅长从零到一的工程师，也认识擅长成熟系统的工程师；两类工作对速度和下行风险的权衡不同。
吴恩达：有时该先规划、写很长的规格；有时你二十分钟后就要睡觉，完全可以先交给Agent跑几个小时，第二天早上看看结果。难的恰恰是学会按项目阶段切换做法。
这段回答不是劝人把生产系统随手交给Agent。吴恩达讲的是同一位开发者在项目早期和上线前，需要用不同的工作方式。
吴恩达区分快速试验与长期运行的系统
工作完成得快，不等于人学得快
访谈最后，主持人把话题转到学习：Agent能做越来越多的事，人以后怎么学？
吴恩达：我要说一句听起来有争议的话：聊天机器人很不适合拿来学习。我很喜欢用大模型，但在学校里，有学生用它做作业时表现更好，到了考试却表现更差。让模型替你思考，你可以完成更多事，学到的东西却可能更少。
他随即补充，这不是说AI不能辅助学习。可以设计更好的用法；只是“帮我完成任务”和“帮我掌握能力”不是同一个目标。他认为，工作中的成年人也可能低估了这种差别。
吴恩达：我喜欢我的Coding Agent，它帮我完成了很多工作，也减少了我需要亲自思考的部分。我们应该做得更好，让学习工具真正服务人的成长，而不只是更快交出结果。
对正在用Agent的工程师，这个区别不难体会：一个问题它替你修好了，下次再碰到类似故障，你能不能说明原因？这不是要求每次都手写一遍修复，而是别把“合并了PR”误当成“已经理解了系统”。
吴恩达谈完成任务与学会一件事的区别
开发者哭诉：越能做，越做不完
一位开发者在视频下接上了那张变长的项目清单：AI让能力增长，想做的事也增长。
另一位网友则把“人的上下文优势”放到老项目里检验：许多背景已埋在多年代码与取舍中，未必还完整存在于任何一个人的脑中。让Agent理解项目之前，团队可能得先把这些背景找回来。
吴恩达不再怀念手写代码，也没有因此得到一张清空的项目清单。
Agent能在夜里继续跑，明天早上等着人的，仍然是几个很具体的决定：这个结果有没有用，要不要继续做，出了问题该从哪里查。开发速度上来了，这些决定只会来得更频繁。
参考链接：
https://www.youtube.com/watch?v=qeMMnOiF51A&t=1021s
——好文链接——返回搜狐，查看更多