再发一个AI辅助开发兴起之后的观察：

AI兴起前，代码的长期可维护性一直是软件开发的重要关注点之一，AI兴起以后，很多简单功能和原型可以交给AI快速实现，因此”日抛“型代码显著增多了。

这就引发了一个问题，过去被视为”会增加技术债务“而设置的可维护性门槛，是否还有存在的必要？

从我的观察来看，使用AI辅助开发时，由于上下文的限制，相比于代码重构和复用，新写逻辑要快的多，因此会不可避免的产生大量的重复的代码。

这些代码有一部分的生命周期很短（比如一次性任务或者原型），成为了”日抛型“代码，它并没有降低原有的技术债务，只是没有增加额外的技术债务。但是另一部分代码则进入了更长的生命周期，并且成为了长期技术债务。

如果降低门槛，那么代码库会迅速被大量的AI代码占据，并且成为巨量技术债务，但另一方面，如果坚持高可维护性门槛（复用、重构、review等等），那么很大程度上就会损失掉AI带来的短期效率的提升：目前的市场环境下，低效就等于自杀。

目前我的思路更倾向于敏捷方案：把可维护性的门槛设的靠后一些，允许前期快速落地，但是当业务开始出现长期运营的苗头时，重新建立可维护性的门槛。

之前说过，敏捷开发对于开发人员素质的要求是更高的，需要在软件产品生命周期中持续把握住架构的“变”和“不变”，并且不断地做出调整。在这个过程中，每次变更都可能会涉及到小规模的重写与重构，对于谈重构色变（“代码还能跑，不要动”）的程序员来说，这几乎是不可能完成的任务。

因此，我认为能在未来竞争中活下来的公司，技术上起码要具备两个能力：
1 对AI的使用足够充分，开发效率足够高
2 能控制住软件质量爆炸的风险