AI程序员需要新的软件生命周期管理软件
马工在瑞典约 2 分钟今天和朋友们在线讨论2027年的软件工程长什么样。大家认为一两年内AI将成为软件开发主力军，而人类则更多的做一头一尾的工作: 协调AI精确的理解需求，以及验收软件。这个职责，和今天使用外包商的甲方项目经理的职责几乎没有一致。
项目经理严重的依赖需求管理/任务跟踪软件，比如Jira，Linear，ClickUp。这是衔接需求提出方和需求实现方的渠道，是最重要也最容易出问题的环节。
再过去两个月，我和AI使用过Jira，Linear和GitHub Issues，感觉到这些老牌软件不太能满足AI的需要了。我们需要一个新的需求管理软件。
这个软件的定位是软件开发生命周期所有角色交互的聚集点。这些角色包括客户，产品经理，项目经理，架构师，程序员，测试工程师，安全工程师。其中有些角色由人类扮演，而有一些角色则主要由AI分担，甚至有些角色是软件扮演的。
AI和软件并不擅长阅读Web界面，他们更偏好CLI或者API。因此软件要同时提供CLI, MCP和Web界面，服务于代码，AI和人类。而提供给人类的Web，应该是个人定制的，甚至是嵌入到个人日程表的。
由于AI工作速度很快，而且可能有很多个（上千个）AI agents同时工作于同一个项目，那么需求软件要提供可靠的mutex机制，避免AI agents冲突。
传统软件从提出需求到开始验收是以周和月为单位的，而AI编码能把这个时间缩短到小时甚至分钟级别，那么把验收和需求分开管理就没有意义了。新的软件应该把测试文档和测试案例视作需求管理软件的一等公民。需求提出方应该在提出需求的当时就说清楚验收标准。
传统需求管理软件只管理需求版本，而代码版本则交给Git，文档版本则交给了大家的邮箱或者Google Docs，设计过程的讨论则只记录在会议纪要，这就造成了信息的割裂。 在2028年，应该有一款软件管理所有信息的版本，以便给AI提供充分的上下文。
我现在把AI的设计讨论同时记录在git和github Issues，这是不得已的妥协。
总而言之，AI就给软件行业的时间窗口不长了，不论是从业者还是行业软件，都会被颠覆。喜欢不喜欢，它都会发生。