I'm as much of a skeptic about vibe coding as you are. I consider engineering a bit of an art, so it's not for me.
That said, the kinds of things I've been hearing as going wrong with vibe coding are all or mostly fixable. I would even go as far as to say they're manifestations of the same problems that make IDEs such clumsy tools for humans to use at the moment, which is why we're trying to foist all this annoyance of using them off onto AIs.
The biggest problem, THE problem in this space is that tools we use don't have the language to describe the logic -- the intent -- behind refactorings. If you've never captured the user's intent, you can't learn from it. The ability to capture that intent is absent all the way from the highest level UX right down the lowest level of serialization: the patch format
That's why I believe it's my tech they really need and not Windsurf's -- I'm working on capturing the intent top to bottom.
Isn’t the intent described in the commit message, which is one of many ways the developer can use to share intent? Code is only the what and the how. The why should be in Wiki, Readmes, Commit, Issue tracker…
Let's say the change is to rename a variable. The patch format can never capture that the intent was to rename a variable. You can say so in a commit message, sure, but the action is never recorded, only it's effects, causing merges involving the rename to have conflicts
That’s because the code is data for an execution machine. All the other stuff are for the hunan mind. There’s multiple way to transition from one state of code to another, so mostly people record the existence of a transition (version control) and why it has happened (commits and other texts).
Recording how is not fruitful, unless the technique is good. In this case, the essence will be extracted, and it will become a checklist or a script.
If you have two itents producing conflicting patches, the merge intent that emerges is good because it brings empathy (understanding the message) and harmony (working code). And that’s why almost everyone says that the code itself doesn’t matter. Only the feature that it brings into play and the the mind that birth it do. It is a medium.
And a merge conflict is nice because it detects overlapping work and the fact that the concerned people should propably meet.
Yeah that's weird to me but I've made my peace with it. I do this to make the software I want to use, and I think that's a chance everyone should have.
This is patently wrong - as an experiment, I've vibe coded* four apps in the last 10 days. I did not write one line of code myself. Two are crud style, one is DNS related and one is for an embedded device. They were non-trivial use cases, built using claude desktop with various MCP tools. I was blown away by just how good it was.
*the original definition of vibe coding involved using voice to dictate the prompts to AI, I prefer to type.
I mean, why did Facebook buy Instagram? It's a feed of photos and social network, hmmmm. In one sense, sure you can copy any software out there when you have the resources, but OpenAI got to peak under the hood of Windsurf and 1) Found a large, growing community (emphasis on growing) they can buy, which is worth something and 2) A team that probably will save them 1 year of unforced errors (also worth something) and 3) they have a lot of capital to deploy anyway, and this is not a risky bet.
I am not the one coping. Many things may threaten my earnings as a Dev, mostly the very clear possibility of a difficult economic scenario in the years to come.
Vibe coding is just people deeply invested in a deadend technology trying to hype it up.
And I say this as someone that does use AI to a limited capacity as a code assistant.
The obvious answer is that vibecoding does not work.
If it did, OpenAI wouldn't need to buy Windsurf