vibe coding 可能忘记了代码是需要持续维护的

[MidCoder]

今天看到 infoQ 一篇文章，观点是 AI 编程从定量的角度去衡量，实际是降低了研发效率（可能不是针对所有人和所有场景）

这个观点对于作为一个工作十多年的服务端开发来说，和我预想的比较一致。vibe coding 距离媒体宣传中预期的目标差距很远。曾经有一位大佬说过：每天新增的代码对于企业来说是每日新增的成本。如果是按照这样去思考，一个差评冲 0 到 1 到后续的持续迭代都是通过 vibe coding 去进行项目开发交付，会受到 context length 问题导致无法完全理解整个项目的内容（持续迭代的历史、系统链路关系、业务流程迭代等），那么这就带来一个问题，谁来维护整个系统的工程代码，比如业务模式需要升级，vibe coding 是否能够比较低成本的帮助我们做系统的重构？又比如，系统链路要做性能优化或者产品交互层面的优化，vibe coding 是否可以通过全局分析去进行问题发现和最佳的修复？经验丰富的人可能都知道，这些重构和优化，可能需要结合业务策略的配合，这部分 AI 并不感知，要做到它感知，成本是极大的。

我觉得 vibe coding 可能加快了想法的验证，降低胶水代码、工具代码的开发成本。但是当想法要去演变成一个体系化的商业模式，需要一系列的业务系统去支撑时，可能 vibe coding 就失效了。

[zzj0311]

@mumbler 确实 以前重构小心翼翼 现在一个不爽几百个字就给他重构了😅

[leelotov2er]

vibe coding ，不愿意用的人能找出千百个理由不用，好像这些人每天在公司都写的高深的代码，AI 处理不了一样，自己写的不是屎山一样

[charlie21]

你的人类同事 vs 你的 AI 同事

1. 无论听者是 AI 同事还是人类同事，人类作为说者 对于复杂问题的描述能力其实是非常有限的，这里必须要求听者机灵一点

2. 如果描述都错误了，那么这是 GIGO (Garbage in, garbage out)。诚然，这是说者的责任。但一个说者对此是不会认错的，原因就是 “对于复杂问题的描述能力其实是非常有限的”，这是人类的通病

3. 输入的是垃圾，输出的是垃圾，这是客观存在的

4. 同样是 GIGO, 人类听者的纠错性远远大于 AI 的纠错性：假设你是说者，你的同事 / 你的 AI 同事是听者

- 你的同事可以告诉你，你说的前后矛盾，你说错了，即 你的同事能仅仅从不完整的业务描述里直接反推出业务的不可理性。AI 能吗？ AI 努力的方向是 “理解人类的需求”（将错就错）

- 你的同事甚至可以告诉你正确的需求应该是什么

- 虽然 AI 同事擅长找到正确的答案，但人类同事擅长找到正确的问题

5. 问出正确的问题比找到正确的答案更重要

综上，你的人类同事打败了你的 AI 同事

[zmcity]

AI 不是在持续集成方面比人更强吗，而且重构还快

[msg7086]

@nbndco #14 这就体现出程序员 vibe coding 和非程序员（或者不聪明的程序员） vibe coding 的区别了。聪明的程序员让 AI 写测试用例覆盖业务逻辑，跑通以后既不需要复杂的 debug 也不用担心重构出现问题。而剩下的一些人则在那空喊着 AI 写的代码 debugging 要老命 review 要老命重构要老命。

[XTTX]

Cursor 会自动写一大堆 .md, 还会自动出 svg 架构图。 复杂一点的代码我会让几个 AI 全部撸一遍， 挑一个最容易读懂的

[nbndco]

@msg7086 这就是写过程序的程序员和没写过程序的程序员的区别了。先不说测试本身就高度绑定代码的设计，怎么样的 test coverage 可以保证只凭借 test 就可以确定程序的正确性呢？都不说正确性了，现实中有几个框架的 testability 真的可以满足这种需求？空想只要 ai 生成了 test 就可以随心所欲让 ai 写代码的人，真的写过代码吗？

[gorira]

看着自己天天都在用，用了两年多的东西，在网上天天被别人质疑，有种听我爸妈唠叨我「别一天到晚玩盯着电脑了，眼睛会瞎的」的感觉😂