重读经典《人月神话》集合AICoding的思考
最近陪小孩一起看纸质书，又把案头的老书《人月神话》拿出来翻，发现50多年过去了，布鲁克斯的思考还是很有启发性的，不过集合当前的现状，还是应该有比较大的变化的，也希望发出来和大家一起思考？
一、AICoding 是否会打破人月神话的根本假设？
布鲁克斯定律的核心假设是：软件开发存在复杂性，不能简单的通过增加人来提高速度；在当前云基础设施高度发达，微服务架构和API驱动的开发模式下，借助于AI编程，工作的复杂度降低或可分割性提高，特别是CAP理论的发展，可能会重新定义 软件开发规模的评估。不是简单的 人和时间。编程AI处理的时间，消耗的Token数目也许成为新的参考。
二、概念完整性在当前需求随需而变，先做POC或MVP，然后在搭积木的思维冲突下，是否还有必要？
《人月神话》强调概念完整性，这点即使在现代也是有意义的，很多产品特别是开源产品在开发过程中，都是遵循“MVP快速上线+迭代优化”的模式进行，不过迭代到一定的程度后，通常在进行大版本的重构，甚至架构的重新设计。在当前的AICoding模式下，AI不仅仅可以编码，还可以对已有的架构进行评价，按照这种原则，概念完整性，在重要软件产品或者对稳定性要求高的产品还是有必要的，也就是AICoding所要遵循的规则、用户规则和项目规则这些上下文中体现。从这个角度来说，概念完整性，我仍然支持。
三、AI辅助开发甚至AI代理开发，有没有可能成为新的银弹？
布鲁克斯从软件的本质和偶然的角度来定义软件的复杂性，通常无法通过单一的工具或者方法论，解决所有的软件问题，不过AI的快速发展，AI编程可以通过各种技术进行工具集成和快速学习，并且通过训练和当前GIT代码库的各种可用优秀软件的代码实现，AI已经可以生成复杂的代码和并可以理解需求自行设计。不过还是不能完全解决软件本质的复杂性，也许将来更加厉害的AI出来，完全代替人类编程，类似黑客帝国的智能体。那样可能真的有银弹了，我等码农坐等AI 帮我等屁民打工。不过AI是银弹还是铜弹铅弹，还要进一步观望。
四、AI会不会加剧“焦油坑”的进化，导致出现更加无法应对的问题？
布鲁克斯把大型系统比喻为“焦油坑”，史前巨兽在其中挣扎沉沦。当前现状会让“焦油坑”，变得更大，更深，由于很多服务或模块的封装，有时候一个简单的看起来很小的软件，就用到了很多外部依赖，并且需要协调，这使得我们装备更加先进，但是面对的复杂性也更加巨大。调整心态，勇敢面对，不回避。我们当前要学会更好的武装自己，同时要学会在“焦油坑”游泳。
