Many places have "dev", "test" "prod"... but IMHO you need "sandpit" as well.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Sandpit should be a personal (often local, if possible) dev environment. The reason people get mad about dev being broken for long periods of time is that they cannot use dev to test their changes if your code (that they depend on) is broken in dev for long periods of time.
There’s no sandpit, only prod and dev, and you’re not allowed to break prod. Your developers work in partitions of prod. Dev is used for DR and other infra testing.
Hey, I get it. I don't want LLMs on prod at all. I made this to let agents connect to production cloned sandboxes, not production itself. I hope this helps your concerns, but I understand either way. Lmk with any other questions.
For example, if you had an on-prem footprint with thousands of VMs, a production cloned sandbox would be a clone of a VM to let AI safely make changes, install packages, etc.
Yeah, working on the landing page. Feel free to ask any other questions!
Microsoft defected, now the correct move for the customer is to defect. Really, based on the pattern they learned, they can defect a thousand times before they lose enough customers over it that they have to publicly apologize and reverse a feature, so customers stepping in mid-game think that there's a tit for tat happening, but they don't realize they're starting off in the hole. We all should have left Microsoft a very long time ago.
That depends on how you define risk. If it means the probability of a collision, then you'd be correct. But if a collision does happen, the consequences will be worse than being in the same orbit. Based on an oversimplified model, debris in orbit is likely to have low relative velocities with respect to an intact satellite in the same orbit, since a large deltav would change the orbit. (It's not as simple as this, but it's good enough in practice.)
This is actually what asat weapons take advantage of. They usually don't even reach orbital velocity, just like ballistic missiles (of course, there are exceptions like the golden dome monstrosity). The kill vehicle just maneuvers itself into the path of the satellite and lets the satellite plough into it at hypervelocity.
I remember a short story about Canada preventing total global annihilation in WWIII, by deliberately triggering Kessler syndrome. My google-fu is failing me though.
Because types are important and having them be a native part of the language creates opportunities for error checking, editor completions, and LLM bounding.
I’m not sold that config is a complex enough domain to necessitate another language. What problems is CUE solving when compared to python and why are those problems substantial enough to make it worth learning a new language?
Given that we now have TOML, JSON, INI, CSV, YAML, etc it seems we are converging on either JSON, YAML or TOML. There is too much inertia behind those three and not much behind CUE right now.
CUE works with all of those languages, so it doesn't matter what the tools or others are using. I can always apply CUE at any point to output their required format as needed.
Keep your legacy config and mess if you want, you're the one missing out
Also, I don't see TOML in the wild enough and the others have been around long enough, I must chuckle and not take seriously these claims about "inertia"
I’m not claiming inertia makes TOML ‘best’, just that it’s clearly not blocked by inertia either. Cargo standardized on TOML years ago, and GitLab Runner has relied on it for a long time. If a format can win in major ecosystems, “people won’t adopt anything new” isn’t the whole story.”
Can GitHub change their API response rate? Can they increase it? If they do, they’ll break my code ‘cause it expects to receive responses at least after 1200ms. Any faster than that and I get race conditions. I selected the 1200ms number by measuring response rates.
No, you would call me a moron and tell me to go pound sand.
Not surprising. Take any conference and look at the schedule of some CEO or other “socialite” attending said conference. They’re not in the building, they’re running around town attending meetings. At JPMHC everyone is a “socialite”
At no point in history has humanity ever cut back on spending after some constraint got alleviated. Exact opposite, we always ramp spending up to chase new possibilities.
If A.I maximalism gospel was true we would see companies raising absurd seed and A rounds in record numbers. Which is exactly what we’re seeing
I see no point in making this a numbers game. (Like, I was supposed to say "five" or something?)
Let's make it more of a category thing: when AI shows itself responsible for a new category of life-saving technique, like a cure for cancer or Alzheimer's, then I'd have to reconsider.
(And even then, it will be balanced against rising sea levels, extinctions, and other energy use effects.)
Search through github for commits authored by .edu, .ac.uk etc emails and spend a few days understanding what they’ve been building the past few years. Once you’ve picked your jaw off the floor, take another 10 minutes to appreciate that this is just the public code by some researchers, and is crumbs compared to what is being built right now behind closed doors.
Tenured professors are abdicating their teaching positions to work on startups. Commercial labs are pouring billions into tech that was unreachable just a few years ago. Academic labs are downscaling their interns 20x. Historically hermit companies are opening their doors to build partnerships in industry.
The scale of what is happening is difficult to comprehend.
reply