fortuitous-frog

Yep. Was very confused about the title and URL slug; reached the end waiting for Pandas to be mentioned.

Oh wow, what a surprise! I learned a lot from that article, and often referenced and sent it to my colleagues on my old team. Thank _you_ for writing it!

If you want the slop-free inspiration (2022): https://home.robusta.dev/blog/stop-using-cpu-limits

(The title of this was also stolen for this HN post, although the GitHub repo makes no mention of it...)

Bun and the Rust pre-release have continued to be open source; the pre-release isn’t exclusive to Claude Code but available to anyone to download and use. There hasn’t been any public motion to indicate they may close source anytime soon. This FUD is so easily fact-checkable that I’m genuinely confused at how it caught on

No normative opinion on whether this is justified or not, but noting that this is only for parent -> subagent spawns/messages, and only for the `multi_agent_v2` feature (currently experimental / off by default).

Notably, subagent output is still in plaintext.

EDIT: Title was now clarified. But wanted to expand that this is actually enabled for 5.6 Ultra it appears, which does subagent orchestration more natively in the API rather than direct tool calls; they are beginning to treat subagents as similar to chain-of-thought traces (already encrypted) rather than traditional tool calls.

Homomorphic encryption for LLMs is extremely expensive and nowhere near computationally possible for the scale of current LLMs.

I can’t speak for other companies, but I worked at Epic for a few years (left last year), and indeed MUMPS is still their bread and butter. In fact, I had not even heard about ObjectScript until reading this thread.

A few years ago, they _did_ develop a TypeScript wrapper framework (which was transpiled down into MUMPS). They heavily encouraged newer application code to use this, but it never caught on, was quietly abandoned after a bit.

Internally, MUMPS was often criticized or laughed at, but I doubt it’s going anywhere anytime soon.

For the curious, newer versions of MUMPS are still used as the core database framework by a lot of electronic health records companies. Most notably, it’s the backbone of Epic Systems, the largest EHR company in the US.

This seemed familiar? The first few lines/commands are a straight copy and paste of a post that reached front page 8 months back: https://maurycyz.com/misc/easy_git/ (HN post [here](https://news.ycombinator.com/item?id=45710721)). The rest is just AI rewording. Even the quips about wiring this up to the blog's site generator are stolen. Even the _date format_ (which is different from the rest of the sites blogs) is stolen.

However, this does not look affiliated at all with the real author's blog. Exploring this vercel site, looks like they rip dozens of creators blog posts day for SEO spam? And for what? Their homepage (and its non-functional demo) is just for a link preview feature? Something that many browsers already provide natively (and if not, you can just use the many existing browser extensions for this)?

Is this a giant spyware/malware promotion? I'm very confused.

OP (https://news.ycombinator.com/user?id=sheelagay) seems to be affiliated with the page and seems to be only posting this for the last few months; their first post is promoting/showcasing the "product".

I used to use a symlink but was concerned that Claude might see the presence of an "AGENTS.md" file (in e.g, a "List Files" tool call output or from a direct `ls`), be curious and attempt to read it directly (not knowing that it's the same as the "CLAUDE.md" file auto-injected by the harness), and essentially double the token impact / context bloat. Indeed, I did some local experimentation and noticed this was the case, which is why I switched to the explicit "@AGENTS.md" approach.

So perhaps there's no need to be rude about it :)

Looks largely AI-written, with some human edits: https://www.pangram.com/history/9afe7542-1085-4264-9691-2172...

FWIW -- I'm not as repulsed by it as the parent comment. But I do want to substantiate that it _is_ heavily LLM-written.

(If you're unfamiliar, Pangram has garnered a reputation as the leading LLM-detector, with a minimal rate of false positives; IME this has come with the tradeoff of being easy to manipulate/tweak your way into turning an LLM-generated piece of text into reporting a false negative, but for most folks that's worthwhile.)

FYI this program is ~3 months old, and Anthropic has a similar Claude for Open Source program (see https://claude.com/contact-sales/claude-for-oss).

Interesting that (1) this blog post published on April 10th, 10 days after the Axios compromise, and (2) this was emailed to ChatGPT / Codex users yesterday, April 21st, 11 days after the blog post...

After an incident as widely publicized as Axios, I'd expect dependency auditing, credential rotation, and public incident communication to all be carried out with much more urgency. And if they were going to send this out to all of their users (as they should), I would expect _that_ to happen shortly after publishing the post (why wait 11 days???).

Did you investigate the maintainer compromise and publication path? The malicious version was never committed or pushed via git. The maintainer signs his commits, and v1 releases were using OIDC and provenance attestations. The malicious package versions were published locally using the npm cli after the maintainer's machine was compromised via a RAT; there's no way for package maintainers to disable/forbid local publication on npmjs.

It seems the Axios team was largely practicing what you're preaching. To the extent they aren't: it still wouldn't have prevented this compromise.

No. axios (v1 at least; not v0) were setup to publish via OIDC, but there's no option on npmjs for package maintainers to restrict their package to *only* using OIDC. The maintainer says his machine was infected via RAT, so if he was using software-based 2FA, nothing could have prevented this.

I don't think it's a coincidence that a lot of the (stale) tooling that Astral replaced were managed by foundations instead of companies...

I suppose my point is: I would expect that Charlie and co. carried their negotiations with OpenAI with the same laser-focused, careful judgment that catapulted Astral to success in the first place. I don't mean to fanboy, but I generally trust that they made the best decision for not only them, but the Python community as a whole.

Curious how well upstream contributors or projects get contributed for these sort of headline-gathering acquisitions (probably not at all, unfortunately).

OpenClaw notably was built around Mario Zechner's pi[0]; uv I believe was highly adapted from Armin Ronacher's rye[1], and uses indygreg's python-build-standalone[2] for distributing Python builds (both of which were eventually transferred to Astral).

[0]: https://github.com/badlogic/pi-mono

[1]: https://github.com/astral-sh/rye

[2]: https://github.com/astral-sh/python-build-standalone

While I -- like most other commenters -- am dubious of both OpenAI and this acquisition, I think it's pretty reasonable to wait to see how this turns out before rushing to final judgment.

Everything I've seen from Astral and Charlie indicates they're brilliant, caring, and overall reasonable folks. I think it's unfair to jump to call them sell-outs and cast uv and the rest as doomed projects.

I'm also concerned about this, but I feel as though uv and ruff's explosive growth happening alongside and despite that of LLMs demonstrates that it's not a show-stopper. I vividly recall LLM coding agents defaulting to pip/poetry and black/flake8, etc. for new projects. It still does that to some extent, but I see them using uv and ruff by default -- without any steering from me -- with far greater frequency.

Perhaps it's naive optimism, but I generally have hope that new and improved tools will continue to gain adoption and shine through in the training data, especially as post-training and continual learning improve.

The author of pre-commit is known to be pretty hostile :p You should make an issue for prek though!

There's a config option for that :) https://prek.j178.dev/configuration/#default_install_hook_ty...

They're very commonly used in CI. There are dedicated GitHub actions for pre-commit and prek, but most commonly people just invoke something like `prek run --all-files` or `pre-commit run --all-files` in their typical lint CI jobs.

The prek documentation has a list of many large projects (such as CPython and FastAPI, to name a few) who use it; each link is a PR of how they integrated it into CI if you want to see more: https://prek.j178.dev/#who-is-using-prek