[Sleaker]

Maybe I just missed the boat on hashicorp and similar solutioning, but I find a lot of the solutions for working with multiple systems using an intermediary shared language, such as terraform, end up obfuscating the problems they intend to solve and result in people who deal with and support those systems on a daily basis having very little understanding of how to interact and troubleshoot the core infra that is being built up with those tools.

Yes, building those solutions requires a lot of expertise, but I've never found the tools to be worth engaging with over just using what the standard platform tools they abstract away were replacing. Then you add in the economic rug-pull scenarios that have happened when utilizing software like this and I wonder why everyone hops on the bandwagon so easily.

What is the company they're building trying to solve that system maintainers can't already do? Isn't this just rebuilding OS windowing?

[jerf]

At the risk of sounding like a booster, I have noodled over whether this is a place that AI can legitimately provide some improvements. It's harder than just waving an AI at the problem, which is why we don't really have this yet. But one of the major issues with the intermediary language you're talking about is the rigidity of conventionally-applied programming. AI is a bit more flexible and gooey and more able to function as duct tape and bailing wire... but that does come with several tradeoffs of its own that need to be mitigated to some degree.

As a specific example of this, I've been using emacs since about 1997, but it's only this year that I've started down this sort of "integrate everything" road that it promises, because I've never wanted to learn emacs' specific Lisp variant that is used nowhere else. But now with AI I've done more emacs extensions that are providing real value to me than I have in the last... ever. About my previous limit was reifying a keyboard macro into a command, which still isn't really programming emacs.

The ability to indicate "intent" in a way that computers can actually process it as "intent" might change the calculus enough to make this more possible than it used to be in the past.

But those tradeoffs are real. Non-determinism is a problem. Difficulty in knowing what the AI is doing unless you're staring at its output, and even the ability to conceivably monitor an AI's output is only a transient thing we have at the moment, they'll speed up past our ability to monitor them at all soon enough. But it's at least a new area that can be explored and there may be solutions to some problems in there we couldn't reach before.

[sigbottle]

Looking really cynically, it does seem like it might transition into some kind of cloud-development situation. Your "one access to all development" is one ssh away from our mega 24/7 online compute farm, since we need to keep the sessions persistent. But you can access anything you want!

Hopefully that's not the endgame?

[CapsAdmin]

That was pretty much my takeaway from reading the website. Not my cup of tea, but I guess it might valuable to some?

I've had to use the aws cli at work a few times (not an expert), but I could see aws trying to compete here if this becomes a thing.

[sbarre]

There is value in abstracting the underlying generic systems into more context-relevant primitives for people who just want to get shit done in that context.

Why not meet people where they are at?

If this product isn't valuable, then it will fail. I suspect it will not fail.

[Sleaker]

I get that premise, I guess I've just been around a lot of bad engineers that use these types of tools as crutches but can't actually articulate or diagnose problems well. They just regurgitate the syntax like it's a magic spell.

[sbarre]

Does that apply here?

We're talking about abstracting generic OS windowing/multiplexing for what sounds like an agent-based development workflow modality where you're referring to what's happening in the panes/tabs/windows instead of the containers themselves.

We're not talking about software abstractions.