The Co-authored-by question

A few days ago I saw a LinkedIn post from a founder I follow. His team had been debating whether to add Claude as a co-author on their commits, the Co-authored-by: line that AI coding tools like to append. There was a poll, and the comments split cleanly down both sides.

For me it’s an easy one. I don’t add Claude as a co-author. But it’s worth saying why.

Accountability

When I merge a piece of code, I take full responsibility for the behavior it introduces. If it breaks in production, I’m the one who has to fix it and explain what happened. Once I’m the one accountable for what the code does, who or what helped me type it stops being interesting. That line answers a question that never comes up when things actually go wrong.

Ownership

The code I write for an organization isn’t my IP. The org pays me to produce it, so it belongs to the org, and that’s the deal I signed up for. The same logic runs the other way with tools. When I pay for a Claude subscription, I’m paying for the tokens that produce the output. I bought it, so it’s mine to ship. I don’t feel any pull to credit the thing I paid to use.

Then the sharper version of the question shows up: what if the org pays for the Claude subscription?

That makes the argument stronger. Now the company pays me to write the code and pays for the tool I write it with, which is the most ordinary arrangement in software. The company already pays for Sentry, for Axiom, for Temporal Cloud, for every library sitting in the dependency tree. None of them go in the author field. They all helped produce the shipped code, and the responsibility still rests with the engineer and the team. Claude sits in that same bucket.

And the AI tools are the only ones that try to sign their work. Cursor adds itself as a co-author by default, enough that people end up asking how to turn it off. Claude Code does the same out of the box. None of the other tools ever asked for the credit, so leaving the line off is something I have to actively do.

Transparency

The strongest case for adding it is on public repos. If I’m sending a patch to someone else’s open project, the maintainer might genuinely want to know an LLM wrote a chunk of the diff so they can decide how hard to review it. That’s fair. I’d respect a project that asked for it. But that’s specific to walking into a stranger’s codebase. In the repos I own and the ones I’m paid to work in, the calibration is already mine to do.

There’s a softer point too: that flagging AI involvement upfront biases a reviewer to expect slop. I find that one backwards. If the code is good, it’s good, and announcing its origin just turns people against it before they’ve read a line. Either way the fix is identical. Raise a PR you’ve reviewed yourself and would defend line by line. Do that and the co-author line is noise on top of work that already stands on its own.

What that takes

It’s easy to say “review your own PR.” My loop runs like this:

The step that carries the weight is the second one. An agent can justify almost any decision, and the justification usually sounds reasonable. I keep poking at the plan until I actually understand why a choice is right. And the slop I’m hunting in that draft PR is the usual kind: functions that didn’t need to exist, comments narrating the obvious, an abstraction wrapped around code that’s used in exactly one place. Nobody else gets added until it clears that bar.

By the time anyone else opens the PR, every line has already been through me.

So that’s where I land. I leave that line out, and it’s never once felt like I’m hiding that Claude helped write the code.

Peace ✌️