HyperProbe (YC S26) – Agents that do read-only debugging in prod

Hi HN, this is Shailendra and Karan here. We are building a fast and safe way for coding agents to debug issues live in production.When prod breaks, it lets Cursor, Claude, and others drop virtual breakpoints or probes safely in your running code, and extract the exact variable values that logs don’t have.All this saves time and effort for engineers who’d otherwise dig through logs and traces or redeploy with console.logs or print statements until they find the root cause.Here is the link to the video that explains this: https://www.youtube.com/watch?v=ivV7I--ta5cAgents write most of our code now. This shrinks the useful context engineers need to debug AI written code, a problem not helped by the limited telemetry added in the same code by AI.So when something breaks in prod, the first instinct for an engineer is to open logs or throw them to your agents. But if the line you are looking for is not there, agents will start guessing the root cause on non-existent data, forcing you to add a log, and redeploy.This analysis-inference loop of agents with existing data does not come cheap, burning a lot of tokens. And the add log, redeploy cycle is so slow and painful that it makes engineers hate on-call.Our approach lets agents capture telemetry on-demand at the exact moment and point of failure, killing the log-redeploy cycle and getting the most accurate RCA while burning fewer tokens.The obvious problem is making it work on a running service. You can't pause a live service the way you'd pause a debugger on your laptop. Getting the value out of a running process safely, without pausing a thread or slowing the host is the challenge.We are making this happen.Before this I ran engineering at a 100 member team. Then Karan and I spent three years on HyperTest which was a testing tool.At HyperTest, we turned production traffic into integration tests using OpenTelemetry. That was production instrumentation too. The hard parts of pulling real runtime st

Hacker NewsToolAISource
0Sign in to voteCopy link

FL score

72

out of 100

Verdict

VALIDATE

high confidence

Competition

No competitor data yet

Trend

No signal yet

Enable AI coding agents to safely extract live variable state from production without redeployment, cutting debugging cycles from hours to minutes.

The pain

When production breaks, engineers either dig through incomplete logs, redeploy with added logging statements (slow, risky), or feed agents guessing games on incomplete data (expensive token burn). The cycle repeats until someone manually finds the missing telemetry point. With AI-written code, this gets worse because the code lacks intentional instrumentation and engineers lack context.

The gap

No tool exists that lets agents (or engineers) safely inject read-only probes into live running services without pausing threads, degrading performance, or requiring redeployment. Traditional debuggers pause execution. Log aggregation tools miss the exact variables you need. Existing APM tools are passive and slow to query.

Build angle

The founders have direct experience shipping production instrumentation at scale (HyperTest used OpenTelemetry to turn prod traffic into tests). They understand the hard problem: extracting state from a live process without blocking it. The timing is right because AI agents now write most code and need better debugging primitives than humans do. The wedge is clear: start with Cursor and Claude integrations, let agents request specific variable values at specific code locations, execute safely in-process.

Strengths

  • Founders have 3 years of production instrumentation experience and shipped a related product
  • Solves a real, growing pain as AI agents write more code and lack good debugging tools
  • Clear technical moat: the hard part is safe in-process probe injection without performance degradation
  • Natural integration points with existing tools (Cursor, Claude, other agents)
  • Reduces token spend and engineering toil simultaneously, dual value prop
  • YC backing and S26 cohort timing suggests strong initial traction

Risks

  • Technical execution risk is high: injecting probes into live processes is genuinely hard and requires deep systems knowledge; one mistake causes outages
  • Security surface is large: agents requesting arbitrary variable values from prod could leak secrets, PII, or internal state if access control is weak
  • Adoption requires engineers to trust a third-party tool with production code execution; trust takes time to build
  • Market may be narrower than assumed: only teams using AI agents for coding + running complex services + willing to adopt new debugging tools
  • Competitive risk from cloud providers (AWS, GCP, Azure) adding similar features to their observability stacks
  • Pricing model unclear: if priced per-probe or per-query, could become expensive at scale; if flat-rate, hard to capture value

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “HyperProbe (YC S26) – Agents that do read-only debugging in prod”.

Open FlyBot