……我曾与外包的代码合作过，也与同样杂乱无章/缺乏前瞻性的一开始的初创公司MVP代码合作过，这些代码取得了成功，现在需要做更多、更可靠，同时运营成本更低。这并不漂亮。一旦你开始修改人们依赖的代码，你很快就会意识到代码本身的重要性。从质量角度来看，世界上没有足够的测试可以绕过这一点。而大量的复制粘贴代码会变成不一致的行为（从用户满意度角度来看是不好的）或持续拖慢速度（从产品目标/竞争力角度来看是不好的）。我曾对这些“找到MVP，现在需要快速迭代”的代码库运行过工具，无论是杂乱的部分还是较好的部分。当然，Claude可以处理“让我找到这十个复制粘贴版本并尝试全部更新”这类痛点，并追踪所有奇怪的愚蠢错误/繁琐的问题，因为每个版本都比人类能跟得上得更快地独立发展……
源讨论为什么HN的群体对AI这么反感？原帖 765 条评论 · 导入时统计有深度的评论，我想再补充一个角度：无论社区是否分裂，我认为个人在这一问题上也是"分裂"的。 我可以以自己为例（尽管样本量是1）：我非常开放地接受机器学习及其带来的进步。另一方面，我非常清楚当前的LLM经常写出糟糕的代码，一旦项目超出“私人玩具”的规模，这一点就变得尤为明显。对我个人而言，这意味着我努力让我的项目更加模块化，模块之间的界限也更加清晰。在适当指导的情况下，当前的LLM在处理孤立的模块时大多表现良好。这并不意味着它们在那里从不失败，但有时在你让它们在代码库中自由发挥时，它们也会偶尔提出令人惊喜的巧妙解决方案，只要问题足够明确。…
完整原文把你的经验，加入这段讨论。
> 你的代理程序一直在运行好几个小时，进行越来越多的测试，试图在所有地方做出改变，却无意中破坏了更多东西。 我曾经有过这样的经历，使用Claude本身编写的vibe-coded应用程序。不知为什么，Claude除非我告诉它，否则不会使用任何好的实践方法，似乎需要我先向它展示一个不错的设计。
完整原文问题在于，大多数进行vibe coding的人或使用“任何人都可以编程”这种说法的人忽略了软件不仅仅是代码堆砌，还包括文档、测试、设计文档以及许多其他AI（LLM并不是智能的）想要做任何有用的事情所需的其他成果。而且他们中的大多数人永远不会达到使用LLM变得比有帮助更麻烦的阶段，因为到那时他们要么已经有了产品并雇佣了人来处理，要么项目被放弃了，不再使用。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。