AI接管代码的时代如何保持主导？
不，这不是另一篇关于即将到来的AI末日或泡沫破裂的文章。我想你可以说我是软件中AI的倡导者，或者至少我接受它会留下来，无论我们喜欢与否。我亲眼目睹了AI如何彻底改变团队和产品的生产力。但我也看到了当长期盲目依赖它时可能造成的灾难性损害，无论是在我的团队中还是在我自己的日常实践中。我们的行业正在我们眼前迅速变化，看到这么多工程师只是梦游般地经历它，而他们的技能和代码库却在悄悄地退化，这让我深感担忧。
我承认在我的组织中大力推广AI。我们的利益相关者期望它，我的工程师期望它来培养未来所需的技能。但老实说，我担心3-5年后软件工程是什么样子，特别是对于初级工程师。我不想把头埋在沙子里，我想倡导随着AI变得更加强大和普及，我们如何保持对代码库的控制，更重要的是，保持我们神圣的技术技能。
1、AI的弊端
大多数AI内容都非常短视。当人们看到AI和代理工具能立即实现的影响时，都会变得兴奋——但他们没有看到的是，当使用数月后产生的副作用。当AI在没有合理人机协作的情况下用于交付任何"重大"变更时，都会产生一定程度的技术债务和知识债务。随着时间的推移，这种有毒的组合对我们代码库和工程技能都是一种毒药。
经历了所有这些负面影响后，这些是我推荐给使用AI的工程团队重新掌控方向盘的技术。
2、技能和思维方式
AI改变了SDLC（软件开发生命周期），最明显的是编码方面。Anthropic的AI SDLC图表很好地展示了这一点。
实际上我并不完全同意他们的图表——我仍然期望团队手动编码某些功能，SDLC的所有其他领域也被压缩了，只是程度较轻。然而，我确实同意这种压缩在过程中释放了一些空间——工程师利用这个空间专注于价值链上更高价值的领域，并培养未来所需的技能，这很重要，如果他们想在软件领域保持职业控制权。
那么，AI让我们能够更多关注的那些更高价值的领域是什么？过去，最好的工程师总是那些能够在技术深度和其他领域之间取得平衡的人，最重要的是领域知识。产品思维和这些其他技能是顶尖工程师做出最佳决策并为其产品制定最佳解决方案的关键，无论是否有AI。AI并没有改变这种平衡的价值；实际上它甚至提高了标准。
如果你是一个只想通过写代码来交付价值的开发者，那么也许是时候改变你的心态了。我个人不会再雇佣这类人了。
3、不要把你的思考委托出去
这是另一个我与许多人讨论过并自己也陷入过的陷阱。AI现在几乎可以做任何事情——但这并不意味着你应该用它来做所有事情！不要因为你能够就把所有思考都委托给AI，从而陷入困境。人类的判断力是我们与其他工程师或人区分开来的关键——它是使用AI时质量最重要的因素。
4、AI工程工作流
这些是我现在推荐在你的AI驱动工程工作流中使用的技术。
4.1 分解步骤
用AI一次性完成变更显然不是构建软件的可持续方法。将你的流程分解为单独的步骤很重要，原因有几个：
- 作为工程师，你可以在引导AI朝着你想要的方向方面发挥更积极的作用
- 你在每个步骤中更接近输入和输出，从而减少知识债务
- AI在执行特定角色和执行单一任务时表现要好得多——减少了幻觉和上下文腐化的风险
这些是我为基本代理工作流推荐的最小步骤。我特别推荐将规划和设计流程分开。
你可以在不要做巧合设计中了解更多关于我AI驱动设计方法的信息。
4.2 上下文是王道
要从AI获得最佳结果，重要的是将大部分精力放在前期构建上下文、规划、设计和原型制作上。这些过程的输出都应该被审查（由你和AI），并输入到你的AI实现过程中。这意味着在AI实际执行之前，你就已经对它将产生什么有了很好的了解，让你能够接近输出并按照你想要的方式驱动它。这种结构也意味着AI能够保持正轨，提供更高质量和更一致的代码。
这是我喜欢为每个重大变更设计的详细程度的示例，在实现任何代码之前。为你的代理工具提供一些全局上下文也很重要——这应该包括你的工程标准、架构原则、产品上下文和设计系统。
以这种方式使用AI进行工程开发，让你保持在驾驶座上并接近代码。
4.3 详细的实现计划
为你的实现步骤生成结构化计划是代理编码中最重要的一步。然而，AI编码平台内置计划模式生成的计划太高级了。我总是建议编写你自己的规划器（或使用AI帮助），它能生成带有实际代码片段的更详细的计划。
我倾向于创建一个分为不同阶段的高级计划，然后为每个阶段创建详细的实现计划。
StormSpace/.agent-context/tasks/board-timeline-replay-scrubber/plan.md at main ·…StormSpace是一个协作式交互式事件风暴Web应用程序。StormSpace允许多个用户……
是的，这需要更长的审查时间，但从长远来看会为你节省大量时间。现在我们在任何东西构建之前，就对实现会是什么样子有了很好的了解。我们获得更一致的结果，并且更紧密地融入代码库。通过AI第一次就精确地产生你想要的东西，消除了大量浪费的来回。如果计划看起来不对，就改变它或重新开始。
以这种方式使用AI构建也让我们能够使用强大的模型进行规划，然后使用更便宜的模型进行实现。如果我们使用内置计划混合使用这样的模型，我们就是在让较弱的模型来决定详细的代码实现，这是最重要的部分！
4.4 质询 → 共享理解
我们可以构建超级复杂的多步骤代理工作流，具有令人难以置信的上下文工程原则和审查关卡。但归根结底，我们是人类，我们是懒惰的。在许多团队推出这些流程后，我痛苦地了解到人们最终会开始松懈审查。人工审查现在是流程中最重要的部分。但在这个新的AI时代，我们比以往任何时候都做更多的审查，坦率地说，这既令人疲惫又不太有趣。
我第一次听说Matt Pocock的**/grill-me**技能是作为改进规划的一种方式。
The /grill-me Skill在承诺之前就一个想法达成一致。
这是一个简单的技能，它无情地采访用户，直到用户和代理达成"共享理解"。它非常适合揭示隐藏的约束，并迫使用户以不同的方式思考。这也是引导用户完成计划、设计或实施并确保他们真正理解关键细节的好方法。
我现在在我的几乎所有代理工作流步骤中都内置了类似的质询阶段。将其纳入流程的好处是双重的：
- 通过从用户那里获得更多的方向和判断来提高质量
- 让用户参与流程并突出最重要的领域
4.5 领域驱动设计
长期以来，我一直非常喜欢DDD（领域驱动设计），并在许多项目中使用它。这是一个巨大的话题，但许多概念在使用AI时极其重要。
DDD要求将代码尽可能贴近实际业务问题进行建模。这意味着用利益相关者能理解的业务术语命名类和方法。它还提倡在领域实体中封装尽可能多的业务逻辑，这对单元测试也很有好处。
要正确执行DDD，工程师需要更接近他们构建的业务，并深入理解领域，以便能够尽可能贴近地建模代码。这就是为什么它与AI如此契合：工程师在AI时代取得成功所能发展的最佳技能就是更好的领域知识！
使用DDD时，代码库的核心/领域层绝对至关重要。它应该封装你的关键业务规则，并对领域核心的行为和关系建模。它应该被很好地理解并进行良好的单元测试。
使用DDD与AI使我们能够通过将输入和审查集中在代码库最重要的部分——领域/核心——来保持控制。如果使用DDD，我实际上可以对代码的其他一些领域快速灵活地处理，除了安全方面，只要有良好的自动化测试。
4.6 事件风暴
使用DDD设计一个可靠的领域需要大量的思考和努力。AI"可以"做得相当好；然而，这是我更喜欢完全控制的一个方面。事件风暴是我推荐的用于思考你的领域的方法。
事件风暴是一种协作白板流程，可用于对复杂领域建模。它首先关注分解系统中所有可能的事件，最后通过工作数据模型来适配。通常作为工程师，我们直接跳到数据模型；首先从事件思考通常会导致更好的设计。
当有实际的业务专家参与并使用与你建模的领域一致的术语时，事件风暴效果最好。这使我们的工程师更接近业务，这是工程师在AI时代做出良好决策最有价值的知识领域之一。
一旦你的事件风暴板完成，它为AI用于实现规划提供了完美的上下文——无论是作为markdown导出还是图像。
4.7 严格的自动化测试
使用AI时，自动化测试变得比以往任何时候都重要。现代代理擅长使用自动化测试验证自己的工作并自动修复问题。严格的自动化测试原则和框架让你能够严格控制AI产生的代码质量，并确保没有历史代码被破坏。
这些是我推荐在实现阶段运行的测试类别，以保持代理正常运行：
这是你应该瞄准的最低标准，以强制通过你的代理工作流获得高质量。如果你想真正突破极限，那么你也可以加入一些漏洞测试和变异测试。
随着代理在基于浏览器的工作流方面变得更好，我还开始看到更多团队在构建新功能时使用AI进行临时探索性测试。这是非确定性的，可能会变得相当昂贵，但它也可以非常强大。
5、学习和发展
5.1 手动学习编码
尽管行业正在转向更少的手动编码，但学习手动编写代码仍然绝对重要；不幸的是，如果你想成为一个体面的软件工程师，就没有捷径可走。手动编写和犯错误是我们学习的方式，也是我们建立充分利用AI所需的技术判断力的方式。
5.2 AI需要更多技能，而不是更少
高级工程师是那些从AI中获益最多的人，这不是秘密。这是因为他们发展了广泛的技能，使他们能够在多种类型的工作中发挥主动性。
AI提供的杠杆作用使工程师能够在职业生涯早期就处理更复杂的变化——这需要更多的知识和技能来保持控制并构建可持续的软件。如果你想被信任从事这类工作，那么你需要在职业生涯早期就发展对软件工程更高级领域的理解：安全、架构、测试原则、整洁代码、DevOps、云基础设施、性能等。这些领域你根本不能出错。你需要有判断力能够分辨AI何时出错，否则可能会造成严重损害。
这些是工程师以前可能需要10年才能积累的技能。我现在看到一些刚从大学毕业、只有几年经验的工程师就在这些领域工作。
5.3 亲自动手
如果你想成为一名优秀的工程师，那么只在工作中学习是不够的，特别是如果你整天只是与LLM对话。
在工作之外尝试实验和业余项目。有些用AI，有些不用。找出什么有效。更重要的是，找出什么无效！
YouTube上显然有很多精彩的内容。但高级主题的最佳内容通常在书籍中——编程和架构的法律50年来并没有真正改变。有时书籍可能有点枯燥，但我保证这是值得的——这里是我的一些建议：软件工程领导者最佳书籍。
6、保持主导地位
AI利用你的知识，让你尝试远超你通常技能水平的工作。学会使用它现在是现代软件工程师的一部分。我在整个工作中都使用它，我期望我的团队也这样做。
但没有判断力的杠杆是危险的！不要委托那些构建你的技能、你对代码库的理解和你的所有权感的思考。使用AI来加快速度，但要对方向和目的地负责。
6.1 技术债务
根据长期监督许多团队使用AI的经验，我可以自信地告诉你，即使使用最好的代理工具，AI也会快速产生技术债务。AI生成的代码通常比精心手工编写的代码更冗长，并且可能无法重用现有代码，导致重复和不一致的模式。氛围编码倡导者会告诉你，这可以通过更好的上下文工程或循环工程来解决——我告诉你这并不总是正确的。
随着模型变得越来越强大，我越来越多地看到的另一个问题是代理将简单问题的解决方案复杂化。我第一次真正注意到这一点是在使用GPT-5.6 Sol时。Sol非常强大，但如果你不知道自己在做什么，特别是当推理努力程度被调高时，你可能会对代码库造成严重破坏！事实上，卓越工程师最重要的特质之一就是能够为复杂问题制定简单的解决方案。
6.2 知识债务
就个人而言，这更让我担心。在过去手动编写代码的时代，工程师必须深入思考、研究、运行探索、犯错误并经历几次不同的迭代才能把事情做对。这个过程缓慢而费力，但它对学习绝对关键。对于学习新技术，更重要的是学习什么行不通。这些经验和教训锻造了伟大的工程师。如果你没有花时间彻底理解AI产生的内容，并分析可能采取的不同方法，那么你就是在阻碍自己作为工程师的成长。
这些经验对于工程师能够对AI输出应用判断并以正确的方式指导它也至关重要。没有这些教训和战斗伤疤，我们与任何其他使用AI的人没有什么不同。
6.3 与代码库的距离
随着技术和知识债务的堆积，我们与代码库的距离越来越远。我们现在对代码的架构了解得更少了。我还发现工程师现在对代码也不那么关心了，这是一个危险的境地；代码混乱，工程师感觉所有权减少。这种可怕的组合只是进一步加速了通过审查过程允许的低质量代码的速率。
6.4 过度杠杆
AI的主要直接危险是它利用你的知识，让你可以尝试通常远超你技能水平的工作。如果你还长期积累了知识债务，那么这是一个极其危险的境地！
我在金融行业工作，在一个领域复杂性特别高的领域。已经有很多例子表明，初级工程师使用AI来处理他们还没有准备好的功能。通常情况是这样的：
这类问题已经对我的一些产品和团队造成了重大的声誉损害。我们还有一些数据损坏的情况，需要付出巨大的努力来修复。
我不打算等到更大的灾难发生。
原文链接：How to Stay in the Driver's Seat as AI Agents Take Over Coding
汇智网翻译整理，转载请标明出处