I built an AI agent that opens GitHub PRs on your SaaS. Here's how it went.
I've wasted so much time staring at PostHog funnels.
Like, I know that 40% of users drop off between signup and connecting their first integration. I can see it. The funnel just sits there mocking me while I go fix some unrelated bug or ship a feature nobody asked for.
The actual problem isn't finding the friction. It's that turning "users drop off here" into a PR takes maybe 2-3 hours I never seem to have. So the data rots.
I got frustrated enough to just build the fix myself. Velyr connects to your PostHog and your GitHub repo, finds the drop-off, writes the fix, and opens a PR. Then it pings you on Telegram, just a message like "hey, 38% of users quit on this step, I wrote this fix, want me to open the PR?" You say yes or no. That's it.
Nothing touches production automatically. No auto-merges. I'm paranoid about that stuff too, so I designed it so you always have to explicitly approve before anything hits your repo.
Opening it up with a 14-day free trial right now.
Genuine question for anyone who's been in this situation: if a tool messaged you with a concrete fix for a drop-off you already knew was there, would you trust the PR, or would "AI touched my repo" be a dealbreaker regardless?
The 'no auto-merge' and Telegram ping feature completely removes the 'AI touched my repo' fear for me. If I can review the PR just like a human team member's code, it's a huge time saver.
Quick question: How does Velyr handle complex codebases with a lot of custom UI components? Does it ever hallucinate dependencies?
To your question: "AI touched my repo" alone isn't a dealbreaker for me — but the trust threshold depends entirely on what the AI touched and how verifiable the change is.
A PR that rewrites a single onboarding step based on a clear drop-off signal? I'd review and merge that in 10 minutes. It's bounded, the intent is obvious, the diff is small.
A PR that modifies auth logic or data models? I'd want to understand the full reasoning chain before touching merge. Not because I don't trust the AI, but because the blast radius of a mistake is orders of magnitude larger.
The design you described — explicit approval, no auto-merge, Telegram ping with context — is exactly right. You're not asking me to trust the AI's judgement. You're asking me to trust my own judgement about whether a specific, bounded diff looks correct. That's a very different ask.
The remaining friction is probably: how good is the fix quality? A PR that misdiagnoses the drop-off cause and ships a wrong fix would erode trust faster than never building the tool at all.
I’d be careful treating trust in the PR as the main decision.
A lot of founders already trust humans to ship bad fixes and AI to ship good ones.
The harder question is whether the user believes Velyr identified the right problem before it started writing code.
That distinction matters because the adoption bottleneck may sit earlier than the PR itself.
I wouldn’t make the actual call casually in-thread because it changes what users think they’re approving in the first place.