# Building a Self-Improving, AI-Native Company
**作者**: Dan Westgarth
**日期**: 2026-07-15T10:56:47.000Z
**来源**: [https://x.com/DanWestgarth/status/2077346634275430478](https://x.com/DanWestgarth/status/2077346634275430478)
---
A self-improving company runs on self-improving software: systems that work in recursive loops, learn from what actually happens, and adapt with little or no human intervention. Done right, the product gets better on its own, even while you sleep.
Most AI at work does the opposite. It takes the way we already operate and bolts a faster engine onto it. We wanted something different, and bug fixing is the first place we made it real at Deel.
## How We Built Software That Finds and Fixes Its Own Bugs
For most of software's history, the first one to notice a bug in production was the customer. They would hit the broken page, file a ticket, and wait for an engineer to read it, track down the cause, and ship a fix. The whole loop that kept software working ran outside the software, through people.
Most attempts to bring AI into that loop just make the people in it faster: an engineer clears tickets a little quicker, a reviewer reads a little less. We wanted something different. Not a faster version of the old loop, but a loop that closes on itself.
So we built two agents at Deel. The first, Bug Hunter, explores real customer environments and finds what's broken. The second, Deel Code, writes the fix and proves it works. A person makes the final call, an engineer reviews and approves every fix before it ships.
Tests often do not catch these bugs, because tests are deterministic and check for pre-defined scenarios and cases, while real-life variations can be enormous.
## The Long Tail
Modern software environments are too variable for static testing alone. Every customer account behaves slightly differently, with its own integrations, workflows, permissions, and enabled features.
Many failures now live in the long tail of those combinations. A page breaks only when a certain role loads a certain dataset with a certain integration enabled or a workflow shipped years ago collides with a feature released last week.
These failures rarely appear inside the environments where engineers normally test software. The one place they do appear is the one place tests can't reach: a real customer's account. So the first agent we built goes there and looks.
## 1) Bug Hunter
The first part of the loop is Bug Hunter.
Bug Hunter runs continuously against isolated replicas of customer accounts, navigating the product the way a person would: loading pages, clicking through workflows, triggering actions. As it moves, it watches for the signatures of something broken: console errors, failed network requests, broken UI states, rendering failures, dead interactions.
The replicas matter. They give the agent room to explore aggressively without ever touching a real user.
Temporary failures and model mistakes can both look like bugs at first glance. So when Bug Hunter thinks it has found something, it reruns the sequence to confirm the bug is real before creating a ticket. Then it deduplicates.
A single frontend regression might show up across hundreds of customer environments at once. Engineering doesn't need hundreds of tickets for one issue. It needs one ticket, with context on how widespread the problem is.
Once verified, the issue moves to Deel Code.
## 2) Deel Code
Deel Code is the second agent, the one that actually fixes what Bug Hunter finds. Think of it as an automated engineer: it takes a verified bug, works out what caused it, writes the fix, and confirms the fix worked. A person still has the final say: an engineer reviews and approves every fix before it ships.
Early on, we learned that fixing bugs was less about writing code than about understanding what went wrong.
Production tickets are rarely clean prose. Most are scraps of evidence: screenshots with red arrows, Loom recordings, vague descriptions. The signal usually lives outside the text, so Deel Code had to become multimodal. One sub-agent reads the ticket, another analyzes screenshots, another processes video recordings and reconstructs what the user actually did and what the UI showed, step by step.
The important realization was that these sub-agents needed extremely narrow scopes. The image analyzer should only describe what it literally sees. The first time we let a single agent both look and implement, it started editing files the bug had nothing to do with.
Large repositories overwhelm agents very quickly once irrelevant information enters the context window. Deel Code works by breaking the task apart:
- one agent analyzes requirements
- one navigates the repository
- one writes the implementation
- one opens the PR
Each agent sees only what its own task requires. That structure is what makes it accurate.
## The Moment The Broke Agents
One of the earliest fixes Deel Code generated passed tests, got approved, and merged cleanly, yet still broke the UI. The code looked correct. The product behavior was wrong.
The dropdown from the original ticket now closed correctly on an outside click. It also closed every other dropdown on the page. Nobody caught it, because the diff looked reasonable. We had optimized the wrong thing. Compiling code is not the same as correct behavior.
For visual products especially, "the diff looks right" is not a verification system. It's intuition. And intuition doesn't scale into autonomous systems.
## Giving The Agent Eyes
The fix was obvious in retrospect.
The same multimodal capability that let Deel Code understand a bug report could let it verify its own work. So we put a browser directly into the loop.
After writing a fix, the system launches Playwright against the preview environment, reproduces the original issue, and checks whether the reported symptom actually disappeared.
Only fixes that survive browser verification reach a human engineer. By that point, the system has already:
- discovered the issue
- reconstructed the user behavior
- identified the relevant code
- written the implementation
- verified the result in a real browser
- opened the pull request
By the time an engineer looks, the discovery is done. An engineer reviews the pull request Deel Code opened, decides whether the fix is genuinely right, and approves it. Nothing merges, and nothing reaches production, without that human sign-off.
The agents don't remove the engineer; they move the engineer to the end of the loop, to the one decision that most needs a human: is this right, and should it ship? The searching, reconstructing, writing, and checking (the work that used to take the most time) is already done. People are left with the part where being wrong is most expensive. The agent proposes; a person always approves.
## Closed-Loop Systems
The shift underneath all of this is that software is starting to grow its own correction loop. The system exercises itself against real-world environments, searches for failures, attempts repairs, verifies the outcome, and runs the cycle again. It doesn't wait to be told where to look, and it doesn't stop when the office empties. The maintenance loop that used to live in people now lives inside the system, and it keeps running while everyone sleeps.
That is fundamentally different from how most software has operated. For decades, software executed, and people observed it, judged it, and corrected it from the outside. What we are building observes itself, notices when reality doesn't match what it expected, and works to close the gap until the result holds.
Bug fixing is only the first place we've closed this loop. The same pattern (observe, detect a mismatch, attempt a correction, verify, repeat) reaches well beyond bugs. Most software will move from systems that only execute toward systems that adapt: that watch their own outcomes and improve them a little more each cycle, with people positioned exactly where judgment matters most.
## 相关链接
- [Dan Westgarth](https://x.com/DanWestgarth)
- [@DanWestgarth](https://x.com/DanWestgarth)
- [9.4K](https://x.com/DanWestgarth/status/2077346634275430478/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:56 PM · Jul 15, 2026](https://x.com/DanWestgarth/status/2077346634275430478)
- [9,432 Views](https://x.com/DanWestgarth/status/2077346634275430478/analytics)
---
*导出时间: 2026/7/16 09:51:48*
---
## 中文翻译
# 打造一家自我进化的 AI 原生公司
**作者**: Dan Westgarth
**日期**: 2026-07-15T10:56:47.000Z
**来源**: [https://x.com/DanWestgarth/status/2077346634275430478](https://x.com/DanWestgarth/status/2077346634275430478)
---
一家自我进化的公司运行在自我进化的软件之上：这些系统在递归循环中工作，从实际发生的事情中学习，并在极少甚至没有人工干预的情况下进行适应。如果做得好，产品会自行变得更好，甚至在你睡觉的时候也是如此。
大多数工作中的 AI 做的恰恰相反。它只是接手我们现有的运作方式，并在其上安上一个更快的引擎。我们想要一些不同的东西，而修复 Bug 是我们在 Deel 率先将其变为现实的第一步。
## 我们如何构建能自行发现并修复 Bug 的软件
在软件历史的大部分时间里，第一个发现生产环境 Bug 的是客户。他们会遇到损坏的页面，提交工单，然后等待工程师去阅读、追踪原因并发布修复。维持软件正常运行的整个循环都在软件之外，通过人来完成。
大多数尝试将 AI 引入该循环的做法只是让其中的人更快一点：工程师清理工单稍微快一点，审查者读的内容稍微少一点。我们想要一些不同的东西。不是旧循环的加速版，而是一个自我封闭的循环。
因此，我们在 Deel 构建了两个 Agent。第一个是 Bug Hunter，它探索真实的客户环境并找出损坏的地方。第二个是 Deel Code，它编写修复代码并证明其有效。一个人拥有最终决定权，工程师会在每个修复发布之前审查并批准它。
测试往往无法捕捉到这些 Bug，因为测试是确定性的，只检查预定义的场景和案例，而现实生活中的变化可能是巨大的。
## 长尾
现代软件环境对于静态测试来说太复杂多变了。每个客户账户的行为都略有不同，拥有自己的集成、工作流、权限和启用的功能。
许多故障现在存在于这些组合的“长尾”中。只有在特定角色加载了特定数据集并启用了特定集成时，或者多年前发布的工作流与上周发布的功能发生冲突时，页面才会崩溃。
这些故障很少出现在工程师通常测试软件的环境中。它们唯一出现的地方是测试无法触及的地方：真实的客户账户。所以我们构建的第一个 Agent 就会去那里查看。
## 1) Bug Hunter
循环的第一部分是 Bug Hunter。
Bug Hunter 在客户账户的隔离副本上持续运行，像人一样浏览产品：加载页面、点击工作流、触发操作。在移动过程中，它会监视损坏的迹象：控制台错误、失败的网络请求、损坏的 UI 状态、渲染失败、无响应的交互。
副本至关重要。它们为 Agent 提供了积极探索的空间，而绝不会触及真实用户。
暂时性故障和模型错误乍一看都像 Bug。因此，当 Bug Hunter 认为它发现了问题时，它会重新运行该序列以在创建工单之前确认 Bug 是真实的。然后它会进行去重。
单个前端回归问题可能会同时出现在数百个客户环境中。工程团队不需要针对一个问题收到数百张工单。它只需要一张工单，并附带关于问题普遍程度的上下文。
一旦得到验证，问题就会移交给 Deel Code。
## 2) Deel Code
Deel Code 是第二个 Agent，也是真正修复 Bug Hunter 发现问题的那个。可以把它想象成一个自动化工程师：它接收一个已验证的 Bug，弄清原因，编写修复代码，并确认修复有效。人仍然拥有最终决定权：工程师会在每个修复发布之前审查并批准它。
在早期，我们了解到修复 Bug 与其说是写代码，不如说是理解哪里出了问题。
生产环境的工单很少是清晰的文章。大多数是零碎的证据：带有红箭头的截图、Loom 录屏、模糊的描述。信号通常存在于文本之外，因此 Deel Code 必须变得多模态化。一个子 Agent 阅读工单，另一个分析截图，还有一个处理视频录像并逐步重建用户实际做了什么以及 UI 显示了什么。
重要的认识是，这些子 Agent 需要极其狭小的范围。图像分析器应该只描述它实际看到的内容。当我们第一次让单个 Agent 既查看又实现时，它开始编辑与 Bug 无关的文件。
一旦不相关的信息进入上下文窗口，大型代码库就会迅速让 Agent 不堪重负。Deel Code 通过将任务拆分来工作：
- 一个 Agent 分析需求
- 一个 Agent 导航代码库
- 一个 Agent 编写实现代码
- 一个 Agent 打开 PR（拉取请求）
每个 Agent 只看到其任务所需的内容。这种结构正是它准确的原因。
## 让 Agent 受挫的时刻
Deel Code 生成的最早修复之一通过了测试，获得了批准，并干净地合并了，但仍然破坏了 UI。代码看起来是正确的。产品行为却是错误的。
原始工单中的下拉菜单现在在点击外部时正确关闭了。但它也关闭了页面上的所有其他下拉菜单。没有人发现这一点，因为差异看起来是合理的。我们优化了错误的东西。编译代码不等于正确的行为。
特别是对于视觉产品来说，“差异看起来正确”并不是一个验证系统。它是直觉。而直觉无法扩展到自主系统中。
## 赋予 Agent 眼睛
事后看来，解决方法是显而易见的。
让 Deel Code 能够理解 Bug 报告的同样的多模态能力，也可以让它验证自己的工作。因此，我们将浏览器直接放入循环中。
编写修复后，系统会在预览环境中启动 Playwright，重现原始问题，并检查报告的症状是否真的消失了。
只有通过浏览器验证的修复才能到达人类工程师手中。到那时，系统已经：
- 发现了问题
- 重建了用户行为
- 确定了相关代码
- 编写了实现代码
- 在真实浏览器中验证了结果
- 打开了拉取请求
当工程师查看时，发现工作已经完成。工程师审查 Deel Code 打开的拉取请求，决定修复是否真正正确，并批准它。没有人工签字确认，什么都不会合并，什么都不会到达生产环境。
Agent 并没有取代工程师；它们将工程师移到了循环的末端，移到了最需要人类决策的那个环节：这是否正确，应该发布吗？搜索、重建、编写和检查（以前最耗时的工作）已经完成。人类留下的部分是犯错代价最高的部分。Agent 提议；人类总是批准。
## 闭环系统
这一切背后的转变是，软件开始拥有自己的修正循环。系统在现实环境中自我运行，搜索故障，尝试修复，验证结果，并再次运行循环。它不需要被告知去哪里看，也不会在办公室空无一人时停止。曾经存在于人身上的维护循环现在存在于系统内部，并在每个人睡觉时持续运行。
这在根本上与大多数软件的运行方式不同。几十年来，软件执行任务，而人在外部观察、判断和纠正它。我们正在构建的东西会自我观察，注意到现实与预期不符时，努力缩小差距，直到结果成立。
修复 Bug 只是我们实现这一闭环的第一个地方。同样的模式（观察、检测不匹配、尝试纠正、验证、重复）远远超出了 Bug 的范围。大多数软件将从仅执行的系统转向适应的系统：观察自己的结果并在每个周期中改进一点，而人则正好位于判断最重要的地方。
## 相关链接
- [Dan Westgarth](https://x.com/DanWestgarth)
- [@DanWestgarth](https://x.com/DanWestgarth)
- [9.4K](https://x.com/DanWestgarth/status/2077346634275430478/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [6:56 PM · Jul 15, 2026](https://x.com/DanWestgarth/status/2077346634275430478)
- [9,432 Views](https://x.com/DanWestgarth/status/2077346634275430478/analytics)
---
*导出时间: 2026/7/16 09:51:48*