Feb 9, 2025
Blar Success Case: Vambe
Introduction
We first met Vambe in San Francisco when they joined Berkeley’s SkyDesk program. From day one, there was a natural synergy between our companies. Despite differences in product and market focus, we were both deeply rooted in AI and shared strikingly similar backgrounds.
We admired Vambe’s relentless drive and rapid expansion. But with fast growth came new challenges, especially in maintaining code quality as new developers joined the team. One of their first priorities was implementing a streamlined process for reviewing pull requests (PRs) without slowing down development.
At the time, we were still refining Blar, so Vambe decided to try out existing solutions in the market. Just one day later, they reached out to us, eager to know when Blar would be ready. The reason? The tools they tested simply weren’t cutting it.
They faced issues like:
❌ Excessive false positives, leading to wasted time
❌ Superficial suggestions that lacked depth or context
❌ A failure to explore the codebase thoroughly, making insights ineffective
❌ No alignment with their internal coding standards
The problem became so severe that when we interviewed Vambe’s developers, most admitted they actively ignored PR comments, calling them “useless.” The tools were supposed to help them catch issues, but instead, they had become noise—irrelevant, unhelpful, and ultimately disregarded.
Vambe needed a solution that truly understood their code and workflow—not just another tool that flagged random issues, but one that could pinpoint meaningful, hard-to-find oversights that actually mattered.
The Turning Point
Vambe’s frustration with existing tools was growing. Their developers were spending more time sifting through false positives than actually fixing issues. Code reviews, instead of being a safety net, had become a bottleneck.
Every day, they would message us, asking, “When will your solution be ready?” They weren’t just interested, they were eager for a change.
When we finally released Blar, Vambe didn’t hesitate to try it, but they weren’t going to make it easy for us. They had seen too many tools fail to deliver real value, and they wanted proof that Blar was different.
The Challenge
When we first launched, we still faced some of the same issues that plagued other tools, some false positives, occasional irrelevant suggestions, and gaps in contextual understanding. Vambe saw this as an opportunity. Instead of immediately adopting Blar, they offered us a challenge:
"We’ll run Blar alongside the competition on the same repository. We’ll only pay if every one of our developers agrees that Blar is better than what we currently have."
It was a bold test, and we accepted. What followed was two intense weeks of tweaks, improvements, and continuous feedback. Vambe’s developers didn’t hold back, they pointed out every flaw, every misleading suggestion, every missed opportunity.
We took every comment seriously, refining Blar’s algorithms, improving its contextual awareness, and adjusting its sensitivity to better align with real-world coding practices. The process was demanding, but it was exactly what we needed.
The Breakthrough
By the end of the two weeks, something changed.
Vambe’s developers, who had initially been skeptical, started relying on Blar’s suggestions more and more. The noise was mostly gone. The insights were sharp, relevant, and genuinely helpful.
Finally, Vambe made their decision. They turned off the other solutions and switched to Blar exclusively.
Speed: A Critical Factor
For Vambe, speed in code reviews was just as important as accuracy. As they scaled, they needed a tool that could catch issues instantly without disrupting development.
Blar delivered. By parallelizing reviews, we made PR review time independent of PR size, achieving more than 10x speed improvements in some cases.
One of the most memorable moments came on December 31st, when Vambe’s engineering team, couldn’t help but comment on Blar’s speed:
💬 Eng1: "Anda veloz 💨" (It’s blazing fast!)
💬 Eng2: "Quien le dio ❄️❄️ a blar?" (Who gave Blar ❄️❄️? 😏)
💬 CTO: "Anda express." (It’s moving at express speed!)
💬 Eng2: "Están volando los PR reviews." (PR reviews are flying! 🚀)
The Impact: First Month with Blar
In just the first month of using Blar, the results were clear:
🚀 Blar surfaced 31 critical insights that developers found meaningful. And if you know Vambe, you know they demand excellence—so these flagged issues weren’t just minor mistakes, they were real lifesavers.
🚀 18 bugs caught, meaning 54+ hours of debugging saved
🚀 8 optimization recommendations, leading to key performance improvements
🚀 Even capturing a few cybersecurity issues
These weren’t just generic AI suggestions—every one of these insights was validated by Vambe’s developers, who gave them a thumbs-up in their PRs. For a team that had grown frustrated with irrelevant and misleading review tools, this was the ultimate proof that Blar was different.
By eliminating false positives, enforcing coding standards, and optimizing PR review processes, Blar helped Vambe:
✅ Reduce time wasted on irrelevant PR comments.
✅ Improve security, performance, and debugging workflows.
✅ Ensure code consistency across their growing team.
By replacing unreliable tools with Blar, Vambe’s engineers finally had an AI-powered assistant they could trust—one that worked with them instead of against them.
Conclusion
For Vambe, Blar was more than just a tool—it was a game-changer. By cutting through the noise, surfacing only the most critical issues, and seamlessly integrating into their workflow, Blar transformed their approach to code reviews.
No more wasted time on irrelevant suggestions. No more second-guessing automated insights. Just a reliable AI assistant that helped them write better, more secure, and more efficient code.
What started as a challenge ended in a complete shift—Vambe didn’t just adopt Blar, they made it an essential part of their engineering culture. 🚀
But don’t take it from me—here’s what Vambe’s CTO had to say:
“We finally found a solution that doesn’t suck and can do the job.”
Extra: Turning Code Reviews Fun—The Roast Feature
At Vambe, engineering culture isn’t just about writing great code—it’s about enjoying the process. One day they came to us with a unique request:
"Can Blar roast our pull requests based on the issues it finds?"
Challenge accepted.
We built a fun, quick feature that roasts your PRs based on the number and severity of detected issues. If your code is messy, prepare for some AI-generated banter.
Vambe’s engineers loved it, so much so that they started sharing the best roasts internally and across their dev community. What started as a playful idea quickly became a team favorite, making PR reviews not just efficient but genuinely entertaining.
“This code is like a bad haircut—too many layers and no direction! If you think 'CriteriaStatusStatusApi' is a good name, I can only imagine what you call your pets.”
Now, if anyone wants their pull request roasted, contact us. 🔥🚀 If enough of you ask, maybe we make it a thing.