For small teams that keep debugging the same integration or configuration failure
A diagnosis, with its evidence, for the failure your team keeps debugging
Uncurse is an idea under test, and none of it is built. In our first test a general coding agent answered all six of the made-up cases we wrote correctly, so we are looking for a real recurring failure that such tools get wrong.
Write to us about an error that keeps coming back
The project reads mail sent to hello@uncurse.ai and replies by email. Describe the failure in words; do not send logs, secrets or customer data.
Where it stands
- Nothing is built: there is no intake, no redaction step, no sandbox and no product to try.
- One test has run, once, on 11 October 2026: a general coding agent with no help from us answered all six made-up webhook signature cases correctly, one of them by saying the evidence was too thin. We wrote the cases ourselves, so this is weak evidence.
- Our own rule, set before the first test ran: no separate product until a real team shows a kind of failure that general coding tools get wrong.
- A second test, on real public error reports, is being prepared and has not run.
- No team has used Uncurse and nobody has paid for anything.
Checked
How it is designed to work
This is the design on paper. Each step below is planned and none is built.
- One supported kind of failure
- Uncurse would take one class of error at a time and say plainly when a case falls outside it. The class in our first test was webhook signature checks that fail; no class has been chosen for a product.
- Redacted logs in
- The team sends logs it has already redacted. Redaction is also a step of the design, because a secret that slips through is one of the failures it has to be tested against.
- Causes that point at their evidence
- Each suspected cause links to the log lines or source it rests on. Where the evidence is too thin, the answer is that the cause cannot be determined.
- Reproduction in a sandbox
- The failure is reproduced in a sandbox, not on the team's systems.
- A proposed patch with tests
- The output is a written report and a proposed patch with tests. The team decides whether to apply it.
- A reviewer for uncertain cases
- The design gives uncertain cases to a technical reviewer who is accountable for the answer.
What it does not do
- It does not touch production
- The design works from supplied logs and a sandbox. Nothing is changed in production automatically; any change waits for the team's approval.
- It does not run what a log says
- Logs are untrusted text. A command or instruction found inside one is never executed.
- It does not promise a repair
- Some cases will be unsupported and some diagnoses will be wrong. The design counts accepted diagnoses and false fixes, and nothing here promises that a case can be fixed.
- A confident answer is not proof
- The team that owns the system decides whether the evidence holds.
- Nothing supernatural, nothing clinical
- On this page the name refers to an error that keeps coming back. Uncurse has nothing to do with superstition, and it is not a mental-health product.
How this differs from tools you may already use
General coding agents can already read a handler and a log and suggest a fix. In our test one answered all six cases correctly, including one with a secret printed in the log and one with an instruction planted in it.
At least one error-monitoring product now drafts fixes from the telemetry it collects, and webhook tools let you inspect a request with its headers and signature.
What Uncurse would add is narrow: one class of failure, logs the team redacts and sends itself, an answer that says what the evidence does not show, and no change made without the team. We do not know whether that is worth having beside those tools; on our made-up cases the general agent was enough.
If your team cannot use a general tool because code and logs may not be pasted into it, that constraint is the first thing we would want to hear about.
Who is behind it and how to take part
Uncurse is run by a small team, with AI agents doing much of the work. It may end up as a feature of another tool the same team is building, or as a reserved name, instead of a product of its own; the plan allows for both.
What would help most is a team that has hit the same integration or configuration failure more than once and can say what its current tools made of it. Write to hello@uncurse.ai and describe it in words.
Please do not send logs, secrets or customer data. Nothing is in place to receive them safely.