Vibe coding vs open source: The math has flipped

Three months ago I rewrote my entire backend in Bun and Hono. That decision changed how I think about every technical choice.

I used to be the guy who would npm install first and ask questions later. Need authentication? Auth0. Need analytics? Metabase. Need LLM observability? LangSmith. That’s what you’re supposed to do. Don’t reinvent the wheel. Stand on the shoulders of giants.

Then I watched an AI agent write 500 lines of perfect observability code in 90 seconds. And everything flipped.

“The question isn’t ‘should I use open source or build it myself’ anymore. The question is ‘can I build this faster than I can learn the library’.”

This isn’t about being stubborn. It’s not about NIH syndrome. It’s about math. And the math has changed.

I’ve developed a simple framework for making these decisions now. It’s not perfect, but it works. And it’s saved me weeks of frustration.

The Implementation Deep-Dive

Case 0: Authentication

This is the easy one. Never vibe code auth. Never.

Every single person who thinks “oh I’ll just write a simple login system” ends up regretting it. Password resets. Email verification. MFA. Session rotation. Rate limiting. There are 47 edge cases you will forget, and one of them will get you hacked.

Auth0, Supabase Auth, Firebase, Keycloak - none of them are perfect. All of them will frustrate you at some point. All of them are still infinitely better than anything you will write in an afternoon.

This is non-negotiable. Some wheels do not get reinvented.

💡 Insight: Authentication is the only category where the cost of mistakes is catastrophic. No amount of time saved is worth exposing your users’ data.

Case 1: Omnichannel inbox

I used Chatwoot at my last company. It’s good. Solid docs. Stable. Reasonably fast. I would still recommend it to 90% of people.

But Chatwoot was built for human agents. I’m building for AI.

I don’t need assignment rules. I don’t need team inboxes. I don’t need SLA timers. I need every single message to flow directly into my agent’s memory. I need context about the customer, their previous conversations, their company’s knowledge base, all available before the AI even starts typing.

I spent three days trying to bend Chatwoot to do what I wanted. Then I deleted the integration and asked Claude to build me an inbox.

It took 90 minutes.

It does exactly what I need. Nothing more. Nothing less. And when I decide tomorrow that I want to add WhatsApp support, or voice calling, or any other weird feature, I can add it in 10 minutes instead of fighting someone else’s roadmap.

Case 2: LLM framework

LangChain builds abstractions over LLMs, adds middlewares and fallbacks, exports metrics and logs, wraps tool calls. For the core LLM orchestration logic, it’s still worth using. I don’t want to write my own retry logic for 12 different model providers. I don’t want to reimplement tool call parsing. That part is commodity, and LangChain does it well enough.

LangSmith is great for debugging during development. But I needed observability to be part of my product, not just a developer tool. I want control over what data I store, where I store it, and how I visualize it for end customers. I don’t want to send all my user’s conversation data to a third party. I don’t want to be locked into their pricing or their roadmap.

I spent an hour reading LangSmith’s API documentation to understand what features I actually used day to day. Then I asked Claude to build me a drop-in replacement. It took 2 hours.

Now I have:

• Full trace logging for every LLM call
• Cost tracking per user, per conversation
• Custom visualization that fits exactly into my dashboard
• No external dependencies, no extra bills
• The ability to add custom metrics whenever I want

I still use LangChain for the orchestration layer. I still use LangSmith for local debugging when I’m building new features. But for production, all observability runs on my own code. And when a customer asks “can we see how many tokens this conversation used?” I can add that feature in 10 minutes instead of waiting 6 months for LangSmith to ship it.

💡 Insight: Use libraries for the boring commodity parts. Build the parts that make your product unique.

Case 3: Real-time communication

Some things you never build yourself.

Voice calling. WebRTC. Echo cancellation. Network resilience. This is not vibe code territory. This is the kind of problem that 100 engineer teams spend 5 years solving and still get wrong.

I looked at it for approximately 10 minutes. Then I signed up for LiveKit and sent them my credit card.

They solved it. They did the hard part. I don’t want to learn about ICE candidates. I don’t want to debug jitter buffers. I don’t want to think about packet loss. I just want to make a phone call work.

This is the line. This is where the ratio flips.

If it’s a commodity problem that 1000 other people have solved exactly the same way? Use the library. If it’s your core differentiator? If you need to change it every week? If you have one weird requirement that nobody else has? Build it.

Case 4: Embedded analytics

And I don’t need dashboards. I don’t need pivot tables. I don’t need to share reports with investors. I just need answers to very specific questions.

“How many conversations had pricing mistakes last week?” “What’s the average response time per channel?” “How many users actually use the voice feature?”

I used to spend an hour every week building new Metabase dashboards. Then I realized something: I can just ask Claude to write me a query.

I type “show me average response time broken down by channel for the last 7 days” and 10 seconds later I have the exact numbers. No dashboard. No setup. No waiting for Metabase to render.

I deleted Metabase. I saved $50/month. I get answers faster. And nobody is asking me for dashboards anyway.

💡 Insight: For solo founders, AI turns every database into a business intelligence tool. You don’t need dashboards when you can get answers directly.

The Tradeoffs

This is not a manifesto against open source. This is a manifesto against cargo culting.

The rule everyone tells you is:

“Don’t reinvent the wheel”

But nobody tells you the fine print:

Unless learning the wheel takes longer than building it.

And with AI coding agents, that line moves every single day.

Here’s what I give up when I vibe code:

• No battle testing: My observability code has 3 edge cases LangSmith already fixed. I will hit them. I will fix them. It will take 10 minutes each.
• No community: When something breaks, I can’t Google it. I have to read my own code.
• No free features: I will never get that fancy timeline view that LangSmith shipped last week. I don’t need it.

And here’s what I gain:

• Total control: I can change literally anything in 10 minutes.
• Zero learning curve: I wrote it. I understand every line.
• Perfect fit: It does exactly what I need. Nothing more. Nothing less.

The Verdict

“The biggest lie in software development is that ‘reusing code is always better’.”

That was true 10 years ago. That was true before AI coding agents. That was true when writing 500 lines of code took a whole day.

Now writing 500 lines of code takes 90 seconds. Now understanding someone else’s 500 line abstraction takes 3 days.

The math has flipped.

This is the new arithmetic. This is the thing no blog post will tell you.

You still shouldn’t build your own database. You still shouldn’t build your own WebRTC server. You still shouldn’t build your own programming language.

But for everything else? For all the boring glue code that makes up 80% of your application?

Just build it.

The giants whose shoulders you’re standing on? They’re just as confused as you are. Their code has just as many bugs. And now you can write exactly what you need faster than you can read their documentation.

If you’re a solo founder and you’re spending more than 2 hours trying to integrate a library, close the tab. Just ask the AI to write it for you.

You will be shocked at how well it works.

Tell me I’m wrong. I will argue with every single one of you in the comments.