ARTICLE · 1142399
AI写得越快,程序员退化得越快?一篇52万次浏览热帖的警告
AI写得越快,程序员退化得越快?一篇52万次浏览热帖的警告凌晨两点，线上冒出一个偶发错误，你打开仓库，发现编码 Agent 昨天下午改了十几个文件。测试大多通过，日志也很完整。你让它修，它很快给出补丁。旧错误消失了，另一个测试又开始失败。 几轮之后，代码越来越多，你却越来越没底。每个函数单独看都说得通，可你不知道系统为什么变成了这样。 这正是 Haskell 社区一篇52万次浏览热帖担心的事。作者 turion 是一名 Haskell 程序员。他没有拒绝 LLM，也承认自己的效率大约提高了一倍。但他的工作方式，和现在流行的“把需求扔给 Agent”完全不同： 计划可以和 AI 一起做，关键代码尽量自己写。 因为写代码从来不只是把需求翻译成语法。 你在实现一个函数时，会发现需求里藏着矛盾；设计接口时，会察觉数据边界没有想清楚；写到第三个相似分支时，可能突然意识到，这里需要的不是再复制七遍，而是换一个抽象。 这些犹豫、试错和推翻，才是理解系统的过程。 AI 可以一次生成几百行实现，却不会把形成理解的那段经历一并交给你。你拿到了结果，中间那条路探索的过程却被折叠了。等代码出错，你面对的不是自己搭起来的房子，而是一栋拿到钥匙、却没看过图纸的楼。 所以，“AI写，人审查”并不总是轻松。 阅读一份陌生实现，往往比自己写更累。你要先猜它采用了什么思路，再判断这个思路是否符合业务，最后检查局部修改有没有破坏系统约束。生成成本已经很低，理解成本却一点没降。 更麻烦的是能力退化。 如果连续几周只负责描述需求、接受补丁和运行测试，你会慢慢发现，面对空白文件时开始迟疑。过去熟悉的 API 记不清了，调试时也不愿意顺着调用链往下走。遇到困难，第一反应变成再问一次模型。 人没有变笨，只是任何长期不用的能力都会生疏。LLM 把“停止练习”的门槛降得太低了。 这个作者建议换一种分工：让 AI 围着程序员工作（不知道有没有道理？）。 让它阅读代码库、梳理调用链、整理需求讨论、记录测试结果、提醒可能遗漏的边界；让它处理容易验证、失败后方便回滚的任务，比如补测试、换依赖、清理样板代码。架构选择、业务边界和核心实现，仍然由人掌握。 这并不是对手写代码的怀旧。亲手实现，本身就是对设计的压力测试。 一个方案到底顺不顺，写几十行就能感觉出来。接口不断增加特殊参数，说明抽象可能错了；多个模块必须一起修改，说明边界可能不清；同类代码被复制多次，说明真正缺少的是统一模型。 编码 Agent 往往会沿着计划一直向前。经验丰富的程序员却可能在第三十行停下来：“不对，这条路走歪了。” 这种停顿看起来降低了产出，实际上可能省掉几周返工。 文章还有一个很实用的判断：Token 用完，不是“自己买少了”，而是外部服务中断。 如果模型额度耗尽，项目就完全停摆，说明 AI 已经成了开发流程的单点故障。研究结果、实施计划和待办事项应该写进仓库，而不是只存在聊天窗口里。即使模型暂时不可用，人也知道项目进行到了哪里，接下来该做什么。 能不能在没有 AI 的情况下继续推进，是检验你是否仍然掌握项目的一个简单办法。 普通开发者真正要防的，或许不是 AI 抢走工作，而是自己逐渐失去独立接管工作的能力。 以后代码会越来越便宜。真正稀缺的，不是能让 Agent 生成一万行代码的人，而是在一万行代码生成以后，仍然知道哪里不能信、问题该从哪里查，并愿意为结果负责的人。 参考来源：Haskell Community，《How to keep enjoying programming in a world of LLMs》