The vibe coding vibe was off

I attended an AI mini-hackathon this weekend (shoutout to AI Tinkerers ) and was excited to try "vibe coding" for the first time. This is a longer post detailing my experience, but tl;dr: the frustration of iterating with AI when it got stuck swamped the magical wow moments when AI worked seamlessly. The vibe was definitely off. But the promise is there.

The context

My goal for this session of "vibe coding" was to build a personal CRM. I wanted it to have basic contact management features, integrations with Gmail, GCal and LinkedIn, a modern UI, and more (all written up neatly into a spec-like doc at the beginning of the hackathon).

Context about me: I am technical but rusty (last coded professionally a decade ago), have coded a few small side projects over the years, have passable React knowledge, tried out Cursor for the first time earlier this year, and have experimented with AI prototyping tools before.

Trying prototyping tools

Replit: I was most excited about using Replit because I heard it has the most technical depth. Started promisingly but immediately hit bugs: in the prototype preview, I couldn't get past the sign in / sign up screen! I went through a few rounds of asking it to fix its own bug. Then I gave up and had it remove the signup wall. After that, I accessed the dashboard but couldn't even load the next page in the leftnav, a basic Contacts page. I gave up on Replit after that.

Lovable & v0: Both performed better with "functional" (mocked) login systems and dummy data that created the illusion of working features. Both built out several pages of the app so I could get a much better feel for the overall idea. Neither connected to an actual database and thus neither prototype had fully working CRUD features, but that's understandable and getting Supabase hooked up wasn't too hard. 

Both handled basic iterations well (changing layouts, converting modals to pages) but made very timid changes when I asked them to improve the UI by drawing inspiration from Notion, Attio, and Linear (my guess is they either can't access outside products or there are guardrails against copying other products).

Amusingly, my spec emphasized my desire to have a Chrome extension but none of the tools even took an attempt at building that in addition to a web app.

Moving to Cursor

I exported the code from v0 to Cursor to continue work. At this point I was about an hour into the hackathon. I made some more small changes to the app, which all went smoothly. But then I hit the real wall: connecting a user's account to their LinkedIn account.

This was definitely a harder change than the ones I had asked for thus far. What I wanted was not to use LinkedIn as the main auth provider, but to let a user who already has an account with my app to oauth into LinkedIn. My app would then save the necessary tokens and be able to make calls to LinkedIn on behalf of the user.

By default, Supabase does offer LinkedIn as an auth provider, but that would try to create new user records in my app, e.g. if somebody used a different email to sign up for my CRM versus sign into LinkedIn. To Cursor's credit, it implemented this basic Supabase feature pretty smoothly. 

But that's not what I wanted; I wanted to store LinkedIn tokens with existing user profiles. After explaining this to Cursor, it did seem to understand what I wanted, but was unable to easily figure it out. This triggered 4 hours of back-and-forth with Cursor… and it's still not working!

I had not seriously looked at the code before this feature since I was trying to fully embrace the "vibe coding" promise. But my continued prompting to try to get this LinkedIn auth feature wasn't working, so I had to dive into the code myself. Cursor began spiraling with each iteration, writing more and more code that seemed to just complicate things further. I had to really steer it hard down the path of using a more 'manual' 3-legged oauth. Now I'm still going back and forth with it to figure out how to handle my app's user sessions correctly in light of this oauth flow.

Reality vs the vibes

Earlier this year, I tried out Cursor for the first time, using it when fixing a couple small bugs in my startup's codebase. My experience at the hackathon matches that earlier Cursor experience: ~70% of the time, it works magically on the first try. The first time Cursor works its magic correctly, it feels so good and it feels like you're living in the future. But the other 30% of the time, Cursor is confidently wrong and frustratingly difficult to debug.

This may be an unpopular opinion, but if you think about a "journey map" of the AI-assisted coding experience, the "lows" when you're wrestling with AI and it's just not getting it feel like they outweigh the "highs" when AI works correctly the first time. I've definitely still saved time on net by using v0 then Cursor to get to my current state. But it's definitely not as much time as I thought I'd save, given all the hype around vibe coding.

It's also surprising how AI struggled with a LinkedIn oauth integration. This is not a weird or rare requirement; I can't be the only app out there that wants to connect a LinkedIn oauth to an existing user account. You'd expect common patterns like this to be seamlessly handled. What I want is an AI tool that will tackle common, straightforward features in a very deterministic way and fall back to the probabilistic method of LLMs for everything else. (I believe this invokes a branch of study within the AI world, eg Toolformer).

(I also can't claim this is a totally new thought to me - I previously worked at Bubble, a leading no-code platform. Part of Bubble's strength is that it creates larger building blocks for the most common app features, like auth, to drastically speed up the app building process.)

To me, this is a reflection of a common pattern that unfolds when new technologies come around. First comes the development of basic foundational capabilities, in this case AI code generation. Only after those are somewhat in place do folks focus more on molding these capabilities to facilitating specific workflows. In this case, the workflows might be defined broadly, like "building a SaaS app", or more narrowly, like "facilitating auth features". I imagine this is something the folks at Cursor, Replit, v0, Lovable, etc. are thinking about. It's also fun to see how this is a fractal situation: the pattern is unfolding with AI code generation within the context of broader AI developments following the same pattern.

Conclusion

The vibe coding experiment left me with mixed feelings. These tools scaffolded together basic functionality so, so quickly. But they completely fell flat with more nuanced requirements. And there's no way I could've unblocked the times it got stuck if I didn't already know how to code, as rusty as I am today. 

I am sure that I could improve my own vibe coding skills (in fact, something I'll continue to do on the side). But to me, my conclusion so far is that vibe coding is way overhyped. For now. The future's coming, but it's not quite here yet.