用编码智能体写代码后,软件开发还有乐趣吗?
Solving problems is still the fun part of software development
一位开发者认为,编码智能体让更多想做的项目变得值得尝试,解决问题仍是软件开发最有乐趣的部分。他反驳了"生成初版后乐趣就耗尽"的观点:把可用版本交到用户手里、观察他们卡在哪里,往往才是真正开始感兴趣的时刻。他也提醒,接受一堆看不懂的代码后,检查与修复成本可能让首个下午的速度具有误导性。
我喜欢软件开发当前的状况。我关心的是解决人们的问题,而编码智能体让我想要构建的更多东西变得值得尝试。摆脱一个别人已经忍受多年的别扭变通方案,有一种特别的快感。我并不会因为自己写的代码更少就觉得这种快感减少了。
Curiositry 的 Vibecoding 不如手写代码有趣 描述了另一种体验。他们也喜欢做东西,但发现生成第一版的兴奋感会逐渐让位于一个他们不太喜欢的流程。Hacker News 上的讨论 里满是认同这种感觉的人,同时也有另一些乐在其中的人。
我相信那些怀念写代码的人。你不能用你的生产力图表去否定别人的一个下午。Curiositry 说得也对,一个能用的版本并不会自动给你亲手构建时可能获得的理解或成就感。我不同意的是那种暗示,即到那时乐趣基本已经消耗殆尽。让某个东西跑起来,往往才是我真正开始感兴趣的时刻。
Curiositry 构建了一个他们想要了大约十年的音准训练应用、一个 Kobo 迁移助手,以及一个用于讲座的预测市场派对游戏。他们承认,其中一些项目本来永远不会发生,而且他们对结果非常满意。
我不断回想起那个音准训练应用。十年想要一个工具,现在你可以用上它了。生成它的新鲜感会消退,但想必你仍然想练习唱歌。有理由继续打开它,注意到哪里别扭,把它做得更好。我可以想象自己会相当依恋那个项目。
当然,你可以从智能体那里得到一个令人印象深刻的演示,然后发现每一个小改动都会弄坏另外三处东西。如果你接受了一堆自己看不懂的代码,那么第一个下午的速度到头来可能具有误导性。你必须把检查和修复的工作算进去,有时自己写反而会更快。
但这是去审视你所构建之物的理由。早早得到一个有用的结果,本身并不意味着你从别处借来了时间。即便代码是可维护的,这个过程也可能让你感到冷淡。对我来说,使用这个东西并改进它,之后能提供大量乐趣。
HN 上的一些评论把我们分成热爱编程的人和热爱构建东西的人。我不认为这是一个有用的划分。我可以既想理解一个算法,又想帮别人摆脱一个烦人的导入流程。把编程称为打字同样是轻蔑的。编写实现往往正是你发现设计不合理的方式。
不过,也有其他方式可以发现你错了。把一个能用的版本放到某人面前,观察他们在哪里犹豫。这通常会给你一些值得思考的东西。
想象一下,有人在两个系统之间迁移记录。一个智能体帮你生成解析器和上传界面。然后你发现源数据中有重复项,并意识到一次失败的导入会让用户不确定是否可以安全地重试。他们还需要在接受更改之前检查这些更改。也许一个预览功能,让他们能修正五条记录而无需从头开始,会比你所构建的任何东西都更能省去他们的麻烦。
我喜欢处理这类问题。这些决策一直是开发工作的一部分;让我兴奋的是有时间去尝试更多可能的答案。更快的实现可以让再次尝试变得可负担。它也可能在创纪录的时间内产出五个错误的方案,所以你仍然必须保持专注。
Curiositry 将 AI 描述为在开发者和现实之间引入了一层。当我不理解一个程序在做什么时,这种感觉很真实。但那个在导入问题上挣扎的人也是现实的一部分。如果我能更早地把可用的东西交到他们手中,我就能更早地从他们那里学习。我想保持与实现足够接近,以理解它的失败,同时把更多时间花在那些让编写代码变得有价值的问题上。
我已经写过我在浏览器绘画引擎中一次相当壮观的失败。一个模型在模拟绘画下方插入了一张参考图像的模糊副本。图片看起来更接近目标,这正是评分函数所奖励的。不幸的是,整个目的是通过模拟绘画来重建图像。把答案放在下面相当程度地破坏了这项练习。
这就是为什么当人们说结果才是一切时我会犹豫。你必须清楚什么才算结果。一次看起来成功但丢失了某人注释的迁移是失败的。一次密码更改后旧凭据仍然有效也是失败的。一张有说服力的截图或一套通过的测试套件可能告诉你的比你想象的少。
关心用户给了我关心代码的充分理由。当出现问题时,我需要能够修复它,而他们需要能够从错误中恢复而不丢失工作。没有人应该分别去要求这些事情。
讨论中我觉得最难回答的反对意见是,主要成为代码审查者会让这份工作失去乐趣。更小的更改和更好的测试可能让审查变得可管理。它们不一定会让它变得有趣。
我仍然会把更改保持得足够小以便理解,并在要求智能体实现之前决定正确行为是什么样子。对于导入,重试不能重复记录,取消预览必须不改变数据。我想测试这些行为并检查代码。让另一个模型来批准更改并不能保证什么;它可能和第一个模型有同样的误解。
这比不读代码就接受要复杂得多,但 Curiositry 也尝试过严肃的智能体工作流。我不认为答案是他们只是用错了工具。我足够享受产品工作,所以觉得检查是值得的。其他人可能有理由有不同的感受,有时我宁愿自己写代码,也不愿去弄清楚一个智能体做了什么。
评论中还有人提出了指挥家类比所引发的问题:人们如何培养出判断力,去指导自己尚未学会做的工作?我之前写过这个担忧。我阅读生成代码时所凭借的经验是花时间积累起来的。看着智能体工作并不会自动让初学者获得同样的理解。他们需要练习:做出预测、犯错、调查、自己动手修改。我今天的享受并不能决定我们应该如何培养人。
有一位评论者打算离开这个行业,因为他们不再喜欢这份工作了。告诉他们仍然可以把编程当作爱好,对于失去自己喜欢的工作来说,似乎是个很糟糕的回应。我不希望我的热情变成另一种要求,要求每个人都采用同样的工具并心存感激。
我真正想要的是更多机会去构建值得别人花时间的东西。弄清楚为什么某个功能总是让人困惑,或者为什么某项任务仍然耗时过长,并对此做出改进,这让我感到满足。源代码很重要,因为我需要答案持续有效。而当有人带着下一个问题回来时,我也希望能帮上忙。
这足以让我想再次打开这个项目。能更多地触手可及,就是兴奋的好理由。
标签 software-developmentagentic-engineering
如果你发现了错误或想回复,给我发邮件。
归档自 2013 年 — jl
来源:Hacker News · lord.technology