AI编程时代，《人月神话》结论还适用吗？

过去有一本曾经风靡一时的软件工程经典叫《人月神话》。它来自作者Brooks上世纪六七十年代大型软件工程的实践，核心讨论的是：软件开发并不是简单的“每人每月”工作量相加。工程项目规模越大，人与人之间的沟通、协调、学习和系统集成成本就越高，因此给一个已经延期的项目增加程序员，甚至可能让它更慢。

一个自然而然的问题是：在AI编程的时代，《人月神话》的这些结论还成立吗？

今天的AI已经可以在一天乃至个把小时里做出一个能跑的app，但从“能跑的程序”到真正的软件产品，再到大型软件系统，中间还有巨大的鸿沟。Login、payment、database、security、异常处理、长期维护，以及大型系统里的依赖和集成，都不是“多生成一些代码”就能解决的。AI编程和实际的软件工程之间还具有巨大的鸿沟。

当然，一种很有吸引力的答案是harness engineering：通过模块化、清晰的interface、tests、CI/CD、sandbox和agent orchestration，把一个大型工程拆成大量边界清楚、可以自动验证的小任务，让AI agents分头完成。如果这条路走得通，那么《人月神话》里最重要的瓶颈、即人的沟通和协调成本确实可能被大幅削弱。

但问题也可能只是被转移了：过去的瓶颈是人与人之间的协作，未来的瓶颈可能是specification和verification。AI可以越来越便宜地生成代码，但我们是否能够完整地定义“什么是对的”，并自动验证一个拥有无数依赖、边界条件和未知失败模式的大型系统？换句话说，AI可以迅速地生成一些东西，但是验证端依旧是一个瓶颈。

所以AI coding真正的问题也许不是“AI会不会写代码”，而是：我们能不能用软件工程把大型软件的复杂性控制到足以让AI自主处理？现在这依旧是一个很大的问题。如果可以，《人月神话》可能真的会成为属于上一个时代的经典；如果不可以，那么AI消灭的可能主要是coding的成本，而不是software engineering本身。