Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod
hyperprobe.co shailendraht ● Covered by 2 sources
HyperProbe lets coding agents like Cursor or Claude drop read-only debug probes into live production code, no redeploy needed. It skips the log-guess-redeploy loop engineers hate, pulling real variable data at the exact moment things break.
Based on reporting by hyperprobe.co, shailendraht — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
There's a specific kind of pain every on-call engineer knows: prod breaks, the logs don't have the one line you need, so you add a print statement and redeploy, then wait, then repeat. HyperProbe, launched on Hacker News by Shailendra and Karan, is built to kill that cycle by letting AI coding agents place virtual breakpoints directly into a running service and grab the exact local variable values at the point of failure.
The pitch is straightforward. You tell your coding agent what's wrong in plain language, something like checkout returns 200 but some orders fail. The agent finds the relevant line locally, connects over MCP, and drops a read-only probe on that line in the live service. The probe sits dormant until real traffic actually hits that line, then captures the local variables across the call stack and hands them back to the agent for diagnosis. No new deploy, no guessing from incomplete logs.
Under the hood there are two components: an SDK living inside the service, and an MCP server the coding agent talks to. In Node and Python the SDK hooks in-process; in Java it attaches as a JVM agent instrumenting at the bytecode level. Either way, the service keeps running and serving requests. Captured data gets sanitized in-process before it ever leaves the container, with keys like password, token, authorization, and credit card redacted by default, and teams can add their own redaction rules. The founders also note you can self-host the server, broker, and database if you don't want captured state leaving your network.
On overhead, the claim is that idle probes cost effectively nothing in memory or response time, and only active captures carry any cost, with a separate monitor watching for spikes and pulling probes if things get out of hand. The founders previously spent three years building HyperTest, a testing tool that turned production traffic into integration tests using OpenTelemetry, and say that work taught them the hard parts of extracting runtime state from a live service without breaking it. That earlier project also taught them something about priorities: testing felt like hygiene to teams, but a broken prod service was the fire everyone dropped everything to fight, which is what pushed them toward building something aimed squarely at incident response.
Right now HyperProbe supports Node.js, Java, and Python, and the team frames this as a step toward a more autonomous on-call agent, one that could eventually take an alert, probe the system, diagnose it, and fix it without much human involvement. For now it's asking the HN community to try it against real or synthetic prod issues and report back what's missing.
My take — AI-written commentary, not fact-checked reporting
The redeploy-and-pray debugging cycle has been a quiet tax on engineering teams for years, so a read-only probe that captures real runtime state without a restart is an obviously useful idea rather than a flashy one. The bigger tell here is the founders' own admission that testing tools always lose the internal priority fight against actual production fires — that's a sharp, honest observation about how engineering orgs actually behave, and it's smart to build toward the fire instead of the hygiene. Whether this becomes the fully autonomous on-call agent they're teasing is a separate bet, and a much harder one to win.'
Read more about this at: hyperprobe.co
