Btw for real tho, if you don't have the time or means to mess with full sandboxed environments, just working within a git repo and instructing on your agents.md project level that the agent should back up dirty files (local changes that were not yet committed) before changing them is enough and super fast and easy to set up. And by back up I just mean a simple instruction to back up to some temp location under random named, but rembered during one "turn" of agent thinking, subfolder ( .../temp/{random}/orginal/tree/file.xyz )
This is so the agent (or you later) can recover even locally changed files if it messes them up for whatever reason.
As for the rest you gotta watch what you're asking for, but generally speaking, these SOTA models are smart, none of them will just delete your stuff even with full access. I've been raw dogging multiple projects on my work machine with zero issues of this kind for months. I created codex_reader read only acccounts for my local databases and just add that to agents.md with a note its allowed to only use that and never had a problem.
I read posts like these all the time and I keep wondering when they'll begin to tighten the screws on the prosumers. I think most, if not all, $200/mo individual accounts are blasting high multiples of that amount in tokens. I mean we know that doesn't work with current inference costs, not by a longshot, so I guess this is just a way to pad their numbers like "look, we're growing our user base!" while they can still somewhat hide the "actually, we're hemorrhaging money on inference" in their accounting.
> If the US really cracks down on frontier model access, you'll see them make Chinese open models illegal.
We don't give a fuck about US laws - respectfully, the rest of the planet.
We're already sick of your shit and this will only add to it. Just look at the Iran shit show. What a joke. Ooooooo wooooooo sanctionzzz scary. Sanctions only work if they're enforceable.
Con or not it is an obvious thing they have to do. Might as well promise.
IIRC their biggest cost they're "hiding" in their financials by doing creative accounting is inference (putting it into marketing and whatnot, in the billions)... if they can't hide it in their S-1 then they have to rationalize it, either by a) increasing the prices (not gonna happen, with token based billing orgs are already watching their codex spends) or b) lowering the inference costs. You can lower that by "soft optimizing" (dumbing down) your models but then you have the other players breathing down your neck (see quick rise of Claude), or actually optimizing, in software and in hardware. We're like 5 years into the rise of LLMs, there's not THAT much left on the table unless you write to the metal you specifically designed for your models (and I'm pretty sure the lack of "nvidia tax" would help with covering most of the r&d costs of a custom solution, at least in the long term).
50% cheaper inference without losses in fidelity would unquestionably be a massive win for OpenAI.
That is not why people use Electron. The goal is not and never was to just be a "UI toolkit" and "adopting UI patterns from their host OS".
Chromium has so much stuff packed into it, its insane. All that utility comes with Electron. And that's a good thing.
If you ever worked with video, for example, you know that having the full power of a modern browser in a desktop app is a game changer. Video playback (not to mention transcoding, which is also possible with modern web and webcodecs) is a complex beast, implementing that yourself is massive undertaking, not to mention in a desktop app that is supposed to work on win/mac/lin. I've built apps with Electron in tens of hours that would otherwise take me tens of days or more (and thats with AI because I'm not a video expert).
Careful, someone may drop another whine article about HN being anti-ai (meanwhile nothing can be further from the truth, HN is one of the most, if not THE most, pro-AI news agg sites out there)
Not sure about Docker (lol) but stakeholders are definitely more open to "building your own" now. It used to be that to be agile as a business you would seek out already built software and rent it, as it typically was cheaper than building and maintaining your own (I say typically due to stuff like vendor lock-in and such). But these days, and especially in 2026 with the widespread use of agents and harnesses, that formula has started to change. Even though the SOTA models are really good now, it's the harness and the "fluff" around the model that makes it a game changer. The developer is no longer the one writing or even gluing the code together, the harness does that. Pair that with context preserving mechanisms and tools that emerged (automatic context compaction, AGENTS, TOOLS, MCP...) and you can get to a state where you start a new thread in Codex and it knows your systems, your dbs, can smartly explore code it doesn't know and db data patterns etc., it can explain stuff to a new developer (and be correct most of the time and have time to spend on the developer)... all of which SIGNIFICANTLY reduces the risk you take on yourself as a company when you "build your own". What's $10k/year to any half-working semi-profitable company? Nothing. But in 2026, you can build and maintain A TON of software for that, much more than your "average IT needs" company may ever use.
I'm sure the very large (and very small) businesses will keep their absolute need for (or the lack of) inhouse developers, but everything in between will probably get compressed to one or two inhouse architects in direct contact with the stakeholders and the rest will be contractors working with Codex-like automation.
> the maintainers are equally capable of prompting Claude Code themselves
I'm 100% on the side of maintainers here, but this is BS. If you could "just prompt Claude yourself" the AI productivity boosts would be in hundreds if not thousands of percent, which is demonstrably and self-evidently not the case (at least as of June 2026).
Doesn't need to be the Chinese. It can be anyone without stratospheric Nvidia margins. The Gold Rush phase of AI economy (aka "the bubble") is beginning to slow down and the Optimization phase is just beginning to ramp up (we see this with massive bumps to token cost and token burn rate of pretty much all frontier models, plus the general pivot away from your typical individual chat end-users to businesses and employees of said businesses) and there will come a time when "nvidia has the best software stack" will not mean much for the big players. Organically, I think it already kinda does, it's just masked with the inertia of massive circular deals and Nvidia selling its services to itself (entities it backs/invests in).
This is not meant as an insult, but have you actually LLM/vibe coded anything that used a fast(-ish) moving library or framework? Try asking your favorite LLM with say Jan 2025 knowledge cutoff (or pretraining data cutoff, whatever you want to call it) to work on something using a framework that had a big rewrite later that year (which would make it one year old now, which is like ages in the LLM coding era)... It's a nightmare full of wrestling with the LLM when you try to tell it the version of the framework and that it changed a lot from the previous version and yadda yadda long story short down the thread when context runs out and/or is compressed it begins to forget detailed instructions and just falls back to pulling out old patterns it "remembers" from pretraining. And so you need to constantly remind it what you work with and "oh hey this doesnt work because we're working with react router v7 in framework mode, remember? not react router v6". Or try to use the latest non-lts/breaking version of a library, at first it looks it up online, but again as you get deeper into the weeds and little details, the struggle begins.
So, as far as I'm concerned, training cutoff is still a big deal.