14Working as a teamDeep dive ⑤

Who owns what the agent wrote: 'the agent wrote it' is not an excuse

When half the changes are agent-generated, accountability can't fall into a void — the person who hits merge puts their name on it

Read4 min read
Topicsteamwork · review · trust
TL;DR

An agent can't be accountable — it bears no consequence, doesn't remember, doesn't learn from the mistake. So "the agent wrote it" lifts responsibility off no one; it just drops it into a void, and the code is orphaned. The rule is simple: the person who hits merge puts their name on it, exactly as if they typed it themselves. And when the machine writes most of it, the review bar must rise, not fall — because there's now more code produced by something that can't answer for it.

Something breaks. You ask who wrote this part. The answer, weightless: "Oh, the agent wrote it."

And it's dropped as if it ends the investigation. The agent wrote it — meaning it's no one's fault. And it really is no one's fault: the agent can't take the blame, and the person who merged it just shrugged it off. Accountability evaporated right in front of you. That isn't an answer to the question — it is the problem, spoken aloud.

01An agent can't carry responsibility — so someone must

Accountability isn't a label stuck on for show. It's the anchor that holds quality: the accountable person is the one who'll bear the consequence if it's wrong, so they're the one with reason to look closely.

The agent has no such anchor. It bears no consequence when its code brings something down at midnight. It doesn't remember the mistake to avoid it next time — by morning it's forgotten. It loses no reputation, no sleep, learns nothing. Assigning responsibility to an agent is as meaningless as assigning it to the keyboard: both are just tools that turn a person's intent into text.

So responsibility can't sit with the agent. It has to sit with a human — and the only sensible human is the one who decided to bring that code in: the person who hits merge. The turn is here: "who wrote it" is the wrong question. The right one is "who's putting their name on it" — and the answer can never be "the machine."

02Signs a review is just rubber-stamping

When the machine writes fast and a lot, a very natural temptation appears: review quickly to keep up. And a quick review is just a stamp. The signs below tell you the team's review is sliding into ritual:

Signs a review is stamping, not actually looking
Waved through because "the agent wrote it"The reason to look lightly is exactly the reason to look hard: it was written by something that can't answer for it.
A diff too big to actually readThe agent spits out five hundred lines at once; the reviewer opens it, feels the fatigue, scrolls to the bottom and approves. Too big means no one read it.
Reading the code, not whether it runsReads plausible, gets approved — but "looks plausible" and "actually ran" are two things; the agent is best at writing what looks plausible.
Trusting the smooth summaryThe PR ships with a slick agent-written summary; the reviewer trusts the summary instead of checking what it summarizes.

What they share: every one is a review trusting the <i>account</i> instead of the <i>evidence</i>. And what the agent writes is brilliant at producing easy-on-the-ear accounts — so this is exactly where the bar must rise, not fall.

03Keep the review bar rising, not falling

The paradox to swallow: the machine writing more doesn't mean review gets lighter — it's the reverse. The more code that comes from something that can't answer for it, the heavier the burden of "a real person puts their name on it" must be, not lighter. A few rules to hold that bar:

1
The merger owns it, period

Hitting merge means accepting: "I answer for this as if I wrote it by hand." No "the agent wrote it" exception. The anchor of accountability must have a human on the other end.

2
Split small enough to read

A five-hundred-line diff is a diff no one truly reads. Make the agent ship in pieces reviewable in one sitting — what's readable is what gets read.

3
Review where it errs, not where it's strong

Don't waste effort on syntax — the agent types correct syntax. Scrutinize where it slips: did it grasp the intent, did it quietly touch elsewhere, does the test it wrote actually check what needs checking.

Notice all three shift the review's focus from "is the code clean" to "is someone answering for it, and does it do the thing it's meant to." Reviewing agent-written code isn't catching typos — it's confirming that a human genuinely understood and stands behind what's about to enter the system.

04Orphaned code is nameless debt

A piece of code no one truly owns is nameless debt in the system: when it breaks, no one feels they have to understand it, because "no one wrote it." It sits there until it blows, and then the whole team scrambles to trace something no one ever read closely.

Hold one line: the agent writes, but the merger owns. This is a review that doesn't rubber-stamp at team scale, and the team version of the habit of demanding evidence instead of trusting "done". The machine's writing speed is real and welcome — but it's only a bargain as long as every line entering the system has a human behind it, ready to say "this one's on me." Drop that anchor and you don't speed up — you just pile on debt faster.

c
The author

Each story here wraps a lesson paid for in full.

craftagentsomeone building and learning at once

What are you building with agents? Want to trade notes, push back, or build something together — drop a line.

Write hello@craftagent.cloud
58pieces12clustersVI·ENbilingual

Get new pieces by email

Field notes on working with AI agents — occasional, no spam.