Live data from Hacker News

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

hyperprobe.co

21–30 of 60 posts

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#21
Interesting technology but your landing page screams "I put no work into this design", probably want to rebrand away from generic claude design orange-on-brown.

A useful adjunct to this kind of production in-memory debugging is a read-only agent locked down role in AWS or equivalent. I believe amazon has just set up some kind of a wizard for configuring a role like this. It really gives agents the ability to relatively safely look at the prod setup without exposing sensitive details or making changes, especially with e.g. terraform

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#22
There are two pieces. An SDK that runs inside your service, and an MCP server your coding agent talks to. The SDK is what makes setting probes (virtual breakpoints, log or metric) possible without a redeploy. In Node and Python it hooks in-process. In Java it attaches as a JVM agent, instrumenting at the bytecode level. Either way the service keeps running and serving traffic. Nothing pauses.

Consider putting this near the beginning rather than 2/3 of the way down your pitch. I nearly stopped reading because these dramatic 1-2 sentence paragraphs are unpleasantly like listening to TV commercials. I think your target audience should not be CTOs or their direct reports, but engineers themselves, and I think you need a more focused pitch that takes less time to get to the point.

Anyway, an MCP-managed passive debugger seems like a useful tool. Best of luck with it.

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#23

Interesting technology but your landing page screams "I put no work into this design", probably want to rebrand away from generic claude design orange-on-brown. A useful adjunct to this kind of production in-memory debugging is a read-only agent locked down role in AWS or equivalent. I believe amazon has just set up some kind of a wizard for configuring a role like this. It really gives agents the ability to relative…

I agree, having an agent safely inspect infrastructure config and Terraform state via a read-only IAM role pairs really well with what we're doing. AWS roles handle the "how is the cloud environment configured?" question, while we handle the "what is happening inside the running process heap/memory?" question.

Also thanks for the candid feedback! (And fair call on the design — we definitely prioritized shipping core functionality over UI polish, but point taken on the orange/brown palette, we'll change it)

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#24

There are two pieces. An SDK that runs inside your service, and an MCP server your coding agent talks to. The SDK is what makes setting probes (virtual breakpoints, log or metric) possible without a redeploy. In Node and Python it hooks in-process. In Java it attaches as a JVM agent, instrumenting at the bytecode level. Either way the service keeps running and serving traffic. Nothing pauses. Consider putting this ne…

Appreciate the feedback, will try to highlight the how instead of why specially to devs

Although, our primary sell is debugging, the context from production on how things work currently helps ai agents during feature development and code reviews as well.

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#26

Interesting technology but your landing page screams "I put no work into this design", probably want to rebrand away from generic claude design orange-on-brown. A useful adjunct to this kind of production in-memory debugging is a read-only agent locked down role in AWS or equivalent. I believe amazon has just set up some kind of a wizard for configuring a role like this. It really gives agents the ability to relative…

I agree, having an agent safely inspect infrastructure config and Terraform state via a read-only IAM role pairs really well with what we're doing. AWS roles handle the "how is the cloud environment configured?" question, while we handle the "what is happening inside the running process heap/memory?" question. Also thanks for the candid feedback! (And fair call on the design — we definitely prioritized shipping core…

Counterpoint: nobody is going to care what the front page looks like designwise, as long as the words are right.

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#27
post #26

Earlier quoted context omitted.

I agree, having an agent safely inspect infrastructure config and Terraform state via a read-only IAM role pairs really well with what we're doing. AWS roles handle the "how is the cloud environment configured?" question, while we handle the "what is happening inside the running process heap/memory?" question. Also thanks for the candid feedback! (And fair call on the design — we definitely prioritized shipping core…

Counterpoint: nobody is going to care what the front page looks like designwise, as long as the words are right.

Normally I would completely agree with you, but default claude design makes people close tabs before they read a word. A `text/plain` markdown file would be better.

Re: Launch HN: HyperProbe (YC S26) – Agents that do read-only debugging in prod

#29
post #28

[flagged]

thanks! the read-only guarantee is structurally enforced by sdk itself

a probe is basically just a definition it contains the file and line number of the code you want to inspect

that is safe by default. there's no custom userland function that you can call

if you want conditional probes, then it get's tricky

here's how it works

NodeJS: v8 natively blocks if the code even tries to produce side effects using `throwOnSideEffect: true`

in python and java: conditions can be set on local variables only without accessors as of now. you can call functions, can only a subset of comparison operators.

so, you can set `total > 50` as a condition but not `order.total > 50` as it could in theory trigger a getter (which ideally should be fine, but devs/agents can make getters with side affects so we wont allow it for now)

We will support these use cases with a custom DSL for agents + AST parsing in the future which will let us safely evaluate these expressions.

Post reply on HN