There is no Vibe Engineering

The more hard constraints one imposes on generative AI output, the more that it becomes exponentially harder to constrain that output to those constraints: so much for "embracing the exponentials" -- constraint-exponentials dominate vibe-exponentials.

With only a few dimensions of constraints there are zero relevant examples in training data, with only a few more, there are zero similar examples. This is why programmers are employed: it is always a R&D job, if it existed under relevant constraints, it would be purchased and installed.

The art of vibe coding, such as it can be developed as an art, is in segregating system design to localise (constraint-induced) novelty. There are certain applications of genAI where it makes sense to give up on a plan, and take good-enough. Software "in the large" is not such a place.

It's no accident its data scientists who began vibe coding -- it's a fundamentally "in the small" activity with no hard constraints: much like the throw-away exploratory programming of data science. Hence, I suppose, the alarm and confusion amongst software engineers -- perhaps they just aren't aware they're speaking to a radically different kind of "throw away programmer" that exists in the AI space, they've always been vibe programmers.

Off topic, perhaps, but this is the thing that stuck out to me in the OP

> When the tornado comes whipping through your neighborhood and your house gets blown down and somehow you didn’t have insurance and you lose everything, you can’t control that. But you can certainly control how you’re gonna react to that situation.

Neither of these two things are really true. It sounds like it should be true, but it really isn't. Why didn't you have insurance? Why are there more destructive tornadoes? If my house is trashed, at a reflexive simple human level, I'm pissed, depressed, anxious - take your pick of emotions. No amount of stoicism, short of super maximum foo level is going to change that. Nor, should it. That stuff isn't a movie about overcoming obstacles, as an individual with super-human fortitude. It's a trashed house and a whole boat load of expense, and more.

Why is that quote in the piece? I don't get the analogy.

It should be called "vape coding", as the outcome is almost always a vapor-ware like abandoned project.

(for those mixing up "vape coding" with AI coding, they are absolutely not the same.)

The flip side of all of this is that so many products fail because development on new features becomes unbelievably slow. Either because of a kind of process paralysis or because things are over-engineered.

Don't get me wrong - there are absolutely critical path parts of software and engineering projects that can become enormous liabilities if not handled correctly. Further, the whole nature of software means that sometimes it's not even clear what will be a vulnerability at the outset – people find ways to exploit even the most benign-seeming aspects of a piece of software.

So, I'm not suggesting that the warnings raised here are without merit. But, it's worth understanding that despite all of that – AI or not – disruption happens constantly because a startup that isn't big enough to worry about a lot of these issues can come in and upset the established player by moving fast.

Again, this isn't a moral judgement either way – just pointing out a reality.

I personally think 'vibe coding' should be thought of as a kind of prototyping tool. A scaffolding to quickly validate an idea and see if it has legs.

I don't see it working on anything outside the most popular of frameworks and libraries which have the most example code to ingest. Vibe coding will have hard time creating novel solutions by definition. It devalues the already lowest common denominator and lets people create more buggy CRUD applications.

Do you want a vibe engineered pacemaker?

You cannot and should not vibecode things that are “out of distribution” vs your model’s training set. For those you need to constrain the amount of novelty, generating things in small incremental steps. It’s not much different to how humans constrain software development to one PR at a time.

Part of the skill of coding with LLMs is knowing what's likely out of distribution so knowing “how much rope” to give the model.

These problems with present-day LLMs can and will be mitigated in future with synthetic data providing more examples, and with even more inference time compute, and with intelligent fetching of docs, and with realtime ingestion of relevant dependency code, and with larger context that give models larger working memory.

Coding models have so much potential value that it pretty much has to happen.

Imagine if you will, a team tasked with building widgets. That means designing the widget, the mechanisms to fabricate widgets from input materials, and building those mechanisms to then build the widgets.

You could do this with a team of two people, the engineer and machinist. The engineer spends their time at the drawing board and handing designs to the machinist to fabricate. The machinist is probably going to run into problems, or there are problems with what is fabricated and the engineer needs to go back to the drawing board. It's an iterative process.

Now imagine those widgets are software. Historically we call both the engineer and machinist "software engineers" or "developers" and might call the first one "senior" or "architect" or something like that. Since we don't need a human being to physically operate machinery it seems like using AI agents would be the an ideal place to replace the software machinist.

However there's a problem - the engineer/machinist duo works not because the machinist is an engineer but somehow worse; they have different skillsets and the engineer is going to get immediate feedback from the machinist that a design is going to work or not. The engineer/machinist divide works because the machinist can say "nah."

AI agents today don't have that ability. You can tell them to do things that are impossible, or they will make shit up. Without the ability to check for validity or preemptively avoid mistakes, vibe coding is just shitty software development. If and when that problem is cracked then the concept of a software machinist will be obsoleted.

Vibe Coding and the environments that enable it are the Turkish Hair Transplant of programming.

Calling it rapid prototyping doesn't sound as cool as it used to, now that there is vibe coding. Especially when its pure shiny 100% AI.

It seems like such a hippy thing to do.

> When might this future arrive? It's uncertain. A good indicator, however, might be when engineers confidently say "yes" to the question: "Would you happily go on-call for a system of fully AI-generated services?".

I dare say there are already people saying this, but I don't know of any SWEs (or anyone who has maintained a significant codebase) who would be willing to go on-call for such a system. But I would hesitate to go on-call for even an entirely human-built system unless I'd done some in depth review of its architecture and playbook.

Maybe there's a middle ground here, like willingness to update the codebase of a vibe-coded application. Do that enough times and maybe the confidence in the system increases enough to be willing to on-call for it.

I agree with the position that the value of an "engineering" role in this context should be judged by those who have held that position, moreso than the opinions of management or media in that regard, anyway.

There is no "vibe coding" either. It's just idiots playing around with copypasta by a different name.