Summarizer

There are now several comments that (incorrectly?) interpret the undercover mode as only hiding internal information. Excerpts from the actual prompt[0]: NEVER include in commit messages or PR descriptions: - The phrase "Claude Code" or any mention that you are an AI - Co-Authored-By lines or any other attribution BAD (never write these): - 1-shotted by claude-opus-4-6 - Generated with Claude Code - Co-Authored-By: Claude Opus 4.6 <…> This very much sounds like it does what it says on the tin, i.e. stays undercover and pretends to be a human. It's especially worrying that the prompt is explicitly written for contributions to public repositories. [0]: https://github.com/chatgptprojects/claude-code/blob/642c7f94...

Since when is code considered > which is published with the purpose of informing the public on matters of public interest From your link, that's the only case where text needs to be attributed to AI.

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 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

It's less about pretending to be a human and more about not inviting scrutiny and ridicule toward Claude if the code quality is bad. They want the real human to appear to be responsible for accepting Claud's poor output.

That’s how I’d want it to be honestly. LLMs are tools and I’d hope we’re going to keep the people using them responsible. Just like any other tools we use.

>Also given we both managed to produce more than one sentence, and include capital letters in our comments, it's entirely possible both of us will be accused of being an AI. Could anyone explain the esoteric meaning of why people started doing that shit? I got a hypothesis, what's going on is something like this: 1. Prove you are human: write Like A Fucking Adult You Weirdo (internal designator for a specific language register, you know the one) 2. Prove you are human: _DON'T_ write Like A Fucking Adult You Weirdo (because that's how LLMs were trained to write, silly!) 3. ???? (cognitive dissonance ensues) 4. PROFIT (you were just subject to some more attrition while the AI just learned how to pass a lil bit better) I never thought computer programmers of all people would get trapped in such a simple loop of self-contradiction. But I guess the human materiel really has degraded since whenever. I blame remote work preventing us from even hypothetically punching bosses, but anyway weird fucking times eh? Maybe the posts trying to figure "this post is AI, that post is not AI" are themselves predominantly AI-generated? Or is it just people made uncomfortable by what's going on, but not able to articulate further, jumping on the first bandwagon they see? Or maybe this "AI-doubting of probably human posters" was started by humans, yes - then became "a thing", and as such was picked up by the LLM? Like who the fuck knows, but with all honesty that's how I felt about so many things, dating from way before LLMs became so powerful that the above became a "sensible" question to ask... Predominantly those things which people do by sheer mimesis - such as pop culture. "Are you a goddam robot already - don't you see how your liking the stupid-making song is turning you into stupid-you, at a greater rate than it is bringing non-stupid-you aesthetic satisfaction?" type of thing -- but then I assume in more civilized places than where I come from people are much more convincingly taught that personal taste "doesn't matter" (and simultaneously is the only thing that matters; see points 1-4... I guess that's what makes some people believe curating AI, i.e. "prompt engineering" can be a real job and not just boil down to you being the stochastic parrot's accountability sink?) I'm not even sure English even has the notions to point out the concrete issue - I sure don't know 'em. Ever hear of the strain of thought that says "all metaphysical questions are linguistic paradoxes (and it's self-evidently pointless to seek answers to nonsensical questions)"? Feels kinda like the same thing, but artificially constructed within the headspace of American anti-intellectuallism. Maybe a correct adversarial reading of the main branding acronym would be Anti-Intelligence. You know, like bug spray, or stain remover. But for the main bug in the system; the main stain on the white shirt: the uncomfortable observation that, in the end, some degree of independent thinking is always required to get real things done which produce some real value. (That's antithetical to standard pro-social aversive conditioning, which says: do not, under any circumstance, just put 2 and 2 together; lest you turn from "a vehicle for the progress of civilization" back into a pumpkin)

That’s ultimately the right answer, isn’t it? Bad code is bad code, whether a human wrote it all, or whether an agent assisted in the endeavor.

Yeah in my team everyone knows everyone is using LLMs. We just have a rule. Don't commit slop. Using an LLM is no excuse for committing bad code.

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

But I want to see Claude on the contributor list so that I immediately know if I should give the rest of the repo any attention!

Why not? What's wrong with honesty?

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

I guess Im sometimes dishonest when it suits me

Because some maintainers are hysterical

My first reaction is that they are using this to take advantage of OSS reviewers for in the wild evals.

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.

> 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 If this is not the case you should not be sending it to public repos for review at all. It is rude and insulting to expect the people maintaining these repos to review code that nobody bothered to read.

Sometimes code generation is a useful tool, and maybe people have read and reviewed the generator. The difference here is that the generator is a non-deterministic LLM and you can't reason about its output the same way.

"Here's what AI came up with and it mostly worked the one time I tested it. Might need improving". No. I don't want to test and pick through your shitty LLM generated code. If I wanted the entire code base to be junk, it'd say so in the readme.

> If those tools are writing the code then in general I do expect that to be included in the PR! How about compiler?

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.

>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 I thought the argument was that AI-users were reviewing and understanding all of the code?

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.

Absolutely. Let's say I have a problem with gRPC and traced it to code generated using the gRPC compiler. I can reproduce it, highlight it and I'm pretty sure the gRPC team would address the issue. Replace gRPC compiler with LLM. Can you reproduce? (probably not 100%). Can anybody fix it short of throwing more english phrases like "DO NOT", "NEVER", "Under No Circumstances"? Probably not.

For example `rails generate ...` built into the Rails CLI.

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'

There are many techniques. You're most likely to come across things like declarative DSL:s and macros, then there are things like JAXB and similar tooling that generates code from data schemas, and some people script around data sources to glue boilerplate and so on. Arguably snippet collections belong to this genre.

I am not against the general use of AI code. Quite simply, my view is that all relevant context for a review should be disclosed in the PR. AI and humans are not the same as authors of PRs. As an obvious example: one of the important functions of the PR process is to teach the writer about how to code in this project but LLMs fundamentally don't learn the same way as humans so there's a meaningful difference in context between humans and AIs. If a human takes the care to really understand and assume authorship of the PR then it's not really an issue (and if they do, they could easily modify the Claude messages to remove "generated by Claude" notes manually) but instead it seems that Claude is just hiding relevant context from the reviewer. PRs without relevant context are always frustrating.

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

Sometimes using AI to code feels closer to a Butterfly than emacs right?

A whole lot of people find LLM code to be strictly objectionable, for a variety of reasons. We can debate the validity of those reasons, but I think that even if those reasons were all invalid, it would still be unethical to deceive people by a deliberate lie of omission. I don't turn it off, and I don't think other people should either.

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.

well you know 100% know what dependabot does

Leaves you open to vulnerabilities in overnight builds of NPM packages that increasingly happen due to LLM slop?

You can set a minimum age for packages ( https://docs.github.com/en/code-security/reference/supply-ch... ), though that's not perfect (and becomes less effective if everyone uses it).

> becomes less effective if everyone uses it I don’t think that’s necessarily the case. Exposure and discovery aren’t that tightly correlated. Maybe there’s a small effect, but I think it is outweighed by the fact that blast radius and spread is reduced while buying time for discovery.

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.

What editor you are using has no effect on things like copyright, while software that synthesises code might. In commercial settings you are often required to label your produce and inform about things like 'Made in China' or possible adverse effects of consumption.

well if I know a specific LLM has certain tendencies (eg. some model is likely to introduce off-by-one errors), I would know what to look for in code-review I mean, of course I would read most of the code during review, but as a human, I often skip things by mistake

Tbh as long as the PR looks good, its good to go for internal testing.

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.

Like frying a veggie burger in bacon grease. Just because somebody's beliefs are dumb doesn't mean we should be deliberately tricking them. If they want to opt out of your code, let them.

I've heard similar things before. Frying a veggie burger in bacon grease to sneakily feed someone meat/meat-byproducts who does not want to eat it, like a vegan or a person following certain religious observances. As in, it's not ok to do this even if you think their beliefs are stupid.

In my view, vegans are dumb but it's still unethical to trick them into eating something they ordinarily wouldn't. Does that make sense to you? I am not asking you to agree with me on the merits of veganism, I am explaining why the merits of veganism shouldn't even matter when it comes to the question of deliberately trying to trick them.

Linters and formatters are different tools then LLMs. There is a general understanding that linters and formatters don’t alter the behavior of your program. And even still most projects require a particular linter and a formatter to pass before a PR is accepted, and will flag a PR as part of the CI pipeline if a particular linter or a particular formatter fails on the code you wrote. This particular linter and formatter is very likely to be mentioned somewhere in the configuration or at least in the README of the project.

Likewise. I don’t mind that people use LLMs to generate text and code. But I want any LLM generated stuff to be clearly marked as such. It seems dishonest and cheap to get Claude to write something and then pretend you did all the work yourself.

The reason I want it to be marked as such is because I review AI code differently than human code - it just makes different kinds of mistakes.

I think the issue is less attribution and more review mode. If I assume a change was written and checked line-by-line by the author, I review it one way. If an LLM had a big hand in it, I review it another way.

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.

So if I use Claude to write the first pass at the code, make a few changes myself, ask it to make an additional change, change another thing myself, then commit it — what exactly do you expect to see then?

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.

I'm not really sure that's any of their business.

If you accept the code generated by them nearly verbatim, absolutely. I don't understand why people consider Claude-generated code to be their own. You authored the prompts, not the code. Somehow this was never a problem with pre-LLM codegen tools, like macro expanders, IPC glue, or type bundle generators. I don't recall anybody desperately removing the "auto-generated do not edit" comments those tools would nearly always slap at the top of each file or taking offense when someone called that code auto-generated. Back in the day we even used to publish the "real" human-written source for those, along with build scripts!

It's weird, because they should not consider it as their own, but they should take accountability from it. Ideally, if I contribute to any codebase, what needs to be judged is the resulting code. Is it up to the project's standards ? Does the maintainer have design objections ? What tool you use shouldn't matter, be it your IDE or your LLM. But that also means you should be accountable for it, you shouldn't defend behind "But Claude did this poorly, not me !", I don't care (in a friendly way), just fix the code if you want to contribute. The big caveat to this is not wanting AI-Generated code for ideological reasons, and well, if you want that you can make your contributors swear they wrote it by themselves in the PR text or whatever. I'm not really sure how to feel about this, but I stand by my "the code is what matters" line.

Sounds bit like the label "organic (food)" coiuld be applied to hand-written code?

Some differences with the human source for those kinds of tools: (1) the resultant generated code was deterministic (2) it was usually possible to get access to the exact version of the tool that generated it Since AI tools are constantly obsoleted, generate different output each run, and it is often impossible to run them locally, the input prompts are somewhat useless for everyone but the initial user.

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.)

I have worked with quite a few people committing code they didn't fully understand. I don't meant this as a drive by bazinga either, the practice of copying code or thinking you understand it when you don't is nothing new

Pre-LLM, it was much easier for reviewers to discern that. Now, the AI-generated code can look like it was well thought out by somebody competent, when it wasn't.

Have you ever reviewed an AI-generated commit from someone with insufficient competence that was more compelling than their work would be if it was done unassisted? In my experience it’s exactly the opposite. AI-generation aggravates existing blindspots. This is because, excluding malicious incompetence, devs will generally try to understand what they’re doing if they’re doing it without AI

I think the issue is not that the patches are more compelling but that they're significantly larger and more frequent

I have. It's always more compelling in a web diff. These guys are the first coworkers for which it became absolutely necessary for me to review their work by pulling down all their code and inspecting every line myself in the context of the full codebase.

I try to understand what the llm is doing when it generates code. I understand that I'm still responsible for the code I commit even if it's llm generated so I may as well own it.

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.

Sent from my iPhone

> 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.

I suspect vibe coders might actually want you to consider turning to Claude for accountability and ownership rather than the human orchestrator. If your linter is able to action requests, then it probably makes sense to add too.

No, because those things don't change the logical underpinnings of the code itself. LLM-written code does act in ways different enough from a human contributor that it's worth flagging for the reviewer.

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.

Eh, there are some very good reasons[0] that you would do better to track your usage of LLM derived code (primarily for legal reasons) [0]: https://www.jvt.me/posts/2026/02/25/llm-attribute/

legally speaking.. if you're not sure of the risk- you don't document it.

Seems ethical

> legally speaking.. if you're not sure of the risk- you don't document it. Ah, so you kinda maybe sorta absolve yourself of culpability (but not really — "I didn't know this was copyrighted material" didn't grant you copyright), and simultaneously make fixing the potentially compromised codebase ( someone else's job, hopefully) 100x harder because the history of which bits might've been copied was never kept. Solid advice! As ethical as it is practical. By the same measure, junkyards should avoid keeping receipts on the off chance that the catalytic converters some randos bring in after midnight are stolen property. Better not document it. One little trick the legal folks don't want you to know!

Sent from my Ipad

I've heard of employers requiring people to do it for all code written with even a whiff of it

> 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.

Could be cool if your PRs link back to a blog where you write about your tools.

> The git history is expected to track accountability and ownership, not your Bill of Tools. The point isn't to hijack accountability. It's free publicity, like how Apple adds "Sent from my IPhone."

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.

You do, as the developer. Let's circle back to the original comment that started this discussion: https://news.ycombinator.com/item?id=47594044 That comment is spot on. Claude adding a co-author to a commit is documentation to put a clear line between code you wrote and code claude generated which does not qualify for copyright protection. The damning thing about this leak is the inclusion of undercover.ts. That means Anthropic has now been caught red handed distributing a tool designed to circumvent copyright law.

Not leaking codenames is one thing, but explicitly removing signals that something is AI-generated feels like a pretty meaningful shift.

Where the hell are people getting this idea that it's ok to be deceptive because they are keeping secrets? No shit they have secrets. I have secrets too. That doesn't make it ok for me to deceive you in any way. How would you feel if I deceived you and my excuse was "oh I was just trying some new secret technique of mine"? How did we get to this point where we let enormously powerful companies get away with more than individuals?

> my first knee-jerk reaction wouldn't be "this is for pretending to be human"... "Write commit messages as a human developer would — describe only what the code change does."

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.

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

As opposed to outputting debugging information, which I wouldnt be surprised if LLMs do output "debug" output blurbs which could include model specific information.

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.

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 think the motivation is to let developers use it for work without making it obvious theyre using AI

Which is funny given how many workplaces are requiring developers use AI, measuring their usage, and stack ranking them by how many tokens they burn. What I want is something that I can run my human-created work product through to fool my employer and its AI bean counters into thinking I used AI to make it.

I guess that would work until they started auditing your prompts. I suppose you could just have a background process on your workstation just sitting there Clauding away on the actual problem, while you do your development work, and then just throw away the LLM's output.

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

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.

Even some of these comments are obviously Ai-assisted. I hate that I recognize it.

I'd really recommend putting a modicum of work into cleaning up obvious AI generated output. It's rude, otherwise, to the humans you're expecting to read this.

These can be flagged and reported to mods btw. We don't have to accept this.

I have been!

> The obvious concern, raised repeatedly in the HN thread: this means AI-authored commits and PRs from Anthropic employees in open source projects will have no indication that an AI wrote them. It’s one thing to hide internal codenames. It’s another to have the AI actively pretend to be human. I don’t get it. What does this mean? I can use Claude code now without anyone knowing it is Claude code.

technically you're correct, but look at the prompt https://github.com/alex000kim/claude-code/blob/main/src/util... it's written to _actively_ avoid any signs of AI generated code when "in a PUBLIC/OPEN-SOURCE repository". Also, it's not about you. Undercover mode only activates for Anthropic employees (it's gated on USER_TYPE === 'ant', which is a build-time flag baked into internal builds).

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.

Why does that matter though

There are probably different reasons for different people. I can definitely see the angle that trying to specifically pretend to not be AI when contributing to open source could be seen as a bad thing due to the open source supply chain attacks, some AI-driven, that we've been having, not to mention the AI-slop PR spam. But, I also get Anthropic's side that when they're contributing they don't want their internals leaked. If it had been left at that, that's fine, but having it pretend like it's not AI at all rubs me a little bit the wrong way. Why try to hide it?

>There are probably different reasons for different people. I can definitely see the angle that trying to specifically pretend to not be AI when contributing to open source could be seen as a bad thing due to the open source supply chain attacks, some AI-driven, that we've been having, not to mention the AI-slop PR spam. But none of the other agents advertise that the commit was done by an agent. Like Codex. Your panic should apply equally to already existing agents like Codex no?

I agree with you, I think people are overthinking this.

I think it means OSS projects should start unilaterally banning submissions from people working for Anthropic.

Because it has a high likelyhood of being written completely by a LLM without any human thought or attention being put into it. Being written by a LLM is a signal that the submission is of low effort and therefore probably low quality, which then puts the onus on the people reviewing and reading the submission instead of the original generator of the submission. Hence I would classify it as spam. Open source communities also have rules against LLM generated contributions, for various moral, ethical, or legal reasons.

...Because it's a mode of using Claude Code that allows certain users to use the application in "stealth mode" to produce pull requests that seem human, but are actually AI generated, which often goes against the contribution rules of OSS projects? At this point I would consider any employee of an AI provider to be tainted.

None of the other agents claim that the commit was made by an AI so why the panic suddenly

If anybody cares about AI-written code slipping in they can grep for style tells or run a classifier against a suspect repo. You won't get guarantees. Watermarks and disclosure tags die the moment someone edits the patch, so secret strings and etiquette signs are cargo cult security and the only answer is review.

They want "Made with Claude Code" on your PRs as a growth marketing strategy. They don't want it on their PRs, so it looks like they're doing something you're not capable of. Well, you are and they have no secret sauce.

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

Out of curiosity, given two code submissions that are completely identical—one written solely by a human and one assisted by AI—why should its provenance make any difference to you? Is it like fine art, where it’s important that Picasso’s hand drew it? Or is it like an instruction manual, where the author is unimportant? Similarly, would you consider it to be dishonest if my human colleague reviewed and made changes to my code, but I didn’t explicitly credit them?

Yes because you can be sued for copyright violation if you don't know the origin of one, and not the other.

You're asking a lot of very good and thoughtful questions, but none are directly related to the immediate issue, which is "do I have to credit the AI model?". To begin to answer your questions, I would suggest you study the Copyright Office's report (which is also not law, but their guidance for laypeople as written by their staff lawyers) at https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...

Why does the provenance make any difference? Let me increase your options. Option 1: You completely hand-wrote it. Option 2: You were assisted by an AI, but you carefully reviewed it. Option 3: You were assisted by an AI (or the AI wrote the whole thing), and you just said, "looks good, YOLO". Even if the code is line-for-line identical, the difference is in how much trust I am willing to give the code. If I have to work in the neighborhood of that code, I need to know what degree of skepticism I should be viewing it with.

That's the thing. As someone evaluating pull requests, should you trust the code based on its provenance, or should you trust it based on its content? Automated testing can validate code, but it can't validate people. ISTM the most efficient and objective solution is to invest in AI more on both sides of the fence.

In the future, that may be fine. We're not in that future yet. We're still at a place where I don't fully trust AI-only code to be as solid as code that is at least thoroughly reviewed by a knowledgeable human. (Yes, I put "AI-only" and "knowledgeable" in there as weasel words. But I think that with them, it is not currently a very controversial case.)

You are spamming the whole fucking thread with the same nonsense. It is instructed to hide that the PR was made via Claude Code. I don't know why people who are so AI forward like yourself have such a problem with telling people that they use AI for coding/writing, it's a weirdly insecure look.

It's different if it's an institutional decision or a personal like in your case. Which is and I am repeating myself here borderline insecure.

?? why doesn't your panic apply to other agents like Codex that don't advertise that the commit was made by an AI by default? strange!