“Vibe coding” is a big deal in the AI community right now. It’s a fun phrase for a new way of developing software, primarily by prompting LLMs.
The demos look cool. I’ve found LLMs helpful in some scenarios, but is “vibe coding” really the future of software engineering, as some AI enthusiasts claim?
Let’s find out. I’ll vibe code an app from scratch as a novice and then review the code as an experienced software engineer.
Weapon of choice
Some of the tools I’ve heard about in this context are Cursor, Claude Code and Lovable. Initially, I was excited to try out Cursor, but unfortunately, Anysphere did not believe I was a human.
So, I decided to try Claude Code instead. I’ve enjoyed using Claude for search, docs and test stubs in the past, so it seemed a decent choice.
I was ready to go after a quick registration process with Anthropic and upgrading my NodeJS installation.
Mission statement
Vibe coding aims to make software development accessible to non-programmers. I tested this by acting as a beginner, giving minimal technical input and letting the AI guide the process.
Still, I wanted a slightly more advanced use case to review the capabilities better later.
The prompt:
Build a progressive web app with C# that allows users to create and share playlists. Users should be able to subscribe to other users playlist for a custom monthly fee.
The first thing that happened was impressive: Claude ran commands to create and design a scaffold for a Blazor frontend and API, including reasonable data models, DTOs, database integration and a Swagger UI.
The next thing that happened was more frustrating: It didn’t work. When registering my user via /api/Auth/register, I got a 403 Forbidden error. Naturally, I let Claude know about this, which launched a 45-minute process of building, rebuilding and testing the project.
I could register my user after disabling HTTPS redirection and vibe debugging some weird .NET compatibility issues.
At this point, I am still running on complete auto-pilot. I have no idea how the code works, but it does appear to work.
I want a front-end, too, so I ask for it. Halfway through building it, Claude exceeds its context window and restarts the conversation, passing a summary to itself.
I ask how to test the frontend and get a satisfactory response. Now, I can see a webpage, although it does not integrate with the API in any way. We have:
A home page with a menu, a blue box and some text
An “About” button that links Microsoft’s ASP.NET docs
A popup about an unhandled error
A Playlists page which says:
Sorry, there's nothing at this address.
I then asked for the front end to be expanded with capabilities from the API, after which Claude realised the entire project was wrongly structured and needed to be reorganised to compile.
Now, both the API and the frontend build again, but uh-oh:
Naturally, I asked for help to get this fixed. Claude was happy to oblige. And the webpage now loads. Except there is now nothing here to do with playlists.
Claude has populated the page with “hello world” placeholders, a counter, a link to a Blazor survey and a broken weather forecast. The unhandled error is still unhandled.
I tried to request a proper integration, but now the builds fail. After another hour of vibe debugging, we now have more correct-looking content, but the user registration doesn’t work again.
Oh my god. That’s it. I’ve spent 4 hours and $20 Claude-bucks - I’m done.
I’m tired and frustrated with acting as QA for a bot. Claude Code occasionally makes heroic progress and then chases its tail for hours on random trivial issues.
Every prompt feels like one step forward, two steps back. I made some fast initial progress, but now I pay the price with a sluggish, frustrating debugging flow.
I struggle to fix issues without investing more effort into reading and understanding Claude's code. And if I can do that, I might as well write the code myself.
Code review
Up until this point, I’ve been acting as a novice. By “vibe coding” for 4 hours, I could spin up an API with authentication and a frontend that is nearly functional.
Frustrations aside, this is a neat tool that anyone can use to make working programs. But is it more than a toy? Can these programs be used in production? Let’s review.
⚠️ Request changes: run.sh doesn’t do anything
This is a small but silly one. run.sh doesn’t do anything but echo to your console that you should go ahead and use dotnet run. The frontend port note is wrong.
⚠️ Request changes: Duplicated projects
While reorganising the project, Claude has created not one, not two, but three duplicate API folders. As far as I can tell, only PlaylistPro/ApiProject is in use. While it doesn’t break anything, it’s a mess (!) and will be hard to maintain.
⚠️ Request changes: Weather forecast
Why do the API and client apps implement a weather forecast? This was not part of the requirements or even tangentially related to playlists. The result returned by the weather forecast is random and arbitrary.
🟥 Decline: Mocked auth implementation
The first auth implementation was not too bad (I reviewed it early). However, after the confusion with structure and integration, Claude has opted for a mocked auth implementation that lets everyone in. This is not acceptable for a public application.
Declined: Do not merge
As a reviewer, I would not accept a pull request like this into my repo and would certainly not release it to end-users.
I have been impressed with the tool's capabilities, though. Maybe an innovation that’ll make these tools “the future of software engineering” is around the corner. I doubt it, but I am open to being wrong.
“Vibe coding” is making software engineering available to a new group of people. It makes prototypes and “personal software” cheaper to produce. But I don’t think it’ll displace the traditional software engineering industry in its current form.
Instead, I’m guessing we are looking at a Jevons Paradox situation, where lowering the cost of creating simple software will lead to more simple software being created.
Personally, I found “vibe coding” a frustrating experience, and I felt less productive. Someone without coding experience might find learning the tech equally a barrier to building what they want. Each to their own.
You can “vibe your way” to decent prototypes for apps where quality and security are unimportant. But please, don’t deploy these apps to production without serious scrutiny. Otherwise, you may need to prepare for some “vibe firefighting” as well.
May you find the questions you seek,
// // /////
// // // //
//////// //
// // /
// ////////