Show HN监视用户会话，发现重要的错误并修复它们
嘿HN,<p>我是Abhishek。我正在构建Opslane，一个开源代理，用于识别面向用户的问题并进行调查。它只会创建一个PR如果它可以验证修复。<p>演示：<a href="https://youtu.be/ccuOTYQMeYg" rel="nofollow">https://youtu.be/ccuOTYQMeYg</a> 文档：<a href="https://docs.opslane.com">https://docs.opslane.com</a><p>在我之前在 Robinhood 的工作中，我们经常做季度性漏洞清理。我们会浏览 Sentry 的待处理问题，并尽量修复尽可能多的问题。我们只修复已知由客户报告的漏洞。
查看英文原文
Show HN: Watches user sessions, finds bugs that matter, and fixes them
Hey HN, I’m Abhishek. I'm building Opslane, an open-source agent that identifies user-facing issues and investigates them. It only creates a PR if it can verify the fix. Demo: https://youtu.be/ccuOTYQMeYg Docs: https://docs.opslane.com At my last job at Robinhood, we used to do a quarterly bug bash. We would go through our Sentry backlog and try to fix as many of them as possible. We only fixed bugs we knew were reported by customers. We had hundreds of bugs, and Sentry’s default priority levels made no sense. After the bug bash, we would declare bankruptcy - select all remaining bugs and mark them as resolved. This problem has only gotten worse since coding agents have become more prevalent. So I started thinking: what would Sentry look like if it were built in 2026? To me, error trackers have two failure modes: 1. False positives: They show you thousands of errors, and you can’t tell the impact on the user 2. False negatives: Many user-facing issues don’t throw exceptions, so they go unnoticed. Opslane combines error tracking and session recording. And there is an agent that acts on both. To get started, you install the Opslane SDK. It captures everything the user did: errors, console logs, network requests, and session recordings. Opslane reduces false positives by ranking issues based on how many users are facing a particular issue. It also learns about your product by reading your code and watching your session recordings. False negatives are harder. Opslane reviews session recordings to spot frustration. They look for rage clicks, dead clicks, and abandoned forms. This recently caught a bug in an early customer’s onboarding flow: a dropdown that closed itself when clicked. No exception, no bug report. The recordings showed users clicking it, selecting nothing, and dropping out of onboarding. Opslane flagged it and the team fixed it. Three guiding principles when building Opslane: 1. Open Source: Self-host with one Docker Compose file. 2.Agent-first: I never want to open an error dashboard again. Opslane ships an MCP server, so you can ask "what broke for users this week" from Claude Code. You get back issues that need your attention and you drive the resolution. 3. It knows about your product: Opslane is continuously learning about your product. Every investigation begins with what it knows about your product. It’s early. Frontend apps work end to end today.I am currently focused on improving reliability and accuracy. Here is a link to our repo: https://github.com/opslane/opslane Would love to get feedback from folks on our approach to this problem!
Show HN: Watches user sessions, finds bugs that matter, and fixes them
Hey HN,<p>I’m Abhishek. I'm building Opslane, an open-source agent that identifies user-facing issues and investigates them. It only creates a PR if it can verify the fix.<p>Demo: <a href="https://youtu.be/ccuOTYQMeYg" rel="nofollow">https://youtu.be/ccuOTYQMeYg</a> Docs: <a href="https://docs.opslane.com">https://docs.opslane.com</a><p>At my last job at Robinhood, we used to do a quarterly bug bash. We would go through our Sentry backlog and try to fix as many of them as possible. We only fixed bugs we knew were reported by customers. We had hundreds of bugs, and Sentry’s default priority levels made no sense. After the bug bash, we would declare bankruptcy - select all remaining bugs and mark them as resolved.<p>This problem has only gotten worse since coding agents have become more prevalent.<p>So I started thinking: what would Sentry look like if it were built in 2026?<p>To me, error trackers have two failure modes:<p>1. False positives: They show you thousands of errors, and you can’t tell the impact on the user<p>2. False negatives: Many user-facing issues don’t throw exceptions, so they go unnoticed.<p>Opslane combines error tracking and session recording. And there is an agent that acts on both. To get started, you install the Opslane SDK. It captures everything the user did: errors, console logs, network requests, and session recordings.<p>Opslane reduces false positives by ranking issues based on how many users are facing a particular issue. It also learns about your product by reading your code and watching your session recordings.<p>False negatives are harder. Opslane reviews session recordings to spot frustration. They look for rage clicks, dead clicks, and abandoned forms.<p>This recently caught a bug in an early customer’s onboarding flow: a dropdown that closed itself when clicked. No exception, no bug report. The recordings showed users clicking it, selecting nothing, and dropping out of onboarding. Opslane flagged it and the team fixed it.<p>Three guiding principles when building Opslane:<p>1. Open Source: Self-host with one Docker Compose file.<p>2.Agent-first: I never want to open an error dashboard again. Opslane ships an MCP server, so you can ask "what broke for users this week" from Claude Code. You get back issues that need your attention and you drive the resolution.<p>3. It knows about your product: Opslane is continuously learning about your product. Every investigation begins with what it knows about your product.<p>It’s early. Frontend apps work end to end today.I am currently focused on improving reliability and accuracy.<p>Here is a link to our repo: <a href="https://github.com/opslane/opslane" rel="nofollow">https://github.com/opslane/opslane</a><p>Would love to get feedback from folks on our approach to this problem!
- 来源
- Show HN · show-hn
- 证据角色
- project_and_comment_discovery
- 时间状态
- known
- 用户判决
- 未判