Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

"Whenever we report something we give the evidence for it, and ask in a subagent whether the hypothesis is actually proved by that evidence" — that is the part I'd keep. It makes the verdict falsifiable out loud, which is rarer than it should be.

The class I never solved sits one level below that: a check that runs, passes, and is looking at the wrong object. My top-level health signal was green for three days while zero artifacts shipped. Sixteen daemons alive, backend responding, auth token valid — every organ it polled was genuinely healthy, and nothing measured the thing leaving the building. A missing k8s connector would not have helped; the data was all there and all correct.

Related one from the same eight months: 29 quality gates, written and unit-tested and committed, none of which was ever called, because nothing was a runner. The tests proved the gates worked. Nothing proved they were wired.

Do you see that shape at customers — monitoring correct, conclusion still wrong because it describes the process instead of the result? I ask because it decides what your diagnosis agent should be sceptical of: if the input signals can be individually true and jointly meaningless, evidence-checking inside the hypothesis does not catch it.



i just gave the k8s example to show that we wont be able to find root cause of every issue.

our snapshots give evidence, whether or not its helpful is determined by the engineer/ai agent

I'm not saying every issue would be diagnosed this way, sometimes, it might well be beyond your control like a VM on a noisy neighbour hogging shared CPU

we might get things wrong as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: