我大量使用LLM进行软件工程编码和生产力提升。虽然在绿地项目中有效，但在存在重度依赖、强耦合和技术债务的遗留代码库中，质量会急剧下降。模型会为概念编造不一致的拼写，在不需要的地方编写适配器，或在需要适配器时却调用不当。这源于代码库中语言混乱和缺乏共同理解。

Brownfield项目有两层：技术深度和其下的混乱。模型会因为系统无法回答关键问题而错误猜测。可以逐步建立准备就绪状态。在软件工程的起步阶段，技术债务是唯一的关注点。团队交付速度快，付出权衡代价。通常的做法是将10-20%的预算用于清理，但决定要改动什么成本高昂，而随着LLM的出现，实施变得便宜。

我将作者身份拆分为战略和战术工作。战略涉及阅读系统、决定需要什么变更并确保一致性。战术将决定应用到文件中。战略工作需要深度的系统理解；战术工作现在具有成本效益。我创建了用于通用代码库分析的GitHub问题，然后使用具备技能和子代理的AI系统来解决它们。技能是确保一致执行的Markdown过程。

关键实体：人员：John Ousterhout