The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
151–160 of 636 posts
Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#152Earlier quoted context omitted.
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…
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.
(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.)
Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#153Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#154> 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.
Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#155Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#156Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#157Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#158Earlier quoted context omitted.
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 hav…
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
Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#159> "Anti-distillation: injecting fake tools to poison copycats" Plot twist: Chinese competitors end up developing real, useful versions of Claude's fake tools.
Re: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode
#160Earlier quoted context omitted.
Yes because you can be sued for copyright violation if you don't know the origin of one, and not the other.
As an attorney, I know copyright law. (This is not legal advice.) There's nothing about copyright law that says you have to credit an AI coding agent for contributing to your work. The person receiving the code has to perform their due diligence in any case to determine whether the author owns it or has permission from the owner to contribute it.
Additionally, this raises another big issue. A few years ago, a couple guys used software (what you could argue was a primitive AI) to generated around 70 billion unique pieces of music which amounts to essentially every piece of copyrightable music using standard music scales.
Is the fact that they used software to develop this copyrighted material relevant? If not, then their copyright should certainly be legal and every new song should pay them royalties.
It seems that using a computer to generate results MUST be added as an additional bit of analysis when it comes to infringement cases and fair use if not a more fundamental acknowledgement that computer-generated content falls under a different category (I'd imagine the real argument would be over how much of the input was human vs how much was the system).
Of course, this all sets aside the training of AI using copyrighted works. As it turns out, AI can regurgitate verbatim large sections of copyrighted works (up to 80% according to this study[0]) showing that they are in point of fact outright infringing on those copyrights. Do we blow up current AI to maintain the illusion of copyright or blow up current copyright law to preserve AI?