V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
djyde
V2EX  ›  程序员

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

  •  
  •   djyde ·
    djyde · 114 天前 · 2726 次点击
    这是一个创建于 114 天前的主题,其中的信息可能已经有所发展或是发生改变。

    原载于我的博客 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.

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

    10 条回复    2024-08-12 14:16:44 +08:00
    JustW
        1
    JustW  
       114 天前
    已经用习惯 github copilot 了, 现在代码的注释量蹭蹭往上涨.
    Zaden
        2
    Zaden  
       114 天前
    刚在 rss 里看过
    chuunshii
        3
    chuunshii  
       114 天前
    写的太棒了,和我感知到的也一样,我们老板非常沉迷于“一句话让 AI 生成一个系统”,我用过 AI 后,发现根本不是那一回事儿。
    yinmin
        4
    yinmin  
       114 天前 via iPhone   ❤️ 5
    老板们马上会发现:在 ai 的助力下,30-45 岁的高级程序员才是效率最高、成本最低的。

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

    在涉及到大片核心代码的情况下,ai 极有可能生成不符合我的架构设计的代码,即便能跑也严重影响可扩展性。
    8355
        10
    8355  
       112 天前
    @artiga033 一个是你的基础逻辑不适合 ai ,一个是你的注释写的不够严谨。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6051 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 02:35 · PVG 10:35 · LAX 18:35 · JFK 21:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.