异步编程的兴起改变了开发者的工作方式，从逐行编写代码转向清晰描述问题并让工具在后台解决。这种新型异步编程强调明确问题定义、委托实施（如使用AI代理或团队成员）以及后续审查反馈，与传统编程的即时反馈循环不同，更注重基于清晰需求的背景问题解决。

异步编程的兴起

2025年8月19日，Ankur Goyal

我花费大量时间审查非我编写的代码。一个AI代理接收详细的问题描述，编写代码（主要是Typescript、Rust和Python），添加测试，并将更改提交到分支。当一切准备就绪时，我再进行审查。

这曾经像是一个未来主义的场景，但现在这是我的工作方式，也是许多开发者开始采用的方式。这种转变虽然微妙但强大：我们不再逐行编写代码，而是学习清晰地描述问题，并让工具在后台解决它们。

这种“异步编程”与经典定义不同，它关注的是开发者如何构建软件。

工作流程如下：

1. 明确问题定义：详细描述需要构建的内容，包括边缘情况、约束和成功标准。
2. 移交任务：将实现委托给AI代理、团队成员或未来的自己，并附上详细的笔记。
3. 稍后返回：回来审查结果，提供反馈，并决定下一步。

与传统编程的关键区别在于问题定义和实现之间的时间分离。你不再依赖即时反馈循环，而是通过清晰的驱动需求和自动化验证在后台解决问题。

异步编程不是“氛围编码”。氛围编码让你无需深入细节即可编写代码。异步编程是一种工作流程，使开发者能够同时解决更复杂的问题，同时仍然理解所编写代码的细节。你仍在设计解决方案、审查实现并维护代码库，只是不再亲自输入大部分字符。

要使异步编程在实践中有效，你需要三件事：明确的问题定义、自动验证结果的方法以及人工代码审查。

1. 明确的问题定义

问题陈述的质量决定一切。模糊的需求产生模糊的结果，精确的规范产生可运行的代码。

模糊：“让搜索更快”

精确：“我的目标是将搜索延迟从约800毫秒减少到约200毫秒。我怀疑根本原因是我在每批行上进行的堆分配。你能尝试将分配重构为每次搜索只进行一次，并测量影响吗？”

精确版本包括当前状态、目标结果、建议方法和验收标准。AI代理（或人类队友）可以独立工作，因为需求明确。

有效的异步编程规范像技术文档：包括上下文、约束、示例和明确的成功标准。如果你不能清楚地解释问题，你可能没有足够理解它来委托它。

2. 自动验证

异步编程只有在无需手动测试每个边缘情况即可验证结果时才有效。你需要能够自动检查工作的系统。

这可能包括：

• 单元和集成测试，验证核心功能
• 类型检查，捕捉接口不匹配
• 性能基准，确保代码满足速度要求
• 代码风格检查，强制执行风格指南

目标是开发一个代理可以独立验证其工作的过程。这需要时间。你最初会提供大量指导，然后开发允许代理自主工作的模式。在CI中设置这一点具有挑战性，但使后台代理能够在开发环境之外执行工作。

3. 详细的代码审查

一旦你不亲自输入每个字符，代码审查就变得至关重要。我经常发现PR解决了完全错误的问题，做出了糟糕的设计决策，或存在大量代码重复。

审查AI生成的代码是有价值的，类似于传统的代码审查。预计在代码审查上花费的时间比以前多得多。

代码可能不是你逐行编写的，但系统设计和技术决策仍应反映你的判断。

自从采用异步编程以来，我的工作流程发生了变化。我现在同时处理四到五个任务：一个复杂问题同步处理，三到四个在后台处理。当我切换上下文时，我会审查每个后台任务的进行中的工作，提供指导，然后返回同步工作或代码审查。

我们一直在使用异步编程来构建Braintrust本身，现在我们正在构建工具，将这些想法转化为AI工程。

传统的提示工程是手动的。你编写提示，针对示例进行测试，观察失败，进行小的调整，然后重复。这个过程需要专业知识，但涉及大量迭代。

我们的代理Loop让你描述你试图解决的评估问题，并在后台分析实验结果，识别失败测试案例中的模式，并建议改进提示、数据集和评分器。

这种工作方式的影响仍在显现。这改变了我作为开发者的优化目标：更少的时间花在IDE快捷键和打字速度上，更多的时间花在清晰地解释问题和彻底审查解决方案上。

实现工作可以与其他思考并行进行。随着工具的改进，更多的开发者可能会采用这种方法。AI并没有取代编程，但编程中最有价值的部分变得更加突出，而常规任务则转移到后台。

评论主要围绕“异步编程”这一概念展开，观点多样且涉及多个方面。以下是总结：

1. 异步编程的实践与挑战：

   • 有评论者分享了与离岸团队合作的经验，指出异步工作流程在理想情况下效率高，但沟通不清晰时会导致问题，并可能积累技术债务。（评论1：“Worked amazingly when it worked. Really stretched things out when the devs misunderstood us...”）
   • 也有评论者认为，异步编程可能导致编程技能退化，因为长期不写代码会影响代码审查的能力。（评论4：“This works until you get to the point that your actual programming skills atrophy due to lack of use.”）

2. 问题定义的重要性：

   • 多位评论者强调，清晰定义问题是软件开发的关键，但现实中这一步往往被忽视或简化。（评论8：“The first step is 'define the problem clearly'. This would be incredibly useful for software development...”）
   • 有评论者指出，AI编程迫使开发者更关注功能与规范，而不是直接跳到编码阶段。（评论10：“With AI developers are forced to think about the functionality and the specs of their code...”）

3. 术语与概念的混淆：

   • 许多评论者对“异步编程”这一术语表示困惑，认为它与传统的异步编程（如Python中的async/await）不同，容易引起误解。（评论13：“Before I read the article I thought this meant programming with 'async'.”）
   • 有评论者建议使用更准确的术语，如“基于代理的编程”，以避免混淆。（评论21：“I don't know why we need to call it 'Async AI programming'...”）

4. 对AI编程的质疑与担忧：

   • 部分评论者对AI编程的实用性表示怀疑，认为它可能带来大量低质量代码，未来需要清理。（评论18：“When this bubble finally pops, someone is going to have to clean up all the nonsense AI code out there.”）
   • 也有评论者认为，AI编程可能剥夺编程的乐趣，尤其是解决小问题的满足感。（评论12：“For me, at least, solving the little problems are like little satisfying puzzles...”）

5. 个人偏好与工作方式：

   • 有评论者表示，他们更喜欢亲自编写代码，认为这是参与开发的重要部分，而AI生成代码则缺乏这种参与感。（评论19：“I actually like writing code... It's like actively participating in development when typing.”）
   • 也有评论者认为，异步编程可能适合某些人，但并不适合所有人。（评论16：“It's a sad future for me, but maybe a great one for some different personality type.”）

总结：评论者对异步编程的看法分歧较大，主要集中在其实践效果、问题定义的重要性、术语的混淆以及对AI编程的质疑等方面。尽管部分人认为异步编程能提高效率，但也有不少人对其可行性和对编程体验的影响表示担忧。