Microsoft构建aspire.dev的高级软件工程师“文档在哪里？“这是一个产品团队中没有人喜欢回答的问题。诚实的回答通常是“背后”的一些变体。“一位作家正盯着一个封闭的拉取请求，试图对发生的变化进行逆向工程。拉取请求的作者已经继续前进。
到文档实际发布时，该功能已经发布，有时不止一次。我们曾经是Aspire团队的一员（我们是一个小团队，有10个为分布式应用程序构建开发工具）。几个月前，我们试图找出如何安全地将人工智能引入我们已经信任的自动化系统。就在那时，我们发现了GitHub Agentic Workflows。我开始将原型连接到Microsoft/ASPIRE中。
以下是直接从GitHub中提取的数字：对于Aspire 13.3和13.4， 82个功能文档拉取请求在产品拉取请求后以中位数44.8小时合并，每个请求都由发布该功能的工程师审核。无新员工人数。无流程再培训。
只是一种不同的方式来问“谁写的？“约束：跨仓库自动化是最难的部分我们的产品生活在微软/ASPIRE和我们的文档网站生活在微软/aspire.dev -不同的仓库，部署目标和审查链。大多数团队很快就发现了相同的备份自动化；跨备份自动化是事情变得尖锐的地方。
广泛的回购范围的代币属于博物馆，任何负责任的安全态势（包括我们的）都会相应地限制它们。这是一件好事。如果您编写文档的地方不是编写代码的地方，这也是一个真正的瓶颈。多年来的默认工作流程是：工程师在Microsoft/ASPIRE中发布一项功能。Docs作者在几周后才注意到。