There is no Vibe Engineering
serce.me
serce.me
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.
Clearly you've never had the pleasure of working at a NIH (not invented here) syndrome culture company. At one company, we didn't have budget to buy a ticketing system, but somehow we prioritized engineering building one from scratch. Another time I was talking with an engineer at Roblox and the engineer interviewing me was building a config scanning and management system from scratch for pretty generic linux installs. I can think of at least two companies that offer a product that did everything they needed and more, plus it was a full featured, stable production ready system, vs theirs which had serious teething issues and was obvious they were struggling to scale it. There's no shortage of these kinds of config management systems out there but they decided to build their own anyways.
At another company our "staff" infra guy wrote 40,000 lines of bash because he didn't like how Jenkins worked for deploys. These are all very standard things that keep getting coded over and over for whatever reason. I haven't tried it yet but I'm pretty sure you could "vibe code" a Jira or Jenkins clone in a couple of days and at least pass the PoC sniff test. I've certainly done it for some throw-away prometheus exporters to get some crude visibility into third party services we have to use.
oh man, just think of the security implications of a "vibe coded" CI system, holy shit I'm going to have to get into consulting because there is going to be SO MUCH MONEY to be made digging organizations out of self-created holes like this one.
Jira too, considering the importance of RBAC there, if you tried to replace that in a couple of days, inevitably that's a lawsuit waiting to happen.
Lol I love also that I got a downvote before I was done editing this comment. Love it. Be mad, I'll be rich.
This is a whole new category of "I could build that in a weekend," lol, no you couldn't.
> 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.
I liked the quote because what it conveys is that you can't control everything. You can't control the way people freak out about things on Twitter. You can't control an influx of new tools. But what you can control is the way you react to them – not giving in to the chaos, but instead approaching the changes with a cool head. And the Netflix show it's from, Midnight Gospel, is pretty good. I do agree that the house analogy could be better though.
(for those mixing up "vape coding" with AI coding, they are absolutely not the same.)
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 always wonder what kind of things people would want to use vibe coding for because there's no way it could be for anything serious, I'd hope.
1) throwaway code where the "work product" is not a software system, but rather the outputs of the code which you can verify yourself.
the classic example for me is producing plots. I can easily verify that data is loaded correctly, and that the end result is correct, I just don't want to learn the complex API to make all the ticks and colors and fonts look perfect.
2) prototypes, mockups
3) simple tools (often with a web interface) for your own use
Any time I have taken shortcuts because "it's just a prototype" I have always come to regret it later. This may not be the "serious" use that it initially feels like.
Only there exist no prototypes, in the sense of throwaway. Prototypes become the product, as rarely something is really build up again from the ground to account for best setup.
But lots of people write computer programs outside such contexts. Then it’s perfectly possible to prototype something and actually rewrite the full version.
The worst outcome of all of this stuff could be that instead of dealing with exploding complexity and coming around to best practices that reduce it, we'll just let complexity and resulting confusion multiply because "the machines" will be the ones "thinking" about it, and not us.
But I wouldn't trust an AI to design the QA process.
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.
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.
This is also what happens when the VC hype brigade just listens to AI researcher influencers who are excellent with research, but instead creating throw away code and encouraging "slopware" because it is gluing code up without maintenance, testing and verifying that the code works.
Vibe coding is yet another way in promoting the proliferation of more slopware rather than creating robust and mature software that lasts for years.
It has zero place in areas of high risk like defense systems or healthcare.
It seems like such a hippy thing to do.
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.
Of course, there are tradeoffs that come with that. You might not need engineering in your product.
Absolutely. As before, there are tradeoffs to be made. Not all software needs engineering, and it may even be detrimental to it. But if you have proclaimed engineers working on your product...
Awesome, products who live what? 1 year tops.
One of last month fun bugs I got from a 10 year old ecosystem was due to some backend calling an API which (aside from fetching info from an API provided by the backend) needed data from some third system generating it using a CRON run mon-thu at 13h. The original input in this third system was done on thursday around 17h so it was not available on friday (date of the ticket) nor monday morning (which led to this treasure hunt) but things were automagically resolved around 13h15. Gotta love the world of in-house legacy applications.
True, but it changes the way that management and investors see us. I, for one, am planning to go back to school in order to move into patient-facing healthcare. I'd love to hear others' ideas on fields that are intellectually stimulating and where the human touch is valued.
Keep building things even if it’s just vibe coding and reading the code. This AI coding caper is moving fast!
Patient facing healthcare will see you spend years getting trained only to hop on the bottom rung of a system hamstrung by onerous regulation (understandable) and severe labor shortages (complex). You’ll be moving all day and have sore feet by the end of the day. The human touch is valued only by the subset of the population who deign to be polite. Your management values metrics.
My prediction is you’ll be shocked and dismayed and come running back to your relatively unregulated, keyboard driven, non body destroying current career.
Such a weird take for both because there does seem to be a sweet middle ground.
Having been burned by Copilot in the past I started researching and using alternatives. Continue was nice for a while because it allowed using Claude and at that time was better at feeding the LLM good context from your codebase. I started using Cursor + Claude 3.7 not too long ago and, while a definite upgrade from Copilot, I still saw glaring issues with what it generated. Writing project rules has helped immensely with this and has crystallized what I believe the SOTA of LLM-assisted development to be for the foreseeable future (i.e. if the assumptions about the limitations of current LLM architectures hold true). To your point, I think
> a sweet middle ground
will end up involving developers bootstrapping LLM-read rules according to project architecture and specifications while they build out the foundation and initial features. This will then allow devs to crank out bounded contexts while they spend the long tail stitching them together as they focus on the problem domain. "Vibe coding" as practiced by influencers is nothing more than a quicker, sexier version of the StackOverflow copy/paste programmer archetype that's been around for the last 20 years. Similarly, "agentic" platforms that allow an LLM to regurgitate whatever it wants while it throws spaghetti at a terminal to debug are just automatic versions of developers that paste entire stack traces into Google. Developers on the opposite end of the spectrum who care enough to review the LLM's work and, more importantly, refine it as they go will be rewarded handsomely.
Either way it's safe to say that Microsoft has gotten a good kick in the pants over the last year or so as the tooling in this space has improved. I'm pretty optimistic about the future after having seen such large dividends from my efforts to go beyond just tabbing and Cmd+I'ing my way through LLM assistance.
Vibe coding is simply a failed attempt to undo the stigma of this.
Slop coders are easily inpressed.
Where will we be in 5-10 years (or more?) if this progress keeps up.
AI development will plateau. It’s not like it *must* improve with each iteration.
Producing code has got to be the best case scenario for LLMs because there's a lot of boilerplate and examples of simple applications, and people aren't out here criticizing the structure of a TODO list app.
That is a big "if".
Why would I need someone who specializes in databases when I can just build it in Access?
Why can't we just build our site in squarespace and not have any resources at all?
There's always something that is supposed to come around and replace engineers but it never comes to fruition. These attempts are good to build shallow products and MVPs. For "vibe" coding, the product will not be serviceable if the person who implements it does not understand what the code is doing. This is the equivalent of rote learning and expecting the implementer to be an expert
Other than excel, end users aren't great at creating their own solutions