Undes is not optimized for polished chat replies. It is designed to produce structured engineering artifacts: evidence, rejected hypotheses, risks, open checks and a final recommendation.
Undes reviews a refactoring plan for OIDC middleware and identifies that the proposed fix does not fully protect the callback flow.
Undes analyzes why a planned file read is selected during planning but does not reach the final execution flow.
Undes runs as a background engineering review and reports missing tests, unsafe assumptions and areas requiring human confirmation.
Example 1
A developer asks Undes to review a refactoring of authentication middleware. The initial implementation looks reasonable, but one reviewer agent identifies that the lock is placed around the wrong part of the flow.
Refactor auth middleware to support OIDC. Review the proposed change for race conditions, unsafe assumptions and missing tests.
> refactor auth middleware to support OIDC
⏺ codex.gpt-5 implementing ✔
│ "Keeping session API; adding mutex around
│ acquire() — OIDC callbacks can race."
└─ 4 files changed · 142 lines
⏺ gemini.pro 2.5 reviewing ⚠
│ "handleCallback awaits exchange() without
│ holding the lock — duplicate sessions on
│ concurrent /callback requests."
└─ flagged: token-refresh race
⏺ claude.opus 4.7 reasoning ⟳ ▰▰▰▱▱
│ "Agree with gemini. The fix must cover
│ exchange() and session acquisition."
┌─ Trust gates ─────────────────────────────┐
│ ✔ payload ✔ impact ⟳ consensus · k3 │
└───────────────────────────────────────────┘The mutex must protect the full callback exchange and session acquisition path, not only the later session API call.
The agents compared the planned middleware flow, callback execution order, token exchange timing and duplicate session creation scenario.
“Adding a mutex around acquire() is enough” was rejected because the duplicate session can be created before acquire() is reached.
Add concurrent callback tests, failed token exchange tests and refresh-token regression checks before merging.
Example 2
In this example, Undes investigates why a file-read operation is selected during planning but disappears before the final execution flow. The point is not just to find a bug, but to show where the pipeline loses intent.
The execution flow does not consistently preserve the selected file-read request between planning, artifact resolution and final synthesis.
Call sites that write artifacts, normalize file requests, resolve paths and pass final context into synthesis.
The model may reason from incomplete context and repeat questions already answered earlier in the run.
Preserve canonical artifact state and make legacy aliases explicit rather than treating them as primary execution outputs.
Example 3
Undes can run as a background review step where speed is less important than review quality. The goal is to give the team a structured artifact before a risky change is merged.
undes run "Review this pull request for risky assumptions, missing tests, and unsafe architectural changes."Start with a real engineering concern: a bug, a refactoring, a fragile subsystem, or a pull request where the answer must be verified before merge.