AI编程的泛滥正是所谓“用户不在乎代码质量”思潮的结果

寂静回声

"用户不在乎你的代码质量，只在乎产品能不能用。"有个叫Lewis Campbell的工程师专门写了篇文章怼这句话，标题是"用户不在乎  但你应该在乎"。       
他说你把这个逻辑套到别的行业试试，开车的人不在乎桥有没有通过最终验收，只在乎桥能不能撑住车。
乘客不在乎飞行员是不是喝醉了，只在乎飞机能不能准时到。上班的人不在乎摩天大楼的地基稳不稳，只在乎能不能赚钱。
       
桥没验收，塌了。飞行员喝醉了，飞到一半掉下来。
地基不稳，地震的时候整栋楼倒了。代码质量差，性能一塌糊涂，bug修不动，加个功能要改三十个文件。       
他说这些"用户不在乎"的论调，本质上是自我辩护。
一个人如果意识到自己写不好代码，最简单的出路就是说服自己代码质量根本不重要。
最好是反过来，那些在乎代码质量的人，才是问题。你们太理想主义了，你们在拖慢我交付的速度。

过去手写烂代码还受限于人力效率，技术债的累积有速度上限。而大模型可以在几分钟内生成上千行 “功能可运行但结构混乱、耦合严重、毫无设计逻辑” 的代码，给 “重交付、轻质量” 的团队制造了虚假的效率爆发。
很多开发者既不校验 AI 代码的架构合理性，也不做完整的边界测试与代码评审，仅以 “功能跑通” 为唯一验收标准，直接让大量未经打磨、隐含风险的劣质代码进入生产环境，让技术债从 “缓慢累积” 变成了 “批量堆砌”。

代码质量的核心价值之一是可维护性，清晰的分层、规范的命名、低耦合的设计，是所有后续迭代的基础。当代码库被 AI 生成的 “一次性代码” 填满后，无论是人类开发者还是 AI 本身，都很难厘清混乱的逻辑脉络。
后续新增功能、修复 bug 时，开发者既不敢轻易重构，也无法精准修改，只能在混乱的逻辑上继续打补丁，代码会越改越乱，技术债以复利速度增长，最终彻底丧失可维护性，形成 “越用 AI 写，代码越烂；代码越烂，越只能靠 AI 瞎凑” 的死局。

AI 带来的快速交付能力，会让管理者更加坚信 “代码质量不重要”，进一步压缩架构设计、代码评审、技术重构的时间与资源，甚至把 “AI 快速堆功能” 当成核心考核指标。
这种导向会倒逼开发者彻底放弃质量底线，从 “主动写烂代码” 变成 “被迫用 AI 批量生产烂代码”，让整个团队的工程能力持续退化，最终彻底失去自主把控产品质量的能力。

本质上，AI 只是效率工具，它既可以辅助高质量工程实践，也可以加速劣质代码的泛滥。问题的根源从来不是 AI 本身，而是 “用户看不见就不重要” 的短视逻辑 —— 它先是消解了人对代码质量的敬畏，如今又借着 AI 的产能，把整个行业拖入 “重速度、轻根基” 的劣币驱逐良币的循环里。就像再先进的工程机械也不能替代桥梁的结构验收，再高效的编码工具，也绕不开软件工程的基本规律。