在过去几年里，我在编码，或者更一般地说，在软件工程中大量使用了大型语言模型（LLMs）。我多次观察到我能获得的生产力提升，并在我的越来越多的项目中使用了LLMs。它在绿色项目和小型项目中效果良好。现实是，在日常工作中，我们需要将代理引入到具有重依赖树、强耦合以及充满未解决技术债务的遗留代码库中。我们很快注意到，LLMs可以提供的工作质量急剧下降。失效有特定的形状。在一个绿色项目中请求“工作状态”字段，你会得到一个。而在一个已经上线四年的系统中请求它时，模型会发明出已有三种拼写的概念的第四种拼写，因为代码库本身从未决定哪个是实际的。它在本来没问题的地方写了一个适配器，或者在一个适配器原本是整个要点的地方直接调用。每一个都是一个关于系统的问题，但系统没有在任何地方回答。模型猜测，往往猜错。因此，已存项目是深层的，技术深度只是第一层。在其下还有第二层：混乱、缺失的意义，以及没有共享语言来解决这一切。这就是模型陷入的层。模型不是需要升级的部分。代码尚未准备好，而准备工作是我们可以逐步构建的。 一点一点地。让我来告诉你我是如何做到的。这比以前更容易了。# 在软件工程的开端，存在着唯一的技术债务。这是我们作为开发人员试图实现的自然结果。我们尚未准备好应对来自未来的商业决策，这些决策正在改变我们当前对代码的看法。我们需要快速交付，并且付出一些权衡。结果，代码气味越来越大。通常的回答是在清理方面花费工程预算的一部分：将10-20%的技术预算用于解决技术债务。在理论上……在下一个季度…… budget的五分之一是决定什么需要改变然后打字的费用，而这两个部分的价格从未相同。决定的成本保持大致不变。打字的费用却急剧下降。一个LLM将以一种不再类似2020年那样的成本完成清理的机械部分（提取模块、跨两个包的重构、更多的测试覆盖）。支付技术债务仍然需要时间。但它所花的时间少得多，而剩下的时间对我来说是决策部分。战略与战术# 我将工作分为两部分，并借用约翰·奥斯特豪特的《软件设计哲学》中的一些词汇，尽管我承认我在曲解它们。他用战术和战略形容编码时可以持有的两种态度：战术编程是在快速解决问题，而战略编程是在前行中投资于设计。我使用这对词来划分作者，因为上面的经济学是沿着这一线切割的。战略工作就是决策：阅读系统，弄清楚需要改变什么、为什么以及这个改变是否真的服务于功能。战术工作就是将这个决定带入文件。第一部分是需要在头脑中理解系统的部分。第二部分则变得便宜了。我的做法# 在第一部分我全力参与，而在第二部分我更像是一个审查者，而不是实施者。在第一条路径上，我以更通用的方式分析代码库，评估需要实施的变化及其与我想要交付的功能的对齐。这些方法的效果是我在每个代码库中创建的GitHub问题。这些问题随后由我的AI系统基于技能和子代理处理。技能是一个书面程序：一个markdown文件，当任务符合它时，模型会加载该指令文件，因此“解决一个问题”或“重新生成上下文图”每次都以相同的方式运行，而不是取决于我那天早上措辞的方式。子代理是一个独立的模型会话，拥有自己全新的上下文和自己狭窄的任务（实施、进行安全审查、对照规范审查），返回结果而不是将整个记录抛入我的记录中。当它们被实施后，PR就可以跳入。我会通过审查会话，接受变更或请求改进。我可以逐步进行，关心测试覆盖和谁出错：在变更落地之前，我需要知道系统的其他部分哪些在使用我正在更改的内容，以及这个变更是否是他们可以承受的。现在，作为一名软件工程师，我协调、规划并为改进创造路径。但在那个时候，我不需要自己实施。节省了时间。DDD作为基础# 这留给了战略的一半，其价值与写作的语言完全一样。这就是DDD发挥作用的地方。DDD一直是我选择的软件之一，能够在一年后仍然改变。埃里克·埃文的介绍提出了这种方法。