If, by your definition of understanding, you can understand something without knowing how it works, then what would be the point in understanding it?
Your argument underscores the fact that understanding exists on a spectrum and that deep understanding can be difficult, or even impossible to achieve. Even formal verification seeks to verify certain properties of a system, and doesn't represent anything close to comprehensive understanding, and the process of formal verification is also guided by a fallible human. In a lot of ways, formal verification is just pushing up to review of a different "programming language."
So, good review is really hard, but ignoring the difficulty doesn't make it go away.
I think you just made some strong arguments for classifying them as gatekeepers. The idea, like you said, is to make it so that competitors can enter the market and pick up the slack in areas where AWS and Azure are dropping the ball.
> software was already in a horrible state before AI, so your dichotomy doesn't work.
It depends on the software. But, generally speaking, I try to use and write the best software available that solves my problem, even if it's one of a kind; it doesn't really matter if the other 99.9999% of the software in the space is broken.
Given 1000 hours to work on a problem, an LLM will continue to yeet out mediocre variations on a theme. Give me 1000 hours to work, and my product will keep getting 1% or 2% better until it's much better than any shit an LLM would spit out.
Similarly, I would much rather use someone else's emulator that they spent 1000 hours on than have AI yeet out some mediocre shit that kinda works, but is really just a mindless exploitation of something that someone else wrote that was actually good.
Then, you follow that with, "Yeah, but AI just allows you to iterate faster and skip the boring stuff, so that you make your product better even faster."
And then I follow that with, "The part where you take it apart piece by piece and study each piece and get kicked in the head by the realities of your lack of understanding is the part that's actually valuable, and it's precisely what you're skipping with an LLM"
I would much rather have software that works but lacks accessibility features than software that's broken but also has some broken accessibility features sprinkled in. The former is useful to many people, while the latter is useful to no one.
But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.
What makes you say that AI is not going anywhere? I hear this overwhelmingly, "AI is here to stay", as if y'all are so caught up in the movement that you've started taking that conclusion as being the axiom. TBH, it feels like a religion.
"If you travelled back in time, the coastline itself would be unrecognisable to modern eyes. In the Jurassic Period, most of what later became Britain was under the sea, apart from Scotland, East Anglia and a series of small islands in the southwest."
It's clear that the article is mostly talking about the reader's ability to interpret figuratively, regardless of the specific reference. However, I'm not even sure it's a biblical reference, because I think dinosaurs are generally incompatible with the story of Noah's Arc. I'm guessing it's probably more along the lines of some theory of continental movement that was prevalent at the time. Maybe it's just a weird mismash of dinosaurs and Noah's Arc, though?
> if all the water left, it could be dry like a desert too
This is just a contextual interpretation thing. It's clear that's not what he means because he says it's muddy, so it must be the other thing. Also, it becoming a desert is more extreme, so in that case the writer would probably offer up a more detailed explanation.
Someone saying they vibe coded a thing is like them saying they were hammered when they wrote it. Maybe they did a great job, but probably not; it's definitely cause for concern.
Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions.
So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.
Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.
I think that's kind of the point though: AI is the sand, but it's the rocks that hold all of the value; the further you get away from using AI the more real value you obtain. Like, a few of the rocks have gold deposits in them, and the sand is just infinitely copious but never holds anything valuable. And you've got a bunch of people running around saying, "Behold my mountains of sand!"
IIRC, you can do git branch -D $(git branch) and git will refuse to delete your current branch. Kind of the lazy way. I never work off of master/main, and usually when I need to look at them I checkout the remote branches instead.
This issue exists with the parsed case, too. If you're using a database to store data, then the lifecycle of that data is in question as soon as it's used outside of a transaction.
We know that external systems provide certain guarantees, and we rely on them and reason about them, but we unfortunately cannot shove all of our reasoning into the type system.
Indeed, under the hood, everything _is_ just a big blob that gets passed around and referenced, and the compiler is also just a system that enforces preconditions about that data.
I think, more generally, "push effects to the edges" which includes validation effects like reporting errors or crashing the program. If you, hypothetically, kept all of your runtime data in a big blob, but validated its structure right when you created it, then you could pass around that blob as an opaque representation. You could then later deserialize that blob and use it and everything would still be fine -- you'd just be carrying around the validation as a precondition rather than explicitly creating another representation for it. You could even use phantom types to carry around some of the semantics of your preconditions.
Point being: I think the rule is slightly more general, although this explanation is probably more intuitive.
Your argument underscores the fact that understanding exists on a spectrum and that deep understanding can be difficult, or even impossible to achieve. Even formal verification seeks to verify certain properties of a system, and doesn't represent anything close to comprehensive understanding, and the process of formal verification is also guided by a fallible human. In a lot of ways, formal verification is just pushing up to review of a different "programming language."
So, good review is really hard, but ignoring the difficulty doesn't make it go away.