「代码艺术家」不会被 AI 取代

99 天前
 djyde

原载于我的博客 https://lutaonan.com/blog/code-artists/

最近大量地使用 Cursor 替代了 VS Code, 开始习惯直接在编辑器里告诉 AI 我的需求,让它来代替我写出代码段。

请注意,我用了「代码段」这个词,而不是「代码」,因为我想做一个区分 —— 按照我目前的经验来看,生成式 AI 非常擅长生成一段内聚的代码,而不是一整个应用程序。

在没有 AI 生成代码前,我写代码也是这样的一个流程:

  1. 思考整个应用的架构、模块
  2. 选择适合的技术栈
  3. 开始写代码,设计目录结构、抽象
  4. 真正开始实现实现

AI 也许能为第 1 和第 2 点提出建议,但我目前不需要。第 3 点我认为对于稍微复杂一点的生产级应用,AI 还做不到把这一块也做到。可能很多人看到现在 Claude 直接能写出一个全功能的 Todo List 就惊叹 AI 要取代程序员了,我觉得真正写过一个完整的给用户使用的「应用」的朋友对此都会很淡定。

对于我来说,只有在第 4 步(实现) 的阶段才真正能杠杆 AI 的能力。我会尽可能地描述清楚我的需求,让 AI 能理解我要做的任务,让它来生成满足我的抽象的代码,或修改现有的代码。

这里我提到的描述清楚我的需求是用 AI 生成代码中最重要的一点。所谓的「需求」不仅仅是描述这个函数需要做什么事情,还需要包含这个函数应该接收什么参数,返回的是什么数据结构。

例如,我在做的一个应用,其中我需要一个上传文件到 S3 的函数。在这个需求中,如果我单纯告诉 AI 它要做什么,那我很有可能得到一个可以实现功能但不适合我调用的函数,因为 AI 没有上下文去确定我可以传哪些参数给它。

在深度和 AI 「结对编程」后,我对于「 AI 是否能取代程序员」这个问题有了更深刻的思考。

有了 AI, 我现在写代码花的精力主要是在「设计」上,例如思考这个应用的交互设计,例如整个应用的架构设计。所谓的架构设计,一部分的工作是决定这个系统里要有什么模块,一部分的工作是决定这些模块如何串联在一起。而这些设计工作恰恰是我写代码的时候最喜欢做的,对我来说,写代码就应该是一个设计的过程,设计出优雅、易用、易扩展的接口是一件很有成就感的事。这也是我当初看 Head First Design Patter 这本书时的感受。
 如果写软件变成了一个只需要花精力在设计而不是实现上的过程,那么写软件的人就是「代码艺术家」了。我觉得「代码艺术家」是不会被 AI 取代的,因为设计的起点和终点都是人类,AI 可以给你 100 个设计上的答案,但只有人类最终能感知到现实和当下的环境和信息,创造出能触动另一群人类的产品。

如果你从现在开始,开始把 AI 当作是你的员工,就像某一天你突然只需要 $20 一个月就能招无数多愿意帮你打工的人,你很快就会发现,你最终会面临两种局面:

局面 1:你将手足无措,你突然发现如果你不是实现函数的那个人,你就不知道你应该做什么了。从前你沾沾自喜的手写快排,手写红黑树突然变得一文不值,无处施展。

局面 2:你将如虎添翼,你突然发现你曾经有很多想法没有精力和时间去实现,现在突然有这么多廉价劳动力将不厌其烦地帮你写代码,而你要做的只是设计好整个系统的结构,把具体实现外包给 AI. 然后把产品推出市场,去碰壁,去失败,去成功。显然,AI 不能替代你去碰壁,去失败,去成功,但真正让你变得强大的不是你手写快排有多烂熟于心,而是去碰壁之后学习到的东西

AI 不会替代「代码艺术家」,因为 AI 是「代码艺术家」的喷射机

读到这里,可能有人要说,Randy, 你飘了,你开始技术虚无主义了。在这里我要申明,这篇文章我是写给有一定经验的程序员看的。对于没有什么经验的程序员,多写点代码总是好的(至少目前来看)。AI 能力的上限是由用的人的上限决定的。无论是任何行业,充分掌握领域知识后配合 AI 才是最好的做法。

就像下面这个例子,我只要说一句 add tanstack query provider 就能让 AI 帮我把 @tanstack/query 加到我的程序里。我自己会写,但我自己写可能要花一两分钟,但 AI 一下子就好了。

但如果你没有任何代码经验,你连 tanstack query 是什么都不知道,也不知道要放在程序的哪个地方,那用 AI 还是有点困难。

写下这篇文章是因为最近用 Cursor 有感,加上刚好看到 Daniel Nguyen 发了一篇 Software is Art, 有感而发,不吐不快。在此粗浅翻译(非 GPT ),作为结尾:

I realize the reason I like building is not just because I’m a builder.

我意识到我一直喜欢创造点东西的原因不只是因为我就是个创造者.

It’s because software products are how I express my creativity.

而是因为写软件产品是我表达我的创意的一种方式

It’s like a poem to a poet, a song to a songwriter, a painting to a painter…

就像诗人的诗,歌手的歌,画家的画

Software is my art form, my medium of expression.

软件是属于我的一种艺术形式,是我表达(创造力)的媒介。

2704 次点击
所在节点    程序员
10 条回复
JustW
99 天前
已经用习惯 github copilot 了, 现在代码的注释量蹭蹭往上涨.
Zaden
99 天前
刚在 rss 里看过
chuunshii
99 天前
写的太棒了,和我感知到的也一样,我们老板非常沉迷于“一句话让 AI 生成一个系统”,我用过 AI 后,发现根本不是那一回事儿。
yinmin
98 天前
老板们马上会发现:在 ai 的助力下,30-45 岁的高级程序员才是效率最高、成本最低的。

新手程序员无法及时发现 ai 的深层次问题,导致调试时间过长和代码存在隐患,而这些问题能被经验丰富的老程序员轻松化解。
GeekGao
98 天前
@yinmin 问题是老板无法量化这些。
konakona
98 天前
@yinmin 很好的观点
luoling8192
98 天前
感谢推荐!种草了~
atpex
97 天前
@yinmin 老板们会发现的,但昭和土皇帝们只会觉得年轻人能加班且招应届生有补贴
artiga033
97 天前
是这样的,反正我从 github copilot 刚出那会用到现在,体验就是只能用来写基本业务无关的独立功能,以及测试用例之类的。要么就是 golang C#那种比较啰嗦的语言能省不少样板代码的击键次数。

在涉及到大片核心代码的情况下,ai 极有可能生成不符合我的架构设计的代码,即便能跑也严重影响可扩展性。
8355
97 天前
@artiga033 一个是你的基础逻辑不适合 ai ,一个是你的注释写的不够严谨。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1063989

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX