Why Vibe Coding

I didn’t set out to “vibe code” an app just for the sake of it. With new AI platforms launching every week and startups raising millions on the promise of building full apps from a handful of prompts, the idea was too compelling not to explore. But I didn’t want to build a toy project or a demo that looked good in screenshots. I wanted to push the limits and see if vibe coding could deliver something real. An end-to-end platform with meaningful utility.

That’s where the idea of Coach Stan, my AI-powered poker coaching platform was born. It’s a product that touches every aspect of real-world app development: frontend, backend, databases, payments, subscriptions and production-level quality. In short, the perfect test case.

What I discovered was both exciting and humbling. Vibe coding can absolutely get you to a working product, but it’s not a straight line. It’s a process of hundreds of prompts, careful code reviews, and plenty of debugging and did I say debugging! Still, the experience proved one thing that AI-assisted coding is no longer just a curiosity. It’s a viable way to build serious software, if you’re willing to be in the driver’s seat.

The Tool Stack

To build Coach Stan, I relied on a small but powerful set of tools: Lovable, Claude Code, Cursor, and Supabase. Each played a distinct role in moving the project forward.

• Lovable gave me the initial scaffolding. However, in a single day I burned through my credits on the Pro plan, but by then I had a solid structure to build on.
• Claude Code became the engine for implementing major features. It could move fast, but came with its own quirks that I had to manage.
• Cursor was both my IDE and my review layer. I leaned on it for smaller changes, debugging, and code cleanups.
• Supabase served as the backend, powering database, authentication, and storage. Its seamless integration with Lovable was a big plus, saving me time on wiring things together. In many ways, it became the serverless backbone of my app.

Individually, none of these tools could have carried the project alone. But together, they formed the backbone of my vibe coding workflow and made it possible to take Coach Stan from idea to reality.

Lovable: Fast Start

I kicked things off with Lovable, and in many ways it was the perfect launchpad. Within a single day I had burned through my monthly credits, but not before it generated a solid structure for the Coach Stan platform. It gave me the kind of scaffolding that would normally take days or even weeks to piece together manually, and it helped me get past the hardest part of any build: the blank canvas.

What I realized quickly was that Lovable shines as a prototyping tool. It gave me a beautiful visual canvas to bring ideas to life and made it easy to see the shape of the platform early on. That momentum was invaluable.

Where it didn’t resonate with me was as a full-blown development tool for the entire lifecycle. Most software engineers are used to working in IDEs, command lines, and reviewing code diffs things that a browser-based experience simply couldn’t match. And while the scaffolding was strong, the credit limits (even on the Business plan) aren’t enough to sustain building something serious end-to-end. For small projects or quick prototypes, it’s great. But for production-scale development, it’s not there yet.

Claude Code: Big Features

Once I had a solid foundation from Lovable, Claude Code became my main workhorse for building out the bigger features. Initially on the Pro plan, and eventually the Max plan I used it heavily to implement core functionality across the app. It was fast, flexible, and generally leaned toward one thing: getting the code to run.

That bias toward “getting the code to run” was both its strength and its weakness. On the positive side, it could generate large chunks of code quickly and gave me a head start on features that would have taken far longer if written entirely by hand. However, on the flip side, it had a habit of mocking up functionality whenever it hit errors. For example, if a database query failed, it might silently replace it with a mock response. It also had a tendency to hallucinate, inventing table names, functions, or fields out of thin air. More than once I found myself thinking: Claude, you just created the table, you should know the column names. On top of that, it often left integrations incomplete, or worse, swapped out real implementations for mock code just to pass tests.

Despite those frustrations, Claude Code carried much of the heavy lifting for Coach Stan. Without it, I would never have been able to move as fast as I did. But using it required constant oversight and a willingness to review every line closely.

Cursor: IDE, Code Reviews, Small Fixes

If Claude Code was my engine for big features, Cursor became the layer of polish and control. It doubled as my IDE and my review partner, giving me a space that felt closer to traditional development: command line, diffs, and all the tooling most engineers are used to.

I leaned on Cursor for smaller changes, debugging, and cleanups, but its real value was in code reviews. Even though Cursor also runs on Claude under the hood, it consistently did a better job of catching issues, reviewing Claude’s output, and pointing out gaps before things broke downstream. That balance with Claude for generation, Cursor for refinement became a rhythm I relied on.

It wasn’t without its quirks. Prompts could take a long time to return, and I often ran into throttling when I leaned on it too heavily. But compared to the frustration of chasing hallucinations in raw Claude Code, Cursor gave me more confidence that what I was shipping was stable and correct. In many ways, it became the safety net that kept the whole vibe coding workflow from going off the rails.

Supabase: The Backend Engine

Unlike the other tools in my stack, there’s nothing inherently “AI” about Supabase, and nothing uniquely tied to vibe coding either. What it offered me was a simple, reliable backend that plugged in smoothly with both Lovable and Claude Code. That ease of integration mattered as it let me focus on building features instead of wrestling with setup.

Supabase also has a great entry point: it’s free to start, which gets you far enough to build out a complete app before needing to upgrade to a paid plan. For a project like Coach Stan, that meant I could validate the platform without committing to heavy backend costs upfront.

I see Supabase evolving into a strong backend option for vibe coding projects, mainly because of how straightforward it is to use. That said, I could have just as easily chosen another cloud backend. Supabase wasn’t the only option but it was the easiest path to momentum.

When Vibe Coding Tested My Patience

As exciting as vibe coding can be, it wasn’t all smooth sailing. The same tools that gave me speed also tested my patience.

The biggest issue was hallucinations. Claude Code in particular had a habit of inventing table names, column names, or function calls out of thin air. Sometimes it would even mock up functionality instead of fixing the real issue like swapping in a mock database response when a query failed.

Another recurring problem was incomplete or incorrect integrations. Features often came back half-baked: a component written but never wired into the app, or real implementations swapped for mock code just to pass tests. Worse, the AI would sometimes make changes I never asked for: renaming fields, altering functions, or “simplifying” working code into something brittle.

Database work introduced its own headaches. While Claude could generate migration scripts, it would occasionally apply schema changes during debugging that never made it into those migrations. That “migration drift” created serious risks for keeping the app stable across environments.

And when things broke, the debugging process often felt like trial and error at scale. Instead of methodically identifying root causes, the AI would try random fixes, undo them, and retry, sometimes looping endlessly without resolution.

Even smaller tasks had quirks. Asking the AI a simple question sometimes triggered it to start implementing code I didn’t want. Attempts to remove debug logs either stalled out or got stuck in loops. And with larger context, I often ran into throttling or slow response times.

In short, vibe coding worked but it also demanded constant oversight. Without reviewing every change, I would have ended up with broken integrations, incomplete migrations, and unpredictable code.

How I Kept Moving Forward

The frustrations with vibe coding were real, but over time I found patterns that made the process more manageable. A few approaches consistently helped me keep things on track:

• Break the vision into smaller pieces. Instead of asking for a big feature all at once, I framed work in the classic Epic → Feature → Story structure. The smaller the task, the more reliably the AI delivered.
• Decompose the system early. Splitting the product into frontend, backend, and services upfront prevented everything from collapsing into a monolith that would be hard to maintain later. Modular development isn’t the strength of vibe coding tools, so as a software architect you have to manage the modularity and reject the solutions if the code generated by claude code violates those rules.
• Make small, reviewable changes. I limited requests to changes that touched only a few files at a time, then always reviewed the diffs before merging.
• Be explicit in prompts. When I wanted help reasoning through a problem without code, I learned to say “don’t implement yet.” Otherwise, the AI often jumped into coding unasked.
• Verify schema details. Since hallucinated table or column names were common, I made a habit of double-checking schema references against migrations before trusting the output.

These habits didn’t eliminate the quirks of vibe coding, but they gave me a way to work with the tools instead of fighting them. Over time, I developed a rhythm: Claude for big pushes, Cursor for review and polish, Supabase as the steady backend, and a lot of discipline layered on top.

What Actually Shipped

In the end, all the prompts, debugging, and workarounds added up to something real: Coach Stan, a functioning poker coaching platform built almost entirely through vibe coding.

The app wasn’t the result of a single clever prompt or a weekend hack. It took hundreds of prompts over several weeks, with careful oversight and constant iteration. Every piece from frontend components to backend services, authentication, storage, and database migrations, all went through the AI pipeline at some point. Supabase handled the backend, Lovable provided the initial scaffolding, Claude Code carried most of the feature-building, and Cursor stitched it all together with reviews, fixes, and polish.

Coach Stan is more than a demo. It’s an end-to-end platform with meaningful utility, showing that vibe coding isn’t just for prototypes or toy apps. It can get you all the way to a production-quality product if you’re willing to guide the process, review everything carefully, and embrace the reality that AI-generated code is still far from perfect.

By the numbers here is what Coach Stan platform has today

Where I Need Vibe Coding Tools to Improve

While vibe coding got me to a working product, the experience also revealed clear gaps in today’s tools, things that would make the process smoother, faster, and less frustrating.

Cross-Repo Support: Most AI code generators today only work within a single repository, and while you can feed in external repos as context, it’s clunky and limited. What’s missing is true multi-repo awareness. The ability to understand multiple repositories and the dependencies between them. Real-world systems are modular, often split into frontend, backend, and shared services, and features frequently require coordinated changes across all of them. Without this, developers are left manually breaking down tasks and stitching the pieces together. If tools like Claude Code could seamlessly track dependencies and implement changes across repos, it would unlock larger, more complex projects. Cross-repo intelligence isn’t a nice-to-have, it’s essential for scaling vibe coding to production-grade systems.

Conversational Ability: One of the biggest gaps I found with Claude Code was its tendency to default to suboptimal solutions just to make something run, instead of pausing to ask what I actually wanted. What would make these tools a lot more powerful is a truly conversational approach, where the AI asks clarifying questions, weighs tradeoffs, and checks whether I prefer the quick fix or the more robust long-term solution or something else. Additionally, rather than dumping 20 questions at once, the interaction should be more iterative, like a back-and-forth with a teammate. Imagine discussing the design of a feature, getting recommendations, and even having the AI push back on a poor decision before writing a single line of code. That kind of collaboration would transform an AI assistant from a code generator into a real coding companion.

Smarter Debugging: When something breaks, Claude Code often falls into endless trial-and-error loops, trying the same fixes without making progress. What would make a huge difference is if Claude Code and other similar tools could debug more strategically building scenarios, ruling out possibilities, and narrowing down the likely root causes instead of guessing blindly. Even better, if they could integrate with logs in real time and analyze them intelligently, they could spot patterns and surface actionable insights much faster than a human could. That level of reasoning would not only prevent wasted cycles but could also evolve into a true production companion, capable of diagnosing live issues and guiding fixes in the moment.

Final Takeaways

Vibe coding isn’t magic. It’s messy, unpredictable, and at times deeply frustrating. But it’s also powerful. With the right mix of tools and a disciplined workflow, I was able to build Coach Stan, a real end-to-end platform, almost entirely through Vibe coding.

A few lessons stood out along the way:

• Use the right tool for the right job. Lovable for scaffolding, Claude Code for big pushes, Cursor for reviews and small fixes, Supabase for the backend.
• Scope tightly. Break big ideas into epics, features, and stories. Small, well-defined prompts work far better than broad requests.
• Review everything. AI code can be brittle, hallucinated, or incomplete. Never merge without reviewing the diffs.
• Expect loops and dead ends. Debugging will often feel like trial and error.
• Stay patient. Shipping a real app isn’t a two-prompt story; it’s hundreds of interactions layered over weeks.

For me, the experiment proved that vibe coding is viable for serious projects but only if you treat the AI as a junior collaborator, not a replacement for engineering judgment. It can get you there faster, but you still have to drive.

Where I Go From Here

Through vibe coding I’ve discovered an incredible power. The ability to create software products far faster than I ever imagined. Coach Stan is proof of that, and I see it as just the beginning. This approach has changed the way I think about building, and I don’t plan on looking back. My goal is to keep pushing forward, creating more products with greater speed and efficiency, and seeing just how far this new way of building can take me. In my next projects, I plan to explore other tools like Grok and GPT-5 Codex, testing how they stack up and where they can take the workflow. The journey is only beginning—and I’m excited to see what comes next.

Of course, I also want to push vibe coding into new territory. A few of my friends have told me it won’t work well for smart contracts. Well, Challenge Accepted!

The opinions, views, thoughts and/or other content (the “content”) expressed on this website and other media outlets, including, websites, social media platforms, articles, blogs, posts and videos, including, but not limited to, Facebook, Twitter and YouTube pages, represent my own opinions, views and/or thoughts and do not reflect the opinions, views and/or thoughts of Protagonist Management LLC or any of its respective affiliates or any of their respective directors, officers, and/or employees (collectively, “Protagonist”).

The information provided in the content should not be considered as an offer soliciting the purchase or sale of any security or interest in any investment vehicle sponsored, discussed, or mentioned by Protagonist, nor should it be construed as an offer to provide investment advisory services. Such offers or solicitations will be made separately by Protagonist and only by means of confidential offering documents of the specific investment vehicles which should be read in their entirety, and only to those who, among other requirements, meet certain qualifications under federal securities laws. There can be no assurances that Protagonist’s investment objectives will be achieved, or investment strategies will be successful. Any investment in a vehicle managed by Protagonist involves a high degree of risk including the risk that the entire amount invested is lost. Any description of investment advisory services, experience, and/or past results is not indicative of any future profitability or positive performance. The content is not intended to be, and must not be taken as, a basis for any investment decision.

The content should not be construed as or relied upon in any manner as investment, legal, tax, or other advice. You should consult your own advisers as to legal, business, tax, and other related matters concerning any investment. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in the content are subject to change without notice and may differ or be contrary to opinions expressed by others. Certain information contained in the content has been obtained from third-party sources. While taken from sources believed to be reliable, the information has not been independently reviewed or confirmed for accuracy, and as such, no representations are made about the enduring accuracy of the information or its appropriateness for a given situation. I do not warrant the accuracy, adequacy or completeness of the content and expressly disclaim liability for errors or omissions in the content. The content is provided on an “as-is” and “as-available” basis, and I disclaim all warranties and representations of any kind with regard to the content, including implied warranties of merchantability, non-infringement of third-party rights, or fitness for a particular purpose.