Summarizer

I would have expected people (maybe a small minority, but that includes myself) to have already instructed Claude to do this. It’s a trivial instruction to add to your CLAUDE.md file.

It's a config setting (probably the same end result though): https://code.claude.com/docs/en/settings#attribution-setting...

It doesn't work so well in my experience. I am currently wrapping (or asking the LLM to wrap) the commit message prompt in a script call. 1. the LLM is instructed on how to write a commit message and never include co-authorship 2. the LLM is asked to produce a commit message 3. the LLM output is parsed by a script which removes co-authorship if the LLM chooses to include it nevertheless

I guess our system prompt didn't work. If folks are having to add it manually into their own Claude.md files...

Typo from speech to text, corrected: “I guess Anthropic’s system prompt didn't work. If folks are having to add it manually into their own Claude.md files...”

My mistake - it was the configuration setting that did it. Nevertheless, you can control many other aspects of its behavior by tuning the CLAUDE.md prompt.

We use CC to power some of our code features and override this setting so we can provide our own attribution. So there are several legit reasons to permit this.

Ive seen it say coauthored by claude code on my prs...and I agree I dont want it to do that

So turn it off. "includeCoAuthoredBy": false, in your settings.json.

They changed it to `attribution`, but yes you can customize this

Yeah I much prefer it commit the agent, and I would also like if it committed the model I was using at the time.

You can already turn off "Co-Authored-By" via Claude Code config. This is what their docs show: ~/.claude/settings.json { "attribution": { "commit": "", "pr": "" }, The rest of the prompt is pretty clear that it's talking about internal use. Claude Code users aren't the ones worried about leaking "internal model codenames" nor "unreleased model opus-4-8" nor Slack channel names. Though, nobody would want that crap in their generated docs/code anyways. Seems like a nothingburger, and everyone seems to be fantasizing about "undercover mode" rather than engaging with the details.

None of this is really worrying, this is a pattern implemented in a similar way by every single developer using AI to write commit messages after noticing how exceptionally noisy they are to self-attribute things. Anthropics views on AI safety and alignment with human interests dont suddenly get thrown out with the bathwater because of leaked internal tooling of which is functionally identical to a basic prompt in a mere interface (and not a model). I dont really buy all the forced "skepticism" on this thread tbh.

I cringe every time I see Claude trying to co-author a commit. The git history is expected to track accountability and ownership, not your Bill of Tools. Should I also co-author my PRs with my linter, intellisense and IDE?

If those tools are writing the code then in general I do expect that to be included in the PR! Through my whole career I've seen PRs where people noted that code that was generated (people have been generating code since long before LLMs). It's useful context unless you've gone over the generated code and understand it and it is the same quality as if you wrote it yourself (which in my experience is the case where it's obvious boilerplate or the generated section is small). Needing to flag nontrivial code as generated was standard practice for my whole career.

Compilers don't usually write the code that ends up in a PR. But compilers do (and should) generally leave behind some metadata in the end result saying what tools were used, see for example the .comment section in ELF binaries.

Are you checking in compiled artifacts? Then yeah, we should have a chain of where that binary blob came from.

Compiler versions are usually included in the package manifest. Generally you include commit info compiler version and compilation date and platform embedded in the binaries that compilers produce.

Usually, pre-LLM generated code is flagged because people aren't expected to modify it by hand. If you find a bug and track it to the generated code, you are expected to fix the sources and re-generate. This is not at all the case with LLM-generated code - mostly because you can't regenerate it even if you wanted to, as it's not deterministic. That said, I do agree that LLM code is different enough from human code (even just in regards to potential copyright worries) that it should be mentioned that LLMs were used to create it.

See, for example, this blog post from 2014: https://go.dev/blog/generate The following comment in the blog post //go:generate stringer -type=Pill generates a .._string.go file which contains a '.String()' method. I would find it very reasonable to commit that with 'Co-Authored-By: stringer v0.1.0' or such. Or 'sed s/a/b/g' and 'Co-Authored-By: sed'

I think this is just the beginning so people are apprehensive, rightfully so, at this stage. I agree with you that AI use should be disclosed but using the commit message as a billboard for Anthropic hell no. Go put an add on the free tier.

You don't generally commit compiled code to your VCS. If you do need to commit a binary for whatever reason, yeah it makes sense to explain how the binary was generated.

You do usually pin your compiler version though, or at the very least set a minimum version

For the purpose of disclosure, it should say “Warning: AI generated code” in the commit message, not an advertisement for a specific product. You would never accept any of your other tools injecting themselves into a commit message like that.

My last commit is literally authored by dependabot.

But how much AI-generated code? If it's just a smallish function or two while most iof the code was written by hand?

My tools just don't add such comments. I don't know why I would care to add that information. I want my commits to be what and why, not what editor someone used. It seems like cruft to me. Why would I add noise to my data to cater to someone's neuroticism? At least at my workplace though, it's just assumed now that you are using the tools.

If a whole of people thought that running code through a linter or formatter was objectionable, I'd probably just dismiss their beliefs as invalid rather than adding the linter or formatter as a co-author to every commit.

You can disclose that you used an LLM in the process of writing code in other ways, though. You can just tell people, you can mention it in the PR, you can mention it in a ticket, etc.

+1. If we’re at an early stage in the agentic curve where we think reading commit messages is going to matter, I don’t want those cluttered with meaningless boilerplate (“co-authored by my tools!”). But at this point i am more curious if git will continue to be the best tool.

A Co-Authored-By tag on the commit. It's a standard practice and the meaning is self-explanatory. This is what Claude adds by default too.

I guess if enough people use it, doesn’t the tag become kind of redundant? Almost like writing “Code was created with the help of IntelliSense”.

I don't think so. The tag doesn't just say "this was written by an LLM". It says which LLM - which model - authored it. As LLMs get more mature, I expect this information will have all sorts of uses. It'll also become more important to know what code was actually written by humans.

Well is it actually being used as a tool where the author has full knowledge and mental grasp of what is being checked in, or has the person invoked the AI and ceded thought and judgment to the AI? I.e., I think in many cases the AI really is the author, or at least co-author. I want to know that for attribution and understanding what went into the commit. (I agree with you if it's just a tool.)

Yes and if they copy and paste code they don’t understand then they should disclose that in the commit message too!

Yes, it sets the reviewer's expectations around how much effort was spent reviewing the code before it was sent. I regularly have tool-generated commits. I send them out with a reference to the tool, what the process is, how much it's been reviewed and what the expectation is of the reviewer. Otherwise, they all assume "human authored" and "human sponsored". Reviewers will then send comments (instead of proposing the fix themselves). When you're wrangling several hundred changes, that becomes unworkable.

> Should I also co-author my PRs with my linter, intellisense and IDE? Absolutely. That would be hilarious.

Tools do author commits in my code bases, for example during a release pipeline. If I had commits being made by Claude I would expect that to be recorded too. It isn't for recording a bill of tools, just to help understand a projects evolution.

Yea in my Claude workflow, I still make all the commits myself. This is also useful for keeping your prompts commit-sized, which in my experience gives much better results than just letting it spin or attempting to one-shot large features.

> Should I also co-author my PRs with my linter, intellisense and IDE? Kinda, yeah. If I automatically apply lint suggestions, I would title my commit "apply lint suggestions".

Huh? Unless the sole purpose of the commit was to lint code, it would be unnecessary fluff to append the name of the automatically linted tools that ran in a pre-commit hook in every commit.

well maybe? co-authoring doesn't hide your authorship if I see someone committing a blatantly wrong code, I would wonder what tool they actually used

I merely read the PDF articles you linked, then posted, verbatim, the primary relevant section I could find therein. Nowhere does it say that works involving humans in collaboration with AI can't be copyrighted. The conclusions linked merely state that copyright claims involving AI will be decided on a case by case basis. They MAY reject your claim, they may not. This is all new territory so it will get ironed out in time, however I don't think we've reached full legal consensus on the topic, even when limiting our scope to just US copyright law. I'm interpreting your most recent reply to me as an implication that I'm taking the conclusions you yourself linked out of context. I'm trying to give the benefit of the doubt here, but the 3 linked PDF documents aren't "a mountain of evidence" supporting your argument. Maybe I missed something in one of those documents (very possible), but the conclusions are not how you imply. Whether or not a specific git commit message correctly sites Claude usage or not may further muddy the waters more than IP lawyers are comfortable with at this time (and therefore add inherent risk to current and future copyright claims of said works), but those waters were far from crystal clear in the first place. Again, IANAL, but from my limited layman perspective it does not appear the copyright office plans to, at this moment in time, concisely reject AI collaborated works from copyright. Your most recent link (Finnegan) is from an IP lawyer consortium that says it's better to include attribution and disclosure of AI to avoid current and future claim rejections. Sounds like basic cover-your-ass lawyer speak, but I could be wrong. Full disclosure: I primarily use AI (or rather agentic teams) as N sets of new eyeballs on the current problem at hand, to help debug or bounce ideas off of, so I don't really have much skin in this particular game involving direct code contributions spit out by LLMs. Those that have any risk aversion, should probably proceed with caution. I just find the upending of copyright (and many other) norms by GenAI morbidly fascinating.

That seems desirable? Like that's what commit messages are for. Describing the change. Much rather that than the m$ way of putting ads in commit messages

The commit message should complement the code. Ideally, what the code does should not need a separate description, but of course there can be exceptions. Usually, it's more interesting to capture in the commit message what is not in the code: the reason why this approach was chosen and not some other obvious one. Or describe what is missing, and why it isn't needed.

It sounds like if you are vibe-coding, that is, can't even be arsed to write a simple commit message, your commit message should be your prompt.

That sounds like design discussions best had in the issue/ticket itself, before you even start writing code. Then the commit message references the ticket and has a brief summary of the changes. Writing and reading paragraphs of design discussion in a commit message is not something that seems common.

Ticket systems are quite ephemeral. I still have access to commit messages from the 90s (and I didn't work on the software at the time). I haven't been able to track the contents of the gnats bug tracker from those days. And of course tickets can be private, so even if the data survived migration, you may not have access to it (principle of least privilege and all that).

if you've changed a function and are worried about the reason for the change not being tracked or disappearing, then add it as a comment, the commit message is not the place for this.

Not really about design, but technical reasons why this solution came to be when it’s not that obvious. It’s not often needed. And when it does, it usually fits in a short paragraph.

> technical reasons why this solution came to be What you're describing here is a design. The most important parts of a design are the decisions and their reasoning. e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message. You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?

So you'd disagree with style that Linux uses for their commits? Random example: Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension. sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region. From 99d2592023e5d0a31f5f5a83c694df48239a1e6c

I think my post makes it pretty clear that I would. If you want, I could cite several examples of organizations which use the method I described, so you can weigh it against the one example you provided, and get the full picture. In your example, for example, where was the issue tracked before the code was written? The format you linked makes it difficult to get the history of the issue. Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?

Git was built for email, because that's the system Linux uses. Commits appear inline. Diffs are reviewed and commented inline. Email is the review process, and commits contain enough information that git blame can get you a reasoning - it doesn't require you checking the email archive. Rather than a dead ticket that no longer exists. I can also supply you a list of companies that make use of git's builtin features if you like. But thats probably not relevant to discussing management techniques.

Everyone has its own system although companies do tend to codify it with a project manager. I used TODO.txt inside the repo. an org file, Things.app, a stack of papers, and a whiteboard. But once a task is done, I can summarize the context in a paragraph or two. That’s what I put in the commits.

I do this too. I’ll have a design.md and roadmap.md checked into the repository.

Here is an example https://cgit.freebsd.org/src/commit/?id=407b1e4980189252fade... You can find more example there https://cgit.freebsd.org/src/log/?showmsg=1

Unfortunately GitHub Copilot’s commit message generation feature is very human. It’s picked up some awful habits from lazy human devs. I almost always get some pointless “… to improve clarity” or “… for enhanced usability” at the end of the message. VS Code has a setting that promises to change the prompt it uses to generate commit messages, but it mostly ignores my instructions, even very literal ones like “don’t use the words ‘enhance’ or ‘improve’”. And oddly having it set can sometimes result in Cyrillic characters showing up at the end of the message. Ultimately I stopped using it, because editing the messages cost me more time than it saved. /rant

Honestly the aggressive verbosity of github copilot is half the reason don't use its suggested comments. AI generated code comments follow an inverted-wadsworth-constant: Only the first 30% is useful.

The human developer would just write what the code does, because the commit also contains an email address that identifies who wrote the commit. There's no reason to write: > Commit f9205ab3 by dkenyser on 2026-3-31 at 16:05: > Fixed the foobar bug by adding a baz flag - dkenyser Because it already identified you in the commit description. The reason to add a signature to the message is that someone (or something) that isn't you is using your account, which seems like a bad idea.

Aside from merges that combine commits from many authors onto a production branch or release tag. I would personally not leave an agent to do that sort of work.

I usually avoid merge commits in favor of rebases precisely for the reason you describe above.

BAD (never write these): - "Fix bug found while testing with Claude Capybara" - "1-shotted by claude-opus-4-6" - "Generated with Claude Code" - "Co-Authored-By: Claude Opus 4.6 <…>" This makes sense to me about their intent by "UNDERCOVER"

I guess you could just code and have it author only the commit message

What does non-undercover do? Where does CC leave metadata mainly? I haven't noticed anything.

it likes mentioning itself in commit messages, though you can just tell it not to.

There is a config setting for this: https://code.claude.com/docs/en/settings#attribution-setting...

Ah, thanks, it hasn't done it for mine so I was wondering if there's something lower-level somehow.

I don't understand the part about undercover mode. How is this different from disabling claude attribution in commits (and optionally telling claude to act human?) On that note, this article is also pretty obviously AI-generated and it's unfortunate the author didn't clean it up.

It's people overreacting, the purpose of it is simple, don't leak any codenames, project names, file names, etc when touching external / public facing code that you are maintaining using bleeding edge versions of Claude Code. It does read weird in that they want it to write as if a developer wrote a commit, but it might be to avoid it outputting debug information in a commit message.

You’ve correctly identified that naming isn’t sufficient for all communication. Name the things that stay constant in the code and explain the things that vary with a particular implementation in version control messages. Version control as a medium communicates what context the message was written for, which is far more appropriate than comments.

This. Its also annoying to have to go through this stack code -> blame -> commit message -> jira ticket -> issue in sales force... Or the even better "fixes bug NNNNN" where the bug tracking system referenced no longer exists. Digging through other systems (if they exist) to find the nugget in an artifact is a problem for humans too.

It also says don't announce that you are AI in any way including asking it to not say "Co-authored by Claude". I read the file myself. I'm still inclined to think people might be overreacting to that bit since it seems to be for anthropic-only to prevent leaking internal info. But I did read the prompt and it did say hide the fact that you are AI.

"and i also wrote this using claude" -- can we just include that at this point?