This is precisely why I run a custom fork of CLIProxyAPI on a private railway server for all my agentic coding. The OG version is indispensable already and has XAI Oauth support, so you can use your subscription to call Grok from any Anthropic OR OpenAI compatible client (Claude Code, Pi, Codex, you name it). To be honest, though, I am bummed, as I do really like the grok build client. The TUI is great in the ways that matter without going out of its way to make it clear that "I'M A MID-LATE 2020s TUI LOOK AT ALL THE NOT USUAL STUFF YOU CAN DO WITH ME".
Grok aside, this has become an increasingly large concern of mine, especially now that I've expanded my usual provider rotation beyond the big 2. Out of arguably reasonable paranoia, I recently bolstered my own personal CLIProxyAPI fork to use an algo similar to gitleaks/betterleaks to, on the fly, scan the incoming (i.e. from my coding agent) stream for any secrets that may have been transmitted from disk, replace them with a unique identifier, send that off to the upstream provider, and then replace the secret (mapped to that identifier in memory, encrypted and with TTL) before sending any response back. That way, if the "secret" is either not really a secret and/or truly is needed in whatever tool call or response, the replacement is seamless to the client but the provider never sees your code.
No, it's not foolproof: it can't prevent some upstream actor from, say, using the on-disk key to your secret in a rogue tool call that uploads it from your device directly to an endpoint of theirs, but the low-hanging fruit like this is, IMO, the equivalent of not leaving all your windows open when you're naked. Virtually no downside or inconvenience to you, gets probably 3-4 9s of cases where someone would be inclined to see something they shouldn't because it's that easy.
The alternative is literally having to approve every read request (is this even a thing now?) and spend the mental energy ensuring that each and every file could not possibly contain a secret. I'd rather just code by hand at that point.
I agree 100%. I've been the resident 'tech guy' among my friends and family for as long as I can remember, and I thought that LLMs would be the definite end to all 'blurry picture of computer screen captioned with "what should I do"' texts, yet that didn't seem to be the case. In fact, LLMs made it worse, as it actually made me seem more knowledgeable; I would be the one asking AI on their behalf and responding with beautifully formatted, easy to understand answers, encouraging them to ask me more.
I chuckled because, as a joke to express my frustration about this, I made a website called djfa.ai (Dude, Just Fucking Ask AI), which is essentially LMGTFY for ChatGPT. As one can imagine, the gimmick wore off rather quickly with my loved ones (turns out moms of nerds sometimes ask their children tech questions because they miss their voice). I ended up haphazardly turning it into my personal blog, which I sometimes choose to abbreviate and sometimes not on my resume.
I would never have made it in the first place had most of the people asking me questions been like Yael: seeking my informed opinion on thought-provoking questions they'd already researched. Going back to your larger point about the social aspect of it all, even among my wife and my social group, "just ask Claude" is almost the new "I don't really know" or "that's a tough one" when it comes to any sort of question. Almost colloquial in the sense that it isn't to be taken literally, but more as an indication of uncertainty.
have you tried 5.2? I agree that 5.1 and prior were below Kimi, Mimo, Qwen, Minimax, and probably Deepseek (depending on task), but 5.2 (especially unquantized) feels like something else.
Now I feel like that I'm covered by GLM 5.2 and Minimax M3 (when I need vision or a second pass on something).
Highly agree with much of the article. IMO, this is why many engineers who learned to code in the post-2010 'new hot framework every week' era but before LLM coding took hold are able to get much better results from AI assisted coding than those on either end of that sweet spot. The domain expertise in this case is constantly having to adapt to learning the latest flavor of the week DB or JS framework and adapt existing patterns and paradigms to new ones. Agentic coding itself is, in this case, one of those new paradigms.
Knowing the caveats and pitfalls of this through years of (often-painful) experience is what, at least for me, allows me to preempt a lot of the sloppy assumptions or omissions that even the frontier models make when working on systems at scale. This means I can leverage my domain expertise on these high-level areas while delegating the grunt work that is harder to screw up to the agents. I find this enables me to work faster while avoiding the slop making its way into critical engineering decisions.
100%. I think I hadn't fully internalized the open source vs trademark ethe (TIL that's the disputed plural of ethos) in my head. I had two nightmare scenarios: the first was where people would say "you copied Notepad++ and didn't give enough attribution, you're a thief!" and the other where...what happened here happened.
I think this was just about as close as I could get to asking Don Ho directly how he would prefer a port to be handled without actually doing so. I plan on publishing it shortly after cleaning up some God objects :)
The timing of this is very funny for me, personally. After the Claude Code Rust re-implementation, I wanted to see how far I could push 'spec-driven development' by re-implementing Notepad++ for Linux. I used four agentic loops to draft detailed from the source, implement the code, write tests to fix regressions, and compare the result with the original source. I then re-themed it and actually came out pretty well.
I initially worried that a brand new name (I went with nootpad) might misleadingly suggest the project was built from scratch rather than being a semi-clean-room re-implementation. Then, I saw that NPP was trademarked and my worries flipped the other direction; the reason I haven't yet published it was because I'm still removing all the NPP references from the source + comments in an abundance of caution, leaving a huge disclaimer/attribution in the README. I know that OSS is an opinionated place and didn't want to step on any toes.
I must say, having all of that anxiety and seeing this guy literally put Don Ho's picture on the website and say that it was being re-named "in collaboration with" Don Ho (i.e. not in response to a legal threat) made me laugh out loud.
Now that's a throwback and is definitely my goto on macOS. I remember I did a bunch of chores in order to buy a Visa gift card just to purchase it. Was much easier than explaining to my parents what SFTP was and why I needed to borrow their credit card. I just googled it and it's good to see they're still around.
Perhaps it's just nostalgia, but I feel like 2006-12 (before the Mac App Store took off) was the golden age of Mac software. There were those ~$100 'app packs' that bundled a bunch of different software together. You'd buy it for 2 or 3 of them and end up discovering some cool new software in the process.
After seeing how quickly those hooligans re-wrote Claude Code in Rust from the leaked sourcemap, I actually made a spec-driven Linux port using Claude Code, Kimi, and Codex just to see if it was possible.
Frankly, I thought I was the only human being on earth who used Arch but missed the comforting embrace of Notepad++, so I'm happy to share the fruits of my ~$200 worth of tokens if there's interest!
Grok aside, this has become an increasingly large concern of mine, especially now that I've expanded my usual provider rotation beyond the big 2. Out of arguably reasonable paranoia, I recently bolstered my own personal CLIProxyAPI fork to use an algo similar to gitleaks/betterleaks to, on the fly, scan the incoming (i.e. from my coding agent) stream for any secrets that may have been transmitted from disk, replace them with a unique identifier, send that off to the upstream provider, and then replace the secret (mapped to that identifier in memory, encrypted and with TTL) before sending any response back. That way, if the "secret" is either not really a secret and/or truly is needed in whatever tool call or response, the replacement is seamless to the client but the provider never sees your code.
No, it's not foolproof: it can't prevent some upstream actor from, say, using the on-disk key to your secret in a rogue tool call that uploads it from your device directly to an endpoint of theirs, but the low-hanging fruit like this is, IMO, the equivalent of not leaving all your windows open when you're naked. Virtually no downside or inconvenience to you, gets probably 3-4 9s of cases where someone would be inclined to see something they shouldn't because it's that easy.
The alternative is literally having to approve every read request (is this even a thing now?) and spend the mental energy ensuring that each and every file could not possibly contain a secret. I'd rather just code by hand at that point.