I think we are about to see much stronger weight given to accounts created prior to a certain date. This won’t be the only criteria certainly, but it will be one of them, as people struggle to separate signal from noise.
There's a huge amount of valuable content in the article. People saying silly nonsense like '10k words for "migrating code and data is a headache"' missed out on all of it--which may well be fine for them because not everyone needs to know these things, but this is an excellent article for those who do. And rejecting this article because an LLM may have been involved is irrational ideology.
My biggest problem with the article is the title, which is somewhat the inverse of clickbait--functional programmers are his apparent intended audience but the content is much broader.
Thank you for writing/publishing this. I especially appreciate the prominent warning at the top not to mistake it for a production library and to suggest an alternative. (It’s surprising to me how often people forget to add disclaimers like that to their code.)
I agree with you, but I don't envy the maintainers. The problem is that it's really hard to tell if someone is skilled like you or just shoveling what an LLM wrote up to the maintainers to have them "figure it out." Honestly, getting a library hard forked and maintained by people that can keep up with the incoming PRs would be a relief to a lot of folks...
Oh, to be clear, there’s no way we’d want incoming code for these forks.
Incoming bug reports or design docs an LLM could implement? Sure.
Maybe something like the Linux approach (tree of well-tested, thematic branches from lieutenants) would work better. We’d be happy to be lieutenants that shepherded our forks back to upstream.
Thank you for matchlock! I’ve got Opus 4.6 red teaming it right now. ;)
I think a secure VM is a necessary baseline, and the days of env files with a big bundle of unscoped secrets are a thing of the past, so I like the base features you built in.
I’d love to hear more about the red team breakouts you’ve seen if you have time.
curious what Opus 4.6 tries - I'd guess it goes for the usual suspects (path traversal, symlink games, timing attacks on the network proxy) but curious if it finds anything novel. the env file point is interesting though - agents need some secrets to be useful, but the attack surface gets wild when you consider that the agent itself might be compromised before it even touches your credentials. I keep thinking about this for my own stuff - like do you rotate secrets per-session? pre-authorize specific API calls? feels like we need better primitives than just "here's a bundle of keys, try not to leak them"
Ugh - yes. I’m seriously close to writing a chrome extension just to warn me or block pages that have that phrase…it’s irrational because there are so many legitimate uses, but they are dead to me.
I don't know man, I feel emboldened to keep using emdash exactly because I want to protest against people equating emdash with "AI reply" even though there are very legitimate uses for emdash.
This looks really cool and genuinely useful. I was about to submit this after seeing the mention in another thread!
Before I read your last line, I was about to ask about network sandboxing. I don’t know what the ideal feature set is, but I keep wanting a proxy or network filter that mitigates some of the “dumb” attack vectors for LLMs…
Thanks! For network sandboxing, I was thinking something like what Little Snitch can do, but more customized... maybe block POST requests and long GET request strings or anything that looks like too much code or secrets.
I’ll take a stab after just reading documentation. I’ve been waiting for a good open source “wrapper” for Claude Code that allows me to run it somewhere and expose it as an API to be driven by a thin client elsewhere, and this appears to be that.
Furthermore, it exposes both the main session manager API, allowing it to spawn new sessions, as well as the API to chat with any given session directly. (Many wrappers allow you to wrap a single Claude code session in an API, driven by tmux under the covers, but don’t expose the meta-API to manage the sessions themselves)
I would use it to write a mobile or web client for my “agents” running remotely, either on sprites.dev, or on my MacBook over tailscale. (I currently use a mobile terminal for this, and have a list of Claude Code wrappers to try, but this “feels” like a cleaner abstraction primitive to build around.)
The above might be wishful thinking on my part, but hopefully the OP will correct me.
reply