Who owns agent-written code six months later?

Agent-written code is strange because it can feel done very quickly.

You describe the task, wait a bit, and now there is a diff. Sometimes it is even a decent diff. It has types, tests, helper functions, and names that look normal enough.

That speed is nice. I use these tools too.

But six months later nobody cares how the code arrived. It is just code in the repo. It can break. It can confuse someone. It can have one extra abstraction that nobody understands.

So for me, merging agent-written code means owning it later.

git only remembers humans#

Git has an author and a committer. There is no field for:

assistant wrote most of this
human skimmed it at 1 AM
seemed fine

If my name is on the commit, future me has to answer for it.

That sounds obvious, but I think people avoid saying it directly. “The agent wrote this” becomes a little escape route. It explains where the code came from, but it will not help when the code breaks.

Production pages the human attached to the change.

accepting can outrun understanding#

Before AI tools, writing a helper took some effort. That effort forced at least some understanding. You had to choose the shape yourself.

Now a helper can appear in one shot.

That is useful, but it also means I can accept code before I understand it. The diff can look clean while hiding a bad assumption.

I try to ask one boring question before merging:

If this breaks later, will I know where to start?

If the answer is no, I keep working.

Code without a debugging path is debt, regardless of who typed it.

prompts make weak documentation#

I would rather not make future me read a prompt to understand a function.

The code should be clear enough. The tests should show the behaviour. The commit message should say why the change exists.

The prompt can be useful while working, but source-of-truth status belongs to the code, tests, and commit message. Prompts are messy. They include failed ideas, missing context, and weird wording from when I was still figuring out what I wanted.

If the code only makes sense after reading the prompt, I should rewrite the code.

how I review it#

I mostly review agent code the same way I review my own code, just a little slower.

I check what changed, what state the code assumes, what happens on bad input, what happens twice, and what happens on retry. That last one matters a lot because agents are quite good at the happy path and weaker around partial work that runs again.

I also watch for new helpers that feel too general.

A tiny private helper is usually fine. A new mini-framework inside one PR deserves much more suspicion.

Without a clear reason for an abstraction, compiling alone is too weak a reason to merge it.

the deletion test#

Good generated code should be easy to delete.

That sounds negative, but I mean it in a good way. If the agent adds a wrapper or helper without a removal story, I get suspicious.

Generated code is cheap. Deleting it should also be cheap.

The diff has no special claim on me.

my rule#

If an agent writes code and I merge it, it is mine.

So I can ask for another version. I can shrink it. I can throw it away. I can write tests around it. I can move slower even if the tool moved fast.

The origin story fades quickly, while the maintenance stays.