“前端已死”说早了!Epic React创始人:框架已经不重要了,AI会写React并不代表能做出好产品

51CTO技术栈 · 软件开发

原创 姜篇 2026-11-05 18:04 日本 肯特:我仍然认为开发者有很多东西要学,但框架已经不是最重要的了。 编辑 | 姜篇 肯特:我仍然认为开发者有很多东西要学,但框架已经不是最重要的了。 肯特:练习编程时,不要为了“学得扎实”就关掉AI助手。你将来就是这样工作的;工具写完之后,你还得弄懂它做了什么。 肯特:代码生成得更快,不代表用户体验会跟着变好。软件仍然需要真正在乎用户体验的开发者。 肯特谈起自己的变化:过去花一年打磨一门课,发布后能教很久;现在 Agent的用法几周就换一次,课程还没做完,部分内容可能已经过时。他甚至认真想过,接下来到底该教开发者什么。 说这些话的,是Epic React课程作者肯特·C·多兹。 现在Agent的用法几周就可能变一次。他开始担心,课程还没录完,讲工具操作的部分已经过时了。 一个教React多年的人,为什么开始说“框架不是重点”? 肯特并没有说React不用学,也没有劝新人跳过编程基础。 主持人问,初学者练习时是不是该关掉AI,自己把代码一行行敲出来。肯特说不必: 开发者在真实工作中已经在用AI,练习也该接近真实工作 。难处在后面。Agent交出一个能运行的页面,你是否看得懂它怎样处理状态、哪里可能出错,需求变了又该从哪儿改起? 访谈中还有一个让开发者无法回避的例子。主持人用过一款点餐应用,页面卡住,最后连订单都没下成。他问肯特:写代码的工具越来越快,为什么用户用到的软件没有同步变好? 肯特也没有把故障归咎于AI 。他说,团队写完页面,还得有人把整条流程走通。用户下不了单,再漂亮的组件也交不了差。 这也是肯特如今更想教“产品工程”的原因。他所说的产品工程,是把想让用户完成的事,和软件具体怎样实现、怎样验证连起来。 访谈的最后,话题走到了前端更远的地方。如果Agent能替人操作软件,网页还要不要做?肯特的回答是要。有些任务交给Agent方便,但有些时候,人就是想看清有哪些选择,或者直接按下一个停止按钮。 从学React、用AI写代码,到用户能不能下单、界面要不要保留,肯特谈的是同一份工作的不同环节:生成页面只是其中一步。当这一步越来越快,开发者仍得知道页面为什么这样工作,以及用户能不能靠它把事情办成。 肯特说仍有很多东西值得教,但框架已不是他最想教的重点 以下根据访谈整理。 教 React的人,先被自己的课程问住了 肯特做技术教育多年,习惯用很长时间准备一门质量高的课程。 Agent起来后,这种节奏首先让他难受:工具变得太快,讲某个版本、某种操作流程,可能刚录完就要重录。 肯特:我可能花一年准备课程,等发布时,它已经过时了。我得想想,有什么东西能让开发者学会以后,过一年仍然有用。 肯特谈自己过去一年做一门课的方式为何受到冲击 主持人说,自己以前常听肯特讲 React、Hooks和`useEffect`,现在这些话题少多了。 肯特接过话:我仍在做教育,也相信开发者还要学习,但自己不想把下一个重点继续放在框架上。 他把方向转向“产品工程”:从用户想得到的结果出发,设计能实现这个结果的系统。 肯特:产品工程要连接两件事:产品希望达成什么结果,以及技术上怎样把它做出来。只把实现交给Agent,还不等于把这两件事接上了。 肯特解释自己所说的 “产品工程” 工程师还得决定订单状态什么时候更新、支付失败怎样返回、重复点击会不会多扣钱,以及该用什么测试确认这些路径。 学 React时要不要关掉AI?肯特说不要 主持人接着问到新人学习:练习时该不该关掉 AI助手,逼自己把每行代码写出来?肯特的答案是 不要 。 他认为练习应接近以后真实工作的样子,而真实工作已经在用这些工具。 肯特:不要关掉AI助手。你将来就是这样编程的,练习时也该用它。但它替你写完之后,你仍要弄明白发生了什么。 他回忆,早期的代码补全会直接把练习题写出来,他还能要求学生停下来读懂。后来工具变成对话式 Agent,甚至开发者自己也不再逐行看代码,原来的教学方法就不好用了。 肯特谈新人怎样从初级走向资深 肯特:新人成长为资深工程师,并不是因为把语法敲了足够多遍,而是因为开始处理资深工程师处理的问题。 但他紧接着说:碰到架构和技术取舍时,仍要思考,弄懂底层为什么这样工作。 对前端开发者来说,这个区别并不抽象。 Agent会替你写一个带搜索框的React组件;你仍要知道搜索请求何时发出、旧请求回来会不会覆盖新结果、页面重载后状态是否丢失。不会背出每个Hook的API,和完全看不懂页面行为,是两回事。 代码快了,为什么用户还是点不了餐 主持人讲了自己的经历:在一款点餐应用里,页面卡住,他没法完成下单。他问肯特,工程师有了更强的 AI,为什么用户体验没跟着变好? 肯特:代码能很快生成,不代表好的用户体验也能很快产生。团队仍然需要真正在乎用户体验的

查看原文