Somebody Has to Own What "Trusted" Means for Agent-Written Code.

Watch the video version:

In September, GitLab posted two jobs for a team called Trusted Agentic Development, inside its Developer Experience group: an Engineering Manager and a Senior Backend Engineer. The manager posting put the problem in two sentences: "Agents generate code and tests in seconds, so speed is no longer the constraint. Confidence is." It also named what makes confidence hard. Agents "can produce a passing test suite for software that doesn't work as intended, and a reviewer may not be able to tell the difference without redoing the work by hand."

The manager listing has since come down, and I do not know whether it was filled or withdrawn. The engineer role is still open, asking someone to "own the technical thesis for how GitLab validates software when an agent is the author." Both postings say this is not a quality assurance role, and both make the same choice about authority. The manager would "earn adoption across GitLab by building the best path, not by mandating a process," and the engineer needs "the ability to influence engineers across an organization without formal authority."

My reading of those postings is this: trust in agent-written code was never anyone's job before, and GitLab made it one, built on adoption rather than mandate. Most organizations have the same gap and no posting at all. Last week's piece was about confidence that follows authorship; here the author is an agent, and the confidence has to be built on purpose.

Leaders tell themselves two things. About people: you ship it, you own it, the line last week's piece answered for authorship, now stretched to code an agent wrote. About the system: it is a tooling problem, so add another check to the pipeline, raise test coverage, and let the platform team handle it. Both sound like ownership, and neither names an owner.

Under "you ship it, you own it," each engineer applies a private standard for when agent output is good enough; the manager posting describes building "one shared model of what 'trusted' means." Under "it is a tooling problem," the standard drifts toward whatever the tool checks, and the manager posting's warning is that agents "can produce a passing test suite for software that doesn't work as intended." Between the two, the definition of "trusted" has no owner, so reviewers fall back on redoing the work by hand, and the speed gained in generation is spent again in verification. That cost lands in some mix of three places, and the mix varies by team: the most trusted reviewer, who becomes the definition without the title; the release, which slows until the standard quietly drops; and the agents, which stop being used for anything that matters.

Naming an owner does not end the problem; it moves it. The team that ships needs to move, and the standard needs to hold. Both needs are legitimate, they meet at the same point, and neither can fully prevail. That is what I call a Structural Bearing™: a named tension between two legitimate systems that does not resolve, only gets managed. My reading is that GitLab's postings put the interface on adoption rather than mandate: the standard has to be useful enough that teams choose it.

The leaders who manage this well do not pick better tools, and they do not try to make one side win. They design the interface between the people who ship and the person who owns the standard. If you cannot name the person who decides what "trusted" means for agent-written code on your team, then your best reviewer is the definition, and nobody gave them the job.

Stop saying everyone owns quality. One person owns the definition: written down, shared across teams, and judged the way GitLab's postings judge their own work, by whether engineers actually trust and adopt it. The decision to ship stays with the team, at the level its decision rights already set. The definition owner sets the standard without approving every change; that boundary is the interface.

Ask the reviewer you trust most what they check in agent-written code that the tests do not. Then ask who decided that was the standard. If the answer is a name, you have an owner. If it is a shrug, your best reviewer is the definition.

The Edge Case walks through the Structural Bearing™, and how to stop fighting a tension like this one and start designing the interface: https://TheEdgeCaseBook.com

Why the tension that keeps coming back after your best fixes is evidence your system is working.