It captures not understanding what you’re doing crossed with limited AI understanding which means the whole thing is running on vibes.

I still wish a better name had been coined/had stuck.

It’s hard to take the name “vibe coding” seriously, and maybe that was the whole point, but I feel like AI coding is a bit more serious than the name “vibe coding” implies.

Anyone that disagrees that it should be taken more seriously can surely at least agree that it’s likely it will cross that threshold in the not too distant future, yet we’re still going to be stuck with the silly name.

It is the perfect name for an industry that considers "enshittification" a serious term of art.

And I say that knowing it will absolutely rule everything in the future - I'd bet at last half of all Show HNs are vibe coded apps now. Not long ago tech was seriously talking about monkey JPEGS being the future of global commerce and finance. We've been living in unserious times for a while.

I'd feel better about vibe coding and AI in general if I thought it would lead to more people learning how to do what it enables for themselves, and actually exercise control over their devices and creativity. But as useful as it can be - and I have to concede that much at this point - it requires depending on centralized AI services and isn't much better than proprietary code in terms of defending end user rights. I fear AI driven everything will lead to more closed systems and more corporate commoditization of our data and our lives. Unfortunately from what I've seen not only do many vibe coders not care, they don't want to care and they think anyone who does care is a slope-headed neanderthal.

So yeah, call it what it is. OP's app would have just been a simple web app ten years ago, it's just a quiz, doesn't require any deep coding magic. But no one cares about anything but the vibe anymore.

I wish that computers were designed in a way that pushed the users to script more. Its such a powerful ability that would benefit almost every worker.

This has often been tried. SQL, for instance, was specifically designed to feel like natural language and be useable by people with minimal technical background. But it always runs into the same problem. As you start to expand the capabilities of these scripting languages and you get into the nitty gritty reality of what programming genuinely involves, they always end up being just really verbose and awkward to use languages that are, otherwise, like any other programming language.

Even worse is the tendency for scripting languages tend to try to be robust against errors, so you end up with programs that are filled with extremely subtle nuance in things like their syntax parsing which, in many ways, makes them substantially more complex than languages with extremely strict syntactic enforcement.

Ah so you're saying we should remove error handling and let the users feel the consequences of their actions.

The users are already feeling it, but may have trouble understanding why! The reason strongly typed languages with rigid syntax are easier is because it's much more difficult to accidentally do things like check if 3 is greater than true.

Apple has always been pretty good at this. AppleScript, Automator, Shortcuts. I did all kinds of cool stuff in OSX 10.4 back before I wrote any traditional code.

Before that was HyperCard. It was always amazing to me the types of applications that could be written with HyperCard.

In a similar way, VBA was amazing in MS Office back in the day. If you ever saw someone who was good at Visual Basic in Excel, it’s impressive the amount of work that could get done in Excel by a motivated user who would have been hesitant to call themselves a programmer.

I wrote, and sold my first piece of software in HyperCard. It was a pretty lame Choose Your Own Adventure style game, where you clicked on buttons, having read the text. 7 year old me was pretty chuffed, to buy some baseball cards out of his hobby. I really, really miss that world.

Applesoft Basic

Workers are over specialized. And our business domain models are rigid. We want to streamline and standardize which often means that code is written in few places.

It would be nice if we could have the cake and eat it here. With LLM:s there's certainly opportunities if we can find ways to allow both custom scripting and large scale domain constrained logic.

The only issue is security. The amount of open endpoints, standard logins and stuff will get out of control.

but they're not programming computers. They're commissioning footgun-riddled software from a junior intern

People have the grandest ideas about the quality of the average piece of software existing in the real world.

for your own use you can use whatever crap you have a machine come up with for you.

For use on others, no. It's not about just the quality, it's about not even knowing what you're selling.

What is the end goal of software? The vast majority of engineers seem to believe the goal is for the software to be perfect, when actually it's to do things like catch cancer early or make money. Do you think a person who’s life was saved by software with footguns cares?

Lose the tunnel vision.