I don't think vibe coding is going to last long as a thing, because it's just a sort of intermediate step to telling the AI to do what you want and having it do that. Right now, people are telling the LLM to write code to accomplish a thing and then running the code to see how it works, then telling the LLM to refine it, but that's a lot of unnecessary extra steps. I'm sure that in the not-too-distant future people will just tell the LLM what they want to do, which may require creating a custom user interface to make user interaction convenient, and may require creating databases or performing network queries or whatever, and the LLM will understand what they want, and do it.

In that future, it's possible that the LLM may generate code to implement the requested functionality, but if it does so that will be a compute-saving shortcut, essentially a way to cache the LLM's work and be able to repeat it with less effort. There won't be any need to show any of the code to the user, or even tell the user that the LLM chose to generate some code.

As an aside, the whole notion of leaning "prompt engineering" is another intermediate step that will die. The whole point of natural language-capable AI is that it will be able to understand what humans want when we express ourselves as we would to other humans. As the LLMs get more capable, it will become less necessary to treat them as something different from an entity that is fully capable of understanding and acting on human communication.

One of the things Android did very right with the Rust transition was to set up a small team of people who were entirely focused on Rust support. It wasn't a large team, only 2-6 people (it varied over time) out of approximately 1500 engineers. Having that core team who either were or became deep Rust language and toolchain experts was critical to smoothing the path for everyone else. It provided a group that had the knowledge and bandwidth to solve the problems that inevitably came up, as well as to offer advice and code review support to the early adopters.

That group no longer provides code reviews and design advice because Rust knowledge is now widespread enough that teams have their own, homegrown, Rust experts (not people designated as Rust experts, just engineers who became enthusiastic and dived deep), but the group still exists to resolve complex technical problems with language integration and to work on improving tooling and performance.

I think any shop adopting Rust (or any new language or complex tool) needs to have some people who become deeply expert in it and are allowed the time and freedom to support others who are picking it up.

So does Android. Google has been a primarily-C++ shop since its inception and although I'm not sure if Android had a lot of C++ in it when Google bought Android in 2005, it definitely became a C++-based system as soon as that happened.

The highly-segmented architecture of Android really helped facilitate the transition. Most of Android is structured as a web of collaborating services that communicate through a common language-independent [*] IPC mechanism (binder). Implementing Rust binder IDL generation and support libraries was a moderately big job, but once that was done it was easy to begin writing new system components (or replacing existing system components) in pure Rust, generally without any unsafe blocks at all.

If your code runs as a monolithic process, or has a lot of different IPC mechanisms, or uses a lot of existing libraries, it will be a lot harder, and the benefits will come slower. You'll have to wrap a lot of C interfaces in Rust -- and they will have to be C, not C++, since there isn't a good way for Rust to interoperate directly with C++. People are working on that, but it's a very hard problem and at present the best option is to layer a C interface on top of your C++ code, then wrap a Rust interface around the C interface. Yuck. Or, in the alternative, insert some other language-agnostic boundary between them.

So in a lot of ways Android got lucky because of its modular architecture and single, language-agnostic IPC mechanism. OTOH, that wasn't really "luck", it was a lot of work, done for good reasons, one of which was cross-language compatibility, notably between Java and C++.

[*] Language independent-ish, maybe I should say. The binder IDL is definitively Java-based, but this maps fairly nicely onto OO languages that support common primitive types (int, char, enum), basic composite types (array, vector, class/struct, string (which is just a vector, but used enough to be worth treating as a first-class thing)) and Java-like methods (fixed argument list, single return value). Further, it's based on "old" Java, before Java acquired functional extensions, when doing things like passing method references as argument was uncommon, and therefore not supported. So it's moderately-expressive but avoids things that get weird and complicated. My one big complaint about it is that I wish it supported unsigned integer types. That's my biggest gripe with Java, too.

.... Their green energy data is flawless, because nobody would ever deliberately lie about that stuff!

Is this
1) (stupid) antivaxxers, as so very many ideologically-motivated comments here have immediately assumed?
Or is it
2) millions of unvaccinated illegals entering the country since 2020? ... Or something else?

I find it curious that so many commenters here are insanely militant and aggressive about vaccination, I didn't recall those same voices ever insisting that the tidal wave of illegals submit to vaccination... Do you?

I think I saw someone swimming in some sewage en route from scraping a bear carcass off the road, let me go check.

1. I got asked once if I played world of warcraft since they say a guy with the name "thegarbz" playing. I said no. By the way I know exactly who that person is because he impersonated me as a joke. I found that flattering and funny, but it has no impact on my life beyond that.

Reminds me of my first email account ;) One of my professors said we all had to register for an email account (this was in the mid-90s) so we could submit our homework to him, so I registered his name at hotmail.com to mess with him ;)

I don't trust single points of failure.

Yeah, this. If I have to sign up to some site that I don't care at all if it gets hacked, I use a throwaway password. Oh noez, someone might compromise my WidgetGenerator.foo.bar account and generate some widgets in my name, heavens to betsy!

It's called "pathetic fallacy"-- ascribing feelings (pathos, in Greek) to inanimate objects.

I'm afraid that we do this all the time. I don't even think twice before saying something like "the toaster doesn't like you to run the blender while it's toasting" or "this program wants two special characters in the password, not just one."

When in the history of humanity has there not been a big problem coming? Or occurring, for that matter.

The problem in this story is not the wealth, but its form. Cryptocurrency transactions are generally irreversible and not subject to the layers of process and protection that have been built up around large banking transactions. Keep your money in banks and brokerages like a sensible person and you don't have much risk.

Uh, yes, the 24-hour cancellation option is always the most expensive one for a given room (ignoring paying extra for add-ons like free breakfast or extra points). What other option would be more expensive? The one that gives the consumer the most flexibility is the one with the highest risk to the property, and that's priced in.

Yeah, TFA overstated it. Though if you're not booking through the chain directly, in many cases it is hard to get a 24-hour cancellation policy. Many of the travel aggregator services hide them.

Yep. That's all true even if AI is the most transformative technology ever invented, even if it generates trillions per year in economic output -- it might not do it soon enough to prevent another crash. You don't have to believe that AI is "sand-castle based or vapor based" (which it's really not) to see a big problem coming.

The market can remain irrational longer than you can remain solvent.

The better strategy, IMO, is to keep your money safe and wait for the bubble to burst, then pile in for the recovery. Where to keep money safe is a good question, though. Just holding cash might be risky if inflation comes back, and the current administration seems anxious to pump up inflation.

There's a pair of seriously bad assumptions underlying your analysis:

(1) What AI does right now is all it's going to do. Given the way capabilites have grown recently, this is a ludicrous assumption. Keep in mind that ChatGPT was launched November 30, 2022... it's less than three years old! And the reasoning models are barely a year old. There is no reason whatsoever to assume that this technology has peaked.

(2) We already know how to take full advantage of AI. Every time a new technology comes along it takes decades for us to fully understand how to effectively use it, and to deploy it everywhere it is useful. I'd say we still haven't fully incorporated the Internet into our society, and we've been working on that for over 30 years now. We're barely beginning to understand how to use what AI we've already got, and it'll take years, if not decades, for the full economic benefits to be achieved -- and in the meantime AI is probably going to continue improving.

The AI thing absolutely is a bubble, but it's not "sand-castle based or vapor based". It's very real. The problem is that the massive wave of investment is going to have to start generating returns within the next 3-4 years or else the financial deals that underpin it all will collapse. That doesn't mean the technology will disappear, it just means that the current investors will lose their shirts, other people will scoop up their assets at firesale prices, and those people will figure out how to deploy it effectively, and create trillions in economic value.

Well, assuming AI doesn't just kill us all.