Agentic Code Quality Addy Osmani 2026-08-12 12.2 KB 425.6K 1.1K ☆ 收藏 𝕏 文章列表 本文探讨了在AI代理大规模生成代码的背景下，如何通过约束和验证机制（如质量门禁）来保证软件质量。作者认为，传统的代码审查方式已无法应对海量代码，因此需要将质量检查嵌入到代理的运行环境、工具链和操作系统中。文章详细介绍了多种约束形式，包括单元测试、属性测试、变异测试等，并讨论了自主性、信任、反馈循环和扩展性等关键问题。最后，作者强调人类注意力应集中在最复杂的问题上，而自动化检查应承担大部分质量保障工作。 AI代理代码质量质量门禁约束验证自动化测试代码审查软件工程生产就绪信任 76 值得读 ▶ 文章深入探讨了AI代理时代代码质量保障的范式转变，提出了以约束和反馈机制为核心的实用框架，观点新颖且时效性强，但具体操作细节略显不足。 # Agentic Code Quality **作者**: Addy Osmani **日期**: 2026-08-12T06:36:01.000Z **来源**: [https://x.com/addyosmani/status/2087427868343373919](https://x.com/addyosmani/status/2087427868343373919) ---  For much of human history, we've evaluated code quality via code review: someone reads what you wrote and makes sure it's clean, thoughtful, fast, understandable, and tests well. For agents, that approach doesn't scale well; there's just too much code for anyone to read. As a result, more and more of our quality checks have to happen in the harness, environment, and operating system around the agent. I still read and review code, but am very intentional about where I am comfortable with constraints as the check. Software quality now depends on the constraints you set around your agents.  Guillermo's list is a good test for whether you can afford to skip reading. Notice that every "yes" is really a statement about how low the stakes are - no users, throwaway code, prototype. Once the stakes go up, something has to read the code. If it isn't you on every diff then it has to be the constraints. Constraints define what the system is allowed to do by throwing tests and deterministic constraints at an agent's proposals. It's by setting and maintaining these constraints that we build loops that reliably deliver high-quality production software, even when agents are creating hundreds of thousands or millions of changes every single day.  We call these constraints quality gates, and they take many forms. They include conventional unit tests, property tests, and acceptance tests. They include mutation testing, where we generate variations of code, run it against the same tests, and make sure that people aren't sneaking bugs in that we're missing. They're metrics around code quality, such as cyclomatic complexity and line length, that help keep things readable.  Two people can disagree about whether to read the code and still agree on the mechanism. Guillermo reads it. Bob doesn't read any of it. Both are describing a gauntlet - the difference is only whether a human sits inside it (I don't endorse Bob's other views) Constraints also play an important role in what proposals the system will accept and apply as code changes. By the time a change proposal moves from the interpreter running the agent to the agent controller and out to production, we've done enough checks on it to be confident that it's safe to ship and the impact of its change is well within the scope of the agent. An agent can propose anything. Your constraints decide whether a proposal is safe enough, correct, scoped, and useful, for you and your team to ship. This model offers a lot, but also leaves out many pieces, and those omissions are worth thinking about today. One issue is autonomy; agents might apply their intentions well, but may fail when there's missing information or when what they try to do is ambiguous. That applies both to the task itself and to how it's parameterized by the harness, environment, and other components. Many of the reasons that humans fail to ship great code are shared with what agents might do: brittle environments that don't hold up under script-driven stress, nondeterministic builds, missing permissions, and weak tests. This motivates a better environment that gives agents trustworthy feedback, allows for low-damage failure modes, and makes it easier to progressively build up success.  The environment we’re after is one where an agent can do real work, get feedback it can trust, and fail without doing much damage. The other important issue is trust. We can’t credulously hand off intent to something even as smart and robust as a modern agent without checking for correctness. We start with trust, but it has to be hard-earned.  Some constraints shape work before it begins. Others give feedback while the agent is working. Others decide whether its output can cross the production boundary at all. There are a bunch of ways to model how we put a verification structure around a system. In my experience it helps to have a broader, but intentionally chosen, set of checks for your constraints instead of solely relying on unit tests. The idea is that each check has a distinct responsibility and that can range from type safety and performance to late-stage security scanning. Folks can define their own constraints too, including architecture rules that linting tools like ESLint can enforce. Many of these tools have built-in hooks that can be used to pull in agents, or humans, when things break. For now, much of the difference between useful agent output and slop still comes down to the skill of the team operating the loop. AI gives us high volume code generation and velocity, but this can also mean it gets harder for humans to review every single change. You have to instead be intentional with where their attention is going. If you put a human check into a system that otherwise moves at machine speed, don't be surprised if that impacts productivity. Human attention is scarce and valuable so we should proactively direct it to those most nuanced problems that require our judgment. Downstream humans should only be pulled in when the automated guardrails for constraints break. Human “code review” in the future is going to look very different Correctness is one important dimension, but you may care about others as well, like maintainability, performance, security, efficiency, and comprehensibility. Just as correctness decomposes into many signal types, so does the rest of quality. And while it matters how many constraints we have in place, it matters more whether they’re challenging enough to meet our bar for quality and production readiness. Software quality isn't a single metric. Think of it as a collection of signals of varying importance to you and your team. Back-pressure can be implemented through many tools: compilers rejecting invalid code, tests failing, security policies blocking bad practices, CI declining to deploy. Ideally it exists throughout the loop, not as a single review at the very end of all the work.  Dex Horthy's map of the same loop, from Why Software Factories Fail. The green box is his argument that atm the human review belongs back in the loop rather than replaced by it. Constraints and back-pressure let agents catch bad work before its a problem What happens if we can't apply the constraint because the volume of changes is higher than our tools can consume? We end up building a queue and relying on a verification system that moves at human speed. To scale, we want to push as much as we can into the verification loop throughout and not wait until the end. If we can scale within our automated checks, we can increase the speed and throughput of our entire delivery system. If we run out of room in the verification loop, we need to do one of several things. First, we can scale our verification system and create more capacity to constrain and push back on changes that come in. Second, we can reduce the rate at which agents generate new changes so that verification can catch up to the volume of work. Third, we can lower our quality bar so that verification doesn’t push back as hard as it otherwise might. From a scaling perspective, we need to be ready to do all of these things. At the same time, we should not stop short of realizing that we could actually get more done by un-constraining in some directions. Maybe we can increase the speed of agent-generated changes by providing swarms of agent developers or automated software factories to create changes without waiting for us to review each of them. And in some places we might want to give them more freedom as long as we keep tighter constraints in others. By providing tighter constraints where we care the most, we can maximize our throughput without sacrificing quality. Throughout these decisions there are many options. Most obviously, we have to trade between different dimensions of quality. As we've emphasized, security is very important, but we’ve also had to trade between delivering security and delivering a product on time. There is a spectrum from innovation-focused at one end to quality-focused at the other. Somewhere along the way, we have to make choices about where we want to be on that spectrum. We want to send clear feedback from the environment and the system back to our agents or teams, so that people can focus on the more subjective concerns of taste, intent, and architecture. If we can help humans stay inside the safe range of constraints, we can avoid the need for them to work hard trying to figure out where things went wrong. Software quality includes more than just correctness. Software quality also means maintainability, good performance, security, efficiency, and being easy to understand. All the constraints that help us meet these standards and keep our production flowing create back-pressure in our delivery pipeline. We need to make deliberate decisions about where to apply strong constraints and where to remove or relax them. Apply strong constraints where they’re serving both of these goals. Don’t support them if they’re not serving one or both. Be ready to raise or lower standards as the case may require. And remember these constraints at different points in the software system are what make software quality enforceable. We should apply strong constraints where they'll serve this dual purpose best and consider removing or relaxing constraints that aren’t serving either purpose well. We should also be ready to shift quality bars up or down as needed. In effect, these constraints at various points in our software system are what give quality its teeth. In many cases, we can create more back-pressure and more constraints by deploying new tools or strengthening tools that are already in place. All of these things can be used to push back on most change requests. We want to build them throughout the pipeline. We don't want to wait until the end of the pipeline when our CI system will simply tell us that we’re not allowed to deploy without fixing problems. We want to use these signals as early as we possibly can, through every possible pathway. The ultimate constraint in this system is the one we place on ourselves to stand behind the decisions and actions we’ve taken to build the system and to operate it. But like all other constraints, we need to make thoughtful trade-offs about how much we want our own judgment to restrain, to back-pressure, and to act as a final check. Quality is in the constraints that we place around our agents. So as you're thinking about quality for your own apps, take this problem statement and come up with your own constraint-driven plan.  Speaking of quality, agents are writing your code. [Sonar](https://fandf.co/45bRKE8) gives you the quality gates to make it shippable. It runs the same complete check on every commit: deep cross-file analysis, a map of where the risk lives, and a quality gate that holds every human and agent to one bar. This article was rated [100% human written](https://www.pangram.com/history/f22fddf2-93c3-4b2e-a3a5-d660cfd9e5b0?ucc=WTDC1pMZmd3) by Pangram 4. ## 相关链接 - [Addy Osmani](https://x.com/addyosmani) - [@addyosmani](https://x.com/addyosmani) - [8.3K](https://x.com/addyosmani/status/2087427868343373919/analytics) - [Sonar](https://fandf.co/45bRKE8) - [100% human written](https://www.pangram.com/history/f22fddf2-93c3-4b2e-a3a5-d660cfd9e5b0?ucc=WTDC1pMZmd3) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:36 PM · Aug 12, 2026](https://x.com/addyosmani/status/2087427868343373919) - [8,344 Views](https://x.com/addyosmani/status/2087427868343373919/analytics) - [View quotes](https://x.com/addyosmani/status/2087427868343373919/quotes) --- *导出时间: 2026/8/12 15:11:15* --- ## 中文翻译 # 智能体代码质量 **作者**: Addy Osmani **日期**: 2026-08-12T06:36:01.000Z **来源**: [https://x.com/addyosmani/status/2087427868343373919](https://x.com/addyosmani/status/2087427868343373919) ---  在人类历史的大部分时间里，我们通过代码审查来评估代码质量：有人阅读你写的代码，确保它干净、深思熟虑、快速、易于理解且测试良好。对于智能体来说，这种方法难以扩展；代码量太大，任何人都无法全部阅读。因此，越来越多的质量检查必须在智能体周围的框架、环境和操作系统中进行。我仍然会阅读和审查代码，但对于在哪些地方可以接受用约束作为检查手段，我会非常谨慎。 软件质量现在取决于你为智能体设置的约束。  Guillermo的清单是一个很好的测试，可以判断你是否能承受跳过阅读的后果。注意，每个“是”实际上都是在说明风险有多低——没有用户、一次性代码、原型。一旦风险升高，就必须有人阅读代码。如果不是你在每次差异（diff）上阅读，那么就必须靠约束来把关。 约束通过向智能体的提议抛出测试和确定性约束，来定义系统被允许做什么。正是通过设置和维护这些约束，我们才能构建出能够可靠交付高质量生产软件的循环，即使智能体每天产生成千上万甚至数百万次更改。  我们称这些约束为质量门禁（quality gates），它们有多种形式。 它们包括传统的单元测试、属性测试和验收测试。它们还包括变异测试（mutation testing），即我们生成代码的变体，用相同的测试运行它们，确保没有人偷偷引入我们遗漏的缺陷。它们还包括围绕代码质量的指标，如圈复杂度和行长度，这些指标有助于保持代码的可读性。  两个人可以就是否阅读代码持不同意见，但仍然在机制上达成一致。Guillermo会阅读代码。Bob完全不阅读。两者描述的都是一道关卡——区别只在于是否有人类身处其中（我不赞同Bob的其他观点）。 约束在系统接受哪些提议并将其作为代码更改应用方面也扮演着重要角色。当一个更改提议从运行智能体的解释器移动到智能体控制器，再到生产环境时，我们已经对其进行了足够的检查，确信它可以安全发布，并且其更改的影响完全在智能体的职责范围内。 智能体可以提出任何建议。你的约束决定了一个提议对你和你的团队来说是否足够安全、正确、范围明确且有用，从而决定是否可以发布。 这种模式提供了很多优势，但也遗漏了许多部分，这些遗漏值得我们现在思考。一个问题是自主性；智能体可能很好地执行它们的意图，但在信息缺失或它们试图做的事情含糊不清时，可能会失败。这既适用于任务本身，也适用于任务如何被框架、环境和其他组件参数化。 人类无法交付优秀代码的许多原因，智能体也可能遇到：在脚本驱动的压力下无法保持稳定的脆弱环境、不确定的构建、缺失的权限以及薄弱的测试。这促使我们建立一个更好的环境，为智能体提供可信的反馈，允许低损害的失败模式，并使其更容易逐步构建成功。  我们追求的环境是：智能体可以在其中做真正的工作，获得它可以信任的反馈，并且在不造成太大损害的情况下失败。 另一个重要问题是信任。我们不能轻信地将意图交给即使是像现代智能体这样聪明和健壮的东西，而不检查其正确性。我们从信任开始，但它必须是来之不易的。  一些约束在工作开始之前就塑造了工作。另一些则在智能体工作时提供反馈。还有一些决定其输出是否能够跨越生产边界。 有很多方法可以建模我们如何围绕系统构建验证结构。 根据我的经验，为你的约束设置一套更广泛但有意识选择的检查是有帮助的，而不是仅仅依赖单元测试。这个想法是每个检查都有不同的职责，范围可以从类型安全和性能到后期安全扫描。人们也可以定义自己的约束，包括ESLint等代码检查工具可以执行的架构规则。许多这些工具都有内置的钩子，可以在出现问题时引入智能体或人类。 目前，有用的智能体输出和垃圾输出之间的差异，很大程度上仍然取决于操作这个循环的团队的技能。 AI为我们带来了高容量的代码生成和速度，但这也可能意味着人类审查每一个更改变得更加困难。相反，你必须有意地引导他们的注意力去向。如果你在一个以机器速度运行的系统里加入人工检查，不要惊讶于这会影响生产力。人类的注意力是稀缺且宝贵的，所以我们应该主动将其引导到那些需要我们判断力的最细微的问题上。只有当自动化护栏失效时，才应该引入下游的人类。 未来人类的“代码审查”将会大不相同。 正确性是一个重要的维度，但你可能还关心其他方面，如可维护性、性能、安全性、效率和可理解性。正如正确性分解为许多信号类型一样，质量的其他方面也是如此。虽然我们设置了多少约束很重要，但更重要的是这些约束是否足够具有挑战性，以达到我们对质量和生产就绪的标准。 软件质量不是一个单一的指标。把它看作是一系列对你和你的团队具有不同重要性的信号。 背压（Back-pressure）可以通过许多工具来实现：编译器拒绝无效代码、测试失败、安全策略阻止不良实践、CI拒绝部署。理想情况下，它应该存在于整个循环中，而不是在所有工作结束时的一次审查。  Dex Horthy对同一循环的映射，来自《为什么软件工厂会失败》。绿色框是他认为人工审查应该回到循环中，而不是被其取代。 约束和背压让智能体在问题成为问题之前就捕捉到糟糕的工作。 如果因为更改量超过了我们工具的处理能力而无法应用约束，会发生什么？我们最终会建立一个队列，并依赖一个以人类速度运行的验证系统。为了扩展，我们希望尽可能多地将内容推入整个验证循环中，而不是等到最后。如果我们能在自动化检查中扩展，我们就能提高整个交付系统的速度和吞吐量。如果验证循环空间不足，我们需要做以下几件事之一。 首先，我们可以扩展验证系统，创造更多能力来约束和推回传入的更改。其次，我们可以降低智能体生成新更改的速度，以便验证能够跟上工作量。第三，我们可以降低质量门槛，这样验证就不会像原本那样强烈地推回。从扩展的角度来看，我们需要准备好做所有这些事情。同时，我们也不应忽视这样一个事实：在某些方向上解除约束，我们实际上可以完成更多工作。也许我们可以通过提供智能体开发者群组或自动化软件工厂来创建更改，而无需等待我们逐一审查，从而提高智能体生成更改的速度。 在某些地方，我们可能想给予它们更多自由，只要我们在其他地方保持更严格的约束。通过在我们最关心的地方提供更严格的约束，我们可以在不牺牲质量的情况下最大化吞吐量。在这些决策中，有很多选择。最明显的是，我们必须在质量的不同维度之间进行权衡。正如我们所强调的，安全性非常重要，但我们也必须在交付安全性和按时交付产品之间进行权衡。从以创新为重点的一端到以质量为重点的另一端，这是一个光谱。在某个点上，我们必须决定我们想在这个光谱上处于什么位置。 我们希望将环境和系统的清晰反馈发送回我们的智能体或团队，以便人们能够专注于品味、意图和架构等更主观的问题。如果我们能帮助人类保持在约束的安全范围内，我们就能避免他们费力去弄清楚哪里出了问题。 软件质量不仅仅包括正确性。软件质量还意味着可维护性、良好的性能、安全性、效率以及易于理解。所有帮助我们达到这些标准并保持生产流程顺畅的约束，都会在我们的交付管道中产生背压。 我们需要就哪里应用强约束、哪里移除或放宽约束做出深思熟虑的决定。在服务于这两个目标的地方应用强约束。如果它们不能服务于其中一个或两个目标，就不要支持它们。准备好根据情况需要提高或降低标准。并记住，软件系统中不同点的这些约束正是使软件质量可强制执行的原因。 我们应该在能最好地服务于这一双重目的的地方应用强约束，并考虑移除或放宽那些不能很好地服务于任一目的的约束。我们还应该准备好根据需要上下调整质量门槛。实际上，我们软件系统中各个点的这些约束正是赋予质量以牙齿的东西。在许多情况下，我们可以通过部署新工具或加强现有工具来创造更多的背压和约束。所有这些都可以用来推回大多数更改请求。我们希望在管道中构建它们。 我们不希望等到管道末端，那时我们的CI系统只会告诉我们，在不修复问题的情况下不允许部署。我们希望尽可能早地通过这些可能的途径使用这些信号。这个系统中最终的约束是我们对自己施加的约束，即为我们构建和运营系统所做的决策和行动负责。但像所有其他约束一样，我们需要对我们希望自己的判断在多大程度上进行约束、产生背压并作为最终检查做出深思熟虑的权衡。 质量在于我们为智能体设置的约束。因此，当你为自己的应用考虑质量时，请带着这个问题陈述，制定你自己的约束驱动计划。  说到质量，智能体正在编写你的代码。[Sonar](https://fandf.co/45bRKE8) 为你提供质量门禁，使其可发布。它在每次提交时运行相同的完整检查：深入的跨文件分析、风险所在位置的映射，以及一个让每个人类和智能体都达到同一标准的质量门禁。 这篇文章被Pangram 4评为[100%人类撰写](https://www.pangram.com/history/f22fddf2-93c3-4b2e-a3a5-d660cfd9e5b0?ucc=WTDC1pMZmd3)。 ## 相关链接 - [Addy Osmani](https://x.com/addyosmani) - [@addyosmani](https://x.com/addyosmani) - [8.3K](https://x.com/addyosmani/status/2087427868343373919/analytics) - [Sonar](https://fandf.co/45bRKE8) - [100% human written](https://www.pangram.com/history/f22fddf2-93c3-4b2e-a3a5-d660cfd9e5b0?ucc=WTDC1pMZmd3) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [2:36 PM · Aug 12, 2026](https://x.com/addyosmani/status/2087427868343373919) - [8,344 Views](https://x.com/addyosmani/status/2087427868343373919/analytics) - [View quotes](https://x.com/addyosmani/status/2087427868343373919/quotes) --- *导出时间: 2026/8/12 15:11:15*
B Building software factories (with no slop) 本文探讨了AI生成代码带来的代码审查瓶颈和'AI垃圾'问题。作者认为，随着AI编码能力增强，人类审查速度成为瓶颈，导致代码质量下降。他提出解决方案：将代码库视为黑盒，通过定义清晰的接口、不变量、追踪和决策记录等'工件'来确保系统可检查性，而无需阅读实现代码。作者强调软件工程的核心是解决问题而非编写代码，未来工程师的职责是设计人与AI协作的系统。 技术 › LLM David 2026-08-20 AI编码代码审查软件工程黑盒可解释性AI垃圾工程实践Claude代码质量开发流程
每 每个 Agent 都需要的计算机使用验证技能 本文介绍了如何向 Agent 添加计算机和浏览器使用能力，以重现问题、验证修复和新功能。文章详细说明了在分类、实施和审查阶段利用计算机进行验证的价值，包括自动生成截图和视频以减轻代码审查负担，以及通过云代理并行运行以提高效率。 技术 › Agent Zach Lloyd 2026-08-04 Agent计算机使用自动化测试代码审查Warp技能验证Cloud Agents
大 大规模代理开发验证：Devin 的端到端测试实践 本文介绍了 Devin 在构建端到端云测试能力方面的经验。通过增强计算机使用能力，Devin 能够自主验证代码变更，通过生成基于代码的测试计划、使用确定性脚本以及多模型路由，显著提高了异步软件工程中的测试可靠性和效率。 技术 › Agent Ido Pesok 2026-05-30 Devin自动化测试端到端测试Agent软件工程测试验证云原生代码审查
T The AI Agent Complexity Ratchet: Why 90% Test Coverage Is Required 文章探讨了 AI 编程代理（Agent）如何改变软件开发的范式。作者通过 GStack 和 GBrain 两个开源项目的经验，指出 AI 使得同时实现高速度和高质量成为可能。核心在于构建“复杂度棘轮”：即 90% 的测试覆盖率。AI 代理能伴随代码编写测试、文档和评估结果，确保每次迭代都建立在质量底线之上，防止退化，从而实现只能变好不能变坏的“单向运动”开发模式。 技术 › Agent Garry Tan 2026-05-12 AI编程测试覆盖率ClaudeCodex软件工程开发效率代码质量自动化测试
H How I work with Agents Thorsten Ball 分享了 2026 年 10 月他与 AI Agent 协作的工作方法：使用最新最强的模型，不必担心代码库积累 slop；提示时描述 What 而非 How；让 agent 贯通整个软件开发生命周期（运行、部署、看日志、处理 bug 报告），并为其提供定制工具；通过盲测实验评估 agent 对代码库知识的利用；不要手动管理上下文，让 compaction 工作；请求不可反驳的证明（端到端演示、前后对比数据）；拥抱异步工作流，给 agent 更大任务；利用定时唤醒等自动化功能；只审查高影响范围的代码。这些实践展示了 agent 驱动开发的新范式。 技术 › Agent Thorsten Ball 2026-10-27 AI AgentLLM编程实践工作流软件工程Amp自动化代码审查AGENTS.md异步协作
A AI 没有智慧，你也不会有了 文章批评'不再读代码、不再写代码'的行业风气。作者指出代码可维护性和好架构难以即时度量，其恶果需要数月甚至数年才显现，而有经验工程师依靠长期实践积累的直觉来嗅出代码异味。AI 因缺乏可度量的奖励信号，无法理解什么是可维护的代码，且从质量低劣的野生代码中学习模式，在简化代码、定义可复用函数上表现糟糕。更危险的是，依赖 AI 写代码和读代码的开发者将永远无法达到精通，因为他们不再从错误中学习。作者认为 LLM 只是工具，预言未来会有公司以'无 AI'政策作为竞争优势。 技术 › LLM Alexandru Nedelcu 2026-09-22 AI编程代码可维护性软件工程LLM工程文化Dreyfus模型代码审查观点
让 让 Codex 与 Claude Code 联手分析 Codex 开源仓库：能学到什么 文章分析了 John Wang 对 OpenAI Codex 开源仓库的研究。Codex 从 2025 年 5 月的 98 个月提交、单一主作者，增长到 2026 年的 900+ 月提交、35 位常规贡献者，归因于大量使用 coding agent、团队扩招和对护栏规则的重投资。核心经验包括：AGENTS.md 把 review 踩过的坑编码成规则；规则按 Review → AGENTS.md → Lint/CI 三级演进；测试代码占 40%，分层执行保证速度；迁移通过 feature flag 推进并用 lint 锁定成果。结论是工程实现变便宜后，测试、边界、自动化和招人等经典工程要素反而更重要。 技术 › Harness Engineering meng shao 2026-09-04 CodexAgentAGENTS.md开源仓库工程实践代码质量自动化测试LintCIClaude Code
智 智能体工程模式：代码免费时代的软件工程实践 本文解读 Simon Willison 的《Agentic Engineering Patterns》，系统总结编码 Agent 时代的软件工程方法论。核心观点：当写代码边际成本趋零，工程师职责转向为 Agent 配备工具、定义问题、验证结果。文章区分了 agentic engineering 与 vibe coding，提出囤积已验证方案、用异步 Agent 清理技术债、子 Agent 保护上下文、Red/Green TDD 与证据式测试等模式，并强调提交未审查代码是最大反模式，以及通过走读和交互式解释偿还认知债。 技术 › Agent meng shao 2026-08-30 AgentSimon WillisonClaude CodeCodex软件工程TDDPrompt工程认知债代码质量
R Running a Software Factory Efficiently at Uber Scale 本文介绍 Uber 如何在软件开发生命周期中高效运行 AI 软件工厂。目前 Uber 超过 70% 的 PR 由本地或云端 agent 完成，工程师构建了 3600+ 个 agent 技能，每天执行超 3 万次。文章提出软件工厂的四层 agent 使用架构，并将成本分解为六个可独立测量和优化的因子。通过基于真实工作构建的基准测试进行 Pareto 最优的模型选择、将子 agent 默认路由到更经济的模型、自动上下文压缩等优化手段，Uber 在模型不变的情况下将每千次请求成本降低约 34%，单会话成本较峰值下降 52%，实现了规模化的 AI 工程效率与成本控制。 技术 › Agent Uber Engineering 2026-08-29 UberAI编程Agent成本优化模型选择软件工程CI/CD代码审查
3 3 Secret Ways Claude Code’s Creator Actually Uses It 本文探讨了Claude Code的创建者Boris Cherny关于如何更有效使用AI代理的建议。作者发现，随着模型升级（如Opus 5），旧有的指令和技能可能反而阻碍新模型的表现。Boris建议定期删除或禁用CLAUDE.md、技能和钩子，以发现模型的新能力。作者通过对比测试发现，保留上下文但简化流程，让模型自主思考，效果更好。文章强调将上下文与程序分离，给出高层目标、护栏和退出标准，并让代理自我验证。最终，管理AI代理应像管理有能力的人一样，设定方向、审查结果，而非微观管理。 技术 › Claude Nate Herk 2026-08-13 Claude CodeAI代理提示工程模型管理技能优化上下文管理验证产品过时Opus 5工作流程
A AI代理让每个人都成为管理者：如何有效监督它们 本文探讨了AI代理普及后，人类从执行者转变为监督者的现象。作者指出，当执行成本降低，监督成为新的瓶颈，并提出了一个包含委派契约和监督循环的框架。委派契约包括成果、上下文、决策权和验证四部分，监督循环则包括派遣、检查点、验证、升级和记录五步。文章引用了OpenAI和Anthropic的数据，强调了明确边界和验证的重要性，旨在帮助知识工作者有效管理AI代理，避免陷入协调困境。 技术 › Agent nyk 2026-08-12 AI代理监督委派验证管理CodexClaude Code工作流
C Can software factories actually work? 本文探讨了软件工厂（software factories）的概念及其可行性。文章指出，随着AI代理编写代码的速度超过人类审查能力，软件工厂应运而生，旨在通过自动化流水线实现代码的标准化交付。然而，HumanLayer CEO Dex Horthy 的系列文章《Why Software Factories Fail》引发了广泛讨论，他认为由于模型训练中缺乏对代码可维护性的评估，完全无人干预的“暗灯”软件工厂难以规模化。文章分析了软件工厂的现状、争议点，并指出其核心问题在于将“决定构建什么”与“构建”分离，建议代理需要更深入的问题上下文才能做出更好的架构决策。 技术 › Agent PostHog 2026-08-12 软件工厂AI代理代码审查Harness EngineeringLLM自动化可维护性PostHogDevOps技术趋势
