在信任自动合并 PR 之前，团队需要先补齐什么
Original title: Before You Trust Auto-Merge
The title and summary in the selected language are awaiting translation.
越来越多工程团队在讨论让 AI 智能体自动合并 PR，但真正的信任问题不在模型本身，而在于变更意图是否明确可审、验收标准是否事先定义、风险边界是否划定、验证是否真正执行、智能体权限是否受限，以及是否有可审查的决策记录。缺少这些，自动合并只是让决策变快，而非交付变快。Software Dark Factory 正尝试把意图、标准、约束、验证和权限边界内建到工作流中，让治理先于速度。
More engineering teams are talking openly about agents auto-merging PRs. The reaction is predictable — half excitement, half horror.
The excitement is understandable. If your AI agent can write the code, pass the tests, and merge the PR without anyone waiting in a queue, that is a genuinely faster delivery loop. The speed case is real.
The horror is also understandable. A merged PR is a commitment. It means something passed your bar. If an agent is making that call, what bar did it actually clear?
That tension is not going away. Agentic coding tools are improving quickly, and the pressure to use them fully — not just for generation but for the whole delivery loop — is only going to increase. So the question is not really whether agents should ever auto-merge. The question is what would need to be true before you trusted that path.
The trust problem is not the model
Most of the conversation about auto-merge risk focuses on the model. Is it good enough? Does it hallucinate? Can it understand the full codebase?
Those are real questions. But they are not the whole problem.
The trust problem is that most teams do not have a clear answer to a simpler set of questions:
Was the intent behind this change explicit and reviewable? Were acceptance criteria defined before the work started, not reverse-engineered from the output? Was the risk boundary named — what this change is allowed to touch and what it is not? Did verification actually run, and is there evidence it ran against the right thing? Was the agent's authority constrained, or could it have taken actions nobody anticipated? And is there a reviewable trail of what happened and why — not just a passing CI run, but a legible record of decisions made?
Without clear answers to those questions, auto-merge does not make delivery faster. It makes decisions faster. That is only useful if the decision quality is there.
What most teams are skipping
The teams moving fastest toward agentic delivery are often the ones skipping the governance step. The assumption is that speed and governance are in tension — that you govern later, once you know it works.
That assumption is understandable in early experimentation. It becomes a real problem when agentic patterns start touching production systems, customer-facing behaviour, or anything with a compliance or audit requirement.
The cost of retrofitting governance onto an ungoverned agentic workflow is high. You end up trying to reconstruct intent, evidence, and accountability from logs and memory rather than from structured records that were built into the workflow from the start.
The path that actually works
Auto-merge may well be the right end state for some classes of work — low-risk changes with strong test coverage, clear acceptance criteria, and a well-understood risk boundary. That is a reasonable place to get to.
But the path there starts with making the work reviewable before it is trusted. That means building the evidence trail into the workflow itself: intent, criteria, constraints, verification, agent authority, and human decision boundaries — attached to the work, not reconstructed after the fact.
That is the space we are working in with Software Dark Factory. The goal is not to slow agentic delivery down. It is to help teams build the trust infrastructure that makes faster delivery actually defensible — to the team, to reviewers, and eventually to anyone who needs to understand what happened and why.
Governance and speed are not opposites. But governance has to come first.
Source: Johnny Butler · Agentic Engineering · world.hey.com