Tessl：智能体写代码后，部署管线的钥匙不该交给人也不该交给 Agent

Human review downstream in the software development lifecycle was never an effective control, not for quality or security. When teams seek to build autonomous software factories with agentic engineering, this antipattern becomes impossible to ignore.

The best code reviews were the ones where you sat in a room with others to get feedback on architecture, best practices, etc., as a learning experience. Once you codified those, you just wanted the tool to catch the issues related to quality, security, standards, code smells, architecture, etc. The machine is best at deterministic checks, and the fact is that these tools cover most of the big issues uncovered during well-run code reviews. For example, running automated checks for code smells, secrets scanning, coding standards, architecture rules, and acceptance tests.

It's very helpful to get humans in a room to decide how the team wants to define the system architecture and how they want to translate and capture the customer acceptance criteria. But then you can use tools such as mutation testing for behavior, and launch a new subagent that verifies what's been implemented against the acceptance criteria. Human judgment belongs in the room discussing the standards, architecture, how to define acceptance criteria, and what quality, security, and other checks need to be applied. Then codify tooling and policies as code and run them as part of a bolstered deployment pipeline.

Agents turn a weak gate into a bottleneck

If human review was always broken, why does it matter so much more now? As builders adopt agentic engineering and consider building autonomous software factories, this antipattern becomes impossible to ignore. In the past, humans wrote slowly enough that an ineffective gate wasn't as obvious. What's more, people found comfort in believing they were doing the right thing by reviewing every change. That's no longer valid. With the volume and speed at which agents generate code, human review becomes a major bottleneck. Teams either resort to cursory reviews or let queues grow while humans review every change. A Harvard working paper found that pull requests are up about 23% and time to merge is up about 49%, while Faros AI's 2026 report found that median pull request review time is up 441%. The resulting backlog isn't a staffing issue. You can't scale a human gate. You replace it. And agentic engineering introduces a new class of trust-boundary checks we need to account for.

Agents author without authority

Who can do what when agents write the code? You can have agents write, propose, and recommend all day long. But you don't give agents the authority to actually do anything in production. The way to think of this is that agents author without authority. Authorship is writing code, tests, and issues, and proposing fixes. Authority is deploying and shipping to production. The agent can write anything. It can't ship anything. Just like you should never let humans run deployment steps manually, you should never let agents deploy. The deployment pipeline (aka CI/CD pipeline) has the authority to deploy to production. Developers and agents can ask for a human review, and so can your checks. But treat every review after the code exists as a defect and root-cause why that kind of change needed a person. Often the answer is a check you can add to the pipeline. If it isn't, ask whether a person could have made that call before the code existed. Irreversible actions still need a person, so that approval becomes something the pipeline checks before it acts. Then track the reviews that found nothing and the changes that skipped review and later broke. You want fewer reviews and a falling change failure rate.

Treat everything an agent reads as untrusted

Imagine an agent that reads issues, logs, tickets, and comments, and then acts on them. Each of these is a potential attack surface. Consider a bug report with a buried instruction to add a dependency and commit it. A human might skim past this, while an agent carries out the instruction. This isn't a theory. In early 2026, a researcher showed that a malicious issue title in Cline's GitHub repo could make its triage agent install a package from an attacker's fork. The agent had no publishing secrets. It didn't need them. It could poison a build cache shared with the nightly release job, whose publish tokens also worked for production releases. According to the researcher, another actor then used the same path to steal Cline's npm token and publish an unauthorized release in February. The solution is to treat everything an agent reads as untrusted. Make sure nothing the agent touches leads to something worth stealing: no secrets, no tokens, no shared state with anything that can publish. Cline also removed the triage agent, but the structural fix was dropping the cache from every workflow that publishes. After the attack, it moved npm publishing to OIDC, leaving no long-lived token to steal.

The pipeline has to earn the keys

Cline's release pipeline held the keys, and it wasn't the most protected thing in the system. A pipeline earns the keys only when it is. Pin every input by hash, including actions, dependencies, and images, and never share a cache with untrusted jobs. Give it one short-lived deploy identity through OIDC. Deny every other principal write access to production, humans and agents included.

Pipelines are code as well, so agents generate changes to them too. These agents will check against specs and ensure that permissions do not drift from the intent. Humans set the pipeline definition in a spec once, and checks will validate each proposed change. Detection of these changes occur outside the pipeline in an account it cannot touch. If there's a production change that cannot produce attested evidence the pipeline produced it, it fails.

The pipeline decides on behavior and intent

With the authority the pipeline has, it needs to decide whether the system behavior meets the customer intent. It decides this by checking the system behavior against the documented customer acceptance criteria. The human's job moves from reviewing code to defining that intent.

To measure behavior, you can use mutation testing. Mutation testing introduces small flaws into the source code and then confirms that your tests actually catch them. Code coverage is testing theater, whereas the mutation score it produces provides evidence.

To establish intent, an independent validator, using its own context, checks the system against the documented acceptance criteria. The judgment is probabilistic, while the gate in the pipeline is deterministic. Every criterion must pass with evidence. Mutation testing is checking to see if the tests are accurate whereas the validator is checking are you building the right thing.

Decide once, run it every time

The human can't hold the keys because downstream review was never an effective control and can't keep pace with agents. The agent can't either because one poisoned input can trick it into doing something nefarious. So you and your team decide once in a room, codify it, and run it the same way every time in a pipeline. Who gets the keys? Not the agent. Not the human. The pipeline.