使用 harnext 编码代理开发完整的企业应用程序

AI Agents Agentic Workflows Developer Productivity Engineering Culture

“AI 编写我们的大部分代码"听起来像一个初创公司的标语。对于一个企业应用程序——有现场客户、实时计费、一个坏合并会花钱的 monorepo——这能是真实的吗?在 QualityUnit 是的。以下是十个月的证据轨迹和使其有效的规则。

太长不读: 在十个月内,代理编写的工作从第一个实验性 PR 发展到 5 月合并的 144 个开发 PR 中的 133 个(92%) ——通过对所有 1,409 个合并 PR 的三方法证审计进行验证,深入到提交预告片和对每个未标记的 2026 PR 的手动检查。这不是通过"让 AI 编码"发生的:它是通过添加规则发生的——一个风险等级工具配置、一个具有有界审查循环的分阶段代理管道、受保护路径,以及一个掌控每次合并的人类。规则才是产品。而且有一个上下文引擎为代理提供信息,同样的工作现在成本降低了约 30%(在这里衡量 )。

实际需要什么

不是工具。一个管道、一个策略文件和一个门控——由 harnext 运行。

管道:分阶段的代理,一个人类

工具是 harnext ——QualityUnit 的开源、与提供商无关的编码代理工具。在我们的生产 monorepo 中,进入管道的每个问题都运行相同的 CI 触发的代理阶段,其进度通过人类一眼就能读取的标签进行跟踪:

生产管道:标记器、分类、规划、实现、带有有界审查修复循环的审查、独立代码审查代理、人类合并——加上文档园艺在合并后保持每个文件夹的文档同步

两个细节比阶段数更重要。循环是有界的: 审查中发现的缺陷会返回实现阶段有限的次数——代理收敛或上报给人类,它们不会乱动。没有什么盲目开始: 在编写一行之前,实现代理必须加载项目的约定并发出一个审查人员可以检查的确认块。

策略文件

另一半是一个机器可读的策略:repo 中的每个路径都分类为风险等级,每个等级都有可执行的门控。CI 读取它;合并策略读取它;代理被告知它。这不是建议:

高风险更改必须清除的内容:必需的检查、两个批准、强制审查代理、无自合并、受保护路径、架构边界、屏幕截图证据——以及强制上下文确认

受保护路径——迁移、支付、身份验证——是代理不能触及的文件。架构边界是强制执行的,而不是建议的。移除这些规则,编码代理就成为一个非常快速的合理看起来的责任生成器。

十个月,一个图表

采用轨迹,从代码库本身衡量。

每月合并的开发拉取请求,2025 年 7 月至 2026 年 6 月——深蓝绿色运行完整的代理管道端到端,浅蓝绿色是开发者与代理直接配对,灰色是未标记。百分比是总代理参与,2026 年 5 月达到 92%

该图表计算,对于每个月,有多少个合并的开发 PR 带有任何硬代理信号——编码代理的页脚、管道的标签、工具等级约定、提交共同作者预告片、代理提交电子邮件或管道自身的账户作为作者。Dependency-bot PR(约占所有合并的 8%)完全从图表中排除——它们既不是人工也不是编码代理工作。我们以三种独立的方式审计了信号:所有 1,409 次合并的 PR 元数据、5,000+ 个提交的提交级预告片,以及对 2026 年每个未标记 PR 的手动法证审查。三个读数很重要:

热情褪去;基础设施坚持。 2025 年时代是临时性的、个人采用——它的振荡方式完全像个人习惯一样:一个月 44%,11 月几乎 4% 当最重的用户暂停时。工具改变了曲线的形状:在风险等级到达后的一个月内,测量的份额跳到 89%;有了完整的管道它达到了 92% 并保持在那里。每一层规则增加的采用比任何个人的热情都多。两种色调在代理份额内讲述了相同的故事:浅色带是开发者手工与代理配对;深色带——运行完整管道从问题到审查 PR 的工作——仅在工具到达时出现,到 5 月它承载了代理工作的大部分。

我们逐个 PR 检查了其余的。 对于 2026 年 4 月至 6 月,没有任何标记的 PR 分解为:dependency-bot 自动化、其唯一属性在提交预告片中存活的代理工作,以及一个合理的手工编写更改的残差——约占非自动化合并的 11%。所以诚实的句子是:~89% 的最后一个季度的真实开发合并显示可验证的代理参与 ——即使这是一个下限,因为编辑器级别的 AI 辅助不留任何痕迹。我们还在三个最弱的月份派遣持怀疑态度的审计员,逐个 PR:11 月的计数从 1 上升到 3 个证明的(加上 3 个在风格上怀疑的),1 月从 10 下降到 8 个后捕捉到两个假正例,12 月被确认无误——有一个转折:按代码量,12 月的八个标记 PR 提交了该月插入行的 39%。代理已经在编写大功能;计数就是看不到。采用也不均匀:一些开发者运行接近 100% 的代理辅助,少数人仍然主要手工编写——管道无论如何都承载了越来越多的份额。

质量没有倒退。 同一个窗口发布了第 3 层的更改——LLM 提供商集成、支付相邻的工作、i18n 扩展——在变得更严格而不是更松散的门控下。当我们直接测量代理审查一致性时,22 个独立审查代理中的 21 个在同一个 PR 上达成了相同的结论

那么谁是作者?

对于人类所处位置的最好表述来自一篇研究工具驱动开发在航空级项目上的工程论文:

当一个更改到达人类作者时,常规质量问题已经被解决——作者的审查专注于架构和领域级决策。合并是作者的决策。合并代码的作者身份属于人类作者,无论哪个参与者生成了初始草稿。

— Štefan Moravík,设计和实现用于机场照明检查的无人机任务规划模块(论文,2026)

这也是生产中的交易:代理进行草稿编写和常规质量工作;人类进行架构、领域判断,并拥有合并。

常见问题

斯特凡是一位人工智能和软件工程师,正在构建FlowHunt。除了产品本身,他还为开发人员设计代理软件工程工作流,以降低开发成本,同时提高代码质量。

斯特凡·莫拉维克
斯特凡·莫拉维克
人工智能与软件工程师

为您的团队带来代理管道

FlowHunt 帮助工程团队设计代理管道、风险等级门控和上下文工作流,在降低开发成本的同时提高代码质量。