Before running the install prompt, I’d want to see a dry run: which files it would touch, what telemetry leaves the box, provider calls, and what “high confidence” means. For debugging tools, generating a PR is the easy part; knowing whether it’s grounded in enough evidence is the part I’d worry about.
Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
41–50 of 60 posts
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#42Sorry to be crude, but this sounds either dead on arrival, or at least needing a pivot, or a rephrasing of the pitch: The moment something changes the system, it no longer observes it, in fact observing something might cause it to change ( https://en.wikipedia.org/wiki/Observer_effect_(physics) ) Either it's a tool for observing or it's a tool for fixing issues, it cannot be both, by physical principle. Best case sce…
The observer effect is that observing itself modifies the system. This is nothing to do with that.
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#43I would love to use it but the website is down
"Please check your network settings to confirm that your domain has provisioned.
If you are a visitor, please let the owner know you're stuck at the station."
Would love to learn more and consider being a customer!
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#44Building on the "investigation > patch" point — running Claude Code, Codex, and Gemini CLI daily, the pattern I keep noticing is that auto-fix is fine on "obvious bug, obvious fix" (off-by-one, null check, missing await, error not propagated). It falls over on "subtle invariant" bugs where the existing code is intentionally weird to preserve something non-obvious — the PR looks right and breaks something three modules away.
The tool I'd actually want isn't "tries harder to fix everything." It's one that credibly says "this touches an invariant I can't see — here's what I think might happen, you handle it." Calibrated humility beats confident patches.
Curious how your high-confidence threshold actually works. Self-reported model certainty (notoriously unreliable), test coverage in the affected area, blast-radius of the change, something else?
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#45[dead]
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#46Not their fault
Railway their hosting provider is entirely down as well
From https://status.railway.com/
>Identified
>Google Cloud has blocked our account, making some Railway services unavailable. We have escalated this directly with Google. The Railway Platform team has since confirmed access to Google Cloud and is working on restoring access to all workloads. We have access to some of our Google Cloud–hosted infrastructure and are working to restore the rest of the service. We apologize for the disruption.
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#47I would love to use it but the website is down "Please check your network settings to confirm that your domain has provisioned. If you are a visitor, please let the owner know you're stuck at the station." Would love to learn more and consider being a customer!
Apologies everyone! indeed our webapp unfortunately went down together with Railway - we're working hard to bring it up
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#48Building on the "investigation > patch" point — running Claude Code, Codex, and Gemini CLI daily, the pattern I keep noticing is that auto-fix is fine on "obvious bug, obvious fix" (off-by-one, null check, missing await, error not propagated). It falls over on "subtle invariant" bugs where the existing code is intentionally weird to preserve something non-obvious — the PR looks right and breaks something three module…
[dead]
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#49Not their fault Railway their hosting provider is entirely down as well From https://status.railway.com/ >Identified >Google Cloud has blocked our account, making some Railway services unavailable. We have escalated this directly with Google. The Railway Platform team has since confirmed access to Google Cloud and is working on restoring access to all workloads. We have access to some of our Google Cloud–hosted infra…
That's true, unfortunately. Very sorry abut this, and it's my fault that we weren't resilient to this failure. We'll be migrating the webapp to a more resilient architecture as a first priority.
The landing page is up again now but unfortunately will have to default to accepting demo requests for now :(
Re: Show HN: Superlog (YC P26) – Observability that installs itself and fixes bugs
#50Sorry to be crude, but this sounds either dead on arrival, or at least needing a pivot, or a rephrasing of the pitch: The moment something changes the system, it no longer observes it, in fact observing something might cause it to change ( https://en.wikipedia.org/wiki/Observer_effect_(physics) ) Either it's a tool for observing or it's a tool for fixing issues, it cannot be both, by physical principle. Best case sce…
How does a grep or read affect the observing system? I guess the change in voltages, arrangement of registers, filling of buffers in the network stack are changing but... what?
It is a well known phenomenon in haskell or OOP in general that just reading can cause systems to change their execution paths. Which is why it's not sufficient to make write/setters private, but reads/getters too.
However in the case of SuperLog the path to system change is quite direct
"We fix bugs. Superlog prepares a resolution PR for every incident. If Confidence Gate fails, it posts findings for the investigating team and pulls in the engineers who can add context."
The system literally pushes (or Pull requests, whatever, github is dead anyways) a code change.