881–890 of 1001 posts
Amusingly, they deprecated it with a message of "Unpublished" instead of actually unpublishing it [1]. When you use npm unpublish it removes the package version from the registry, when you use npm deprecate it leaves it there and simply marks the package as deprecated with your message. I have to imagine the point was to make it harder for people to download the source map, so to deprecate it with this message gives…
Earlier quoted context omitted.
You can say what you want about anthropic but they sure as hell are dogfooding the crap out of claude code lmao
In all my years of writing tools for other devs, dog fooding is the really the best way to develop IMO. The annoying bugs get squashed out because I get frustrated with it in my flow. Iterating on a MCP tool while having Claude try to use it has been a really great way of getting it to work how others are going to use it coming in blind. Yes it's buggy as hell, but as someone echoed earlier if the tool works most of…
Not just tools for devs, this is true in a lot of cases.
I used to work at Fortinet and every now and then we'd get an e-mail from information services letting us know that they would be installing a dev build of FortiOS on our internal (production) corporate network.
In cases where we needed more debug logging from a feature or where we had a fix we had to test on a live network, and if we didn't want to ship a test firmware to some huge client and say 'here, see if this bricks your network or not', they would hand it off to our IT team and we'd install it on our own network to run. After all, if you're not confident enough to run it how can you be confident enough to ask your customers to run it?
Now if they could just get the hang of not hard-coding admin credentials into the software they'd have a lot to brag about!
Earlier quoted context omitted.
It doesn't matter that much. Trust me you could just have an LLM reverse engineer the obfuscated code.
The point is that a "secure coding platform" leaked something they were trying to keep under wraps, whether the contents of the leak matter or not. Also, as many others have pointed out, there is roadmap info in here that wouldn't be available in the production build.
Sure, but that's completely different from what they were responding to to, which was someone insinuating the Claude Code CLI has secret sauce that makes it better than the competition.
Earlier quoted context omitted.
Yes, this is a trend I've noticed strongly with Claude code—it really struggles to explain why . Especially in PR descriptions, it has a strong bias to just summarize the commits and not explain at all why the PR exists.
The question "why" is always answered with post-hoc rationalizations. This applies to both LLMs and humans.
Earlier quoted context omitted.
We already have it and we use it to validate the trusted human maintainer involvement behind the linux packages that power the entire internet: PGP Web Of Trust. Still works as designed and I still go to keysigning parties in person.
Say a regular human wanted to join and prove their humanhood status (expanding the web of trust). How would they go about that? What is the theoretical ceiling on the rate of expansion of this implementation?
From there they set up their workstation tools to sign every ssh connection, git push, commit, merge, review, secret decryption, and release signature with their PGP smartcard which is all very well supported. This offers massive damage control if you get malware on their system, in addition to preventing online impersonation.
From there they ideally link it to all their online accounts with keyoxide to make it easy to verify as a single long lived identity, then start seeking out key signing parties locally or at tech conferences, hackerspaces etc.
We run one at CCC most years at the Church Of Cryptography.
Think of it like a long term digital passport that requires a few signatures by an international set of human notarys before anyone significantly trusts it.
Yes it requires a manual set of human steps anchored to human reputation online and offline, which is a doorway swarms of made up AI bot identities cannot pass through.
Do I expect most humans to do this? Absolutely not. However I consider it _negligent_ for any maintainer of a widely used open source software project to _not_ do this or they risk an impersonator pushing malware to their users.
No idea on theoretical rate of expansion but all the major security conscious classic linux distros mandate this for all maintainers. There are only maybe 20k people on earth that significantly contribute to FOSS internet foundations and Linux distros, so it scales just fine there.
Note: with the exception of stagex, most modern distros like alpine and nix have a yolo wikipedia style trust model, so never ever use those in production.
Earlier quoted context omitted.
It doesn't matter that much. Trust me you could just have an LLM reverse engineer the obfuscated code.
yeah it actually works to use claude to reverse engineer itself; I've used that to workaround some problems. E.g. that's how I discovered that I had to put two slashes for absolute paths in sandbox config. The thing is, the claude team is so quick that soon enough they add more and more features and fix more and more bugs that your workarounds become obsolete
My experience has been that they add far more bugs in every release than they fix
Earlier quoted context omitted.
You can prove the commits were signed by a key you once verified. It is your trust in those people which allows you to extend that to “no LLM” usage, but that’s reframing the conversation as one of trust, not human / machine. Which is (charitably) GPs point: stop framing this as machine vs human — assume (“accept”) that all text can be produced by machines and go from there: what now? That’s where your proposal is on…
I can prove that code was signed by a key that was verified to belong to a single human body by lots of in-person high reputation humans. How the code was authored, who cares, but I can prove it had multiple explicit cryptographic human signoffs before merge, and that is what matters in terms of quality control and supply chain attack resistance.
That’s what I mean by “you agree with the person to whom you replied”
Earlier quoted context omitted.
the claude code team ethos, as far as i’ve been lead to understand— which i agree with, mind you— is that there is no point in code-reviewing ai-generated code… simply update your spec(s) and regenerate. it is just a completely different way of interacting with the world. but it clearly works for them, so people throwing up their hands should at least take notice of the fact that they are absolutely not competing wit…
>there is no point in code-reviewing ai-generated code the idea that you should just blindly trust code you are responsible for without bothering to review it is ludicrous.