You actually do need some understanding of how a car works, no?
For example, you need to know it uses gasoline (or diesel), it requires oil changes every certain amount of time, break pad replacement, etc.
You also probably need to know that you can't operate cars over a certain amount of water, that you need a driver's license, stopping at red lights, etc.
Sure, you might not need to be a mechanic, but that's far from not understanding how a car works, which to me sounds similar to knowing how to shoe a horse, which is different than being a horse vet.
Isn't that kinda how we got the plastic pollution problem in the ocean?
At first, the ocean seems immense. So much so that dumping plastic and toxic chemicals makes no difference.
But then we humans are great at scaling things it seems, such that at some point ocean plastic pollution became a real problem.
I know that space is much much bigger than our oceans, but I wouldn't underestimate the ability of mankind to scale launches to the point where debris becomes a problem.
Maybe I stated it wrong. Macaroons have the ability to attenuate the restrictions _without_ contacting the auth server, which makes it IMO fit for restricting and attenuating as much as you want, without much cost.
If I need a roundtrip to the auth server to attenuate, I am not necessarily going to do it as often.
I am still waiting for Macaroons to be used widely. I think they are a fantastic invention.
It seems they were not of very much use in the past, but with the agentic-everything now, I see this as a great way of delegating permissions to subagents, third-party agents, etc.
Working on something along these lines but unfortunately I cannot dedicate as much time as I'd like.
Still, if anyone is reading, give Macaroons a try!
"Hello, world! Welcome to the classic programming greeting. It is the traditional test message used to introduce beginners to computer science and verify that a language's syntax is properly understood"
Which clearly shows that there will be an avalanche of issues when non-technical people discover the joys of non-deterministic results.
Conversely, you have "full ownership" and have the ability to decide the direction, as long as it's the same direction as your higher-ups have decided.
From past experiences (and I'm sure I'm not alone here), I can almost guarantee that the senior devs did communicate the problems, but they were ignored or brushed aside.
Very seldomly does middle/upper management truly listens to engineers, unless there's buy-in from the CTO/VP to champion the ideas and complaints.
I've always thought I was the only one experiencing this and felt like I was crazy.
I guess it's "good" to know that I'm not alone.
The amount of times I've searched for a ticket that I know it's there (because I either have it opened in a different tab, or because I just created it), but can't find, it's just way to many.
Personally, I've used LLMs to debug hard-to-track code issues and AWS issues among other things.
Regardless of whether that was done via next-token prediction or not, it definitely looked like AGI, or at least very close to it.
Is it infallible? Not by a long shot. I always have to double-check everything, but at least it gave me solid starting points to figure out said issues.
It would've taken me probably weeks to find out without LLMd instead of the 1 or 2 hours it did.
In that context, I have a hard time thinking how would a "real" AGI system look like, that it's not the current one.
Not saying current LLMs are unequivocally AGI, but they are darn close for sure IMO.
Yeah, that was my understanding as well, so I fail to see how a proper SOC2 would have prevented this.
I mean ideally a proper SOC2 would mean there are processes in place to reduce the likelihood of this happening, and then also processes to recover from if it did ended up happening.
But the end result could've been essentially the same.