Every finding, proven before it's posted.

FORJEDAI clones your repository and reviews a pull request against the code around it. Every finding then goes to a second, independent model that tries to refute it. What survives lands inline on the exact line. The rest you never see.

Pull request #482 · fix/partial-refunds

forjedai refund.ts:43

amount can exceed the charge total on a second partial refund — amount_refunded is never checked before refunds.create.

Traced from retryQueue.ts:88, which retries this call unconditionally on failure.

jdoe

@forjedai is this actually reachable from the webhook path?

forjedai

Yes — webhooks/stripe.ts:112 calls issueRefund directly on charge.refunded events, same unguarded path.

Most AI review is fast. Being fast isn't the point.

An automated review only helps if engineers trust it enough to read it.

Pattern-match the diff in isolation, missing anything outside it.
Confidently flag issues that were already guarded three lines up.
Post so many low-value comments the team mutes the bot within a week.

Works in a clone of your repo: outlines files, jumps to definitions, greps for call sites.
Hands every candidate to a judge from a different model family, which re-reads the source itself rather than trusting the quote.
Drops anything the judge can't confirm at 80% confidence. Silence beats a bad comment.

From install to inline comment.

Install the GitHub App

Add FORJEDAI to your org or a single repo. GitHub is the login, so there's no separate account and no password to manage.

It investigates the pull request

Static analysers run first, so the agent never speculates about what a linter already knows. Then it opens the files around the diff and follows the code until it can prove or drop each suspicion.

Survivors post inline, with their evidence

One review, on the exact lines, citing the code each finding is built on. If a line has moved on since, the comment degrades to the summary instead of landing in the wrong place.

It keeps up as you push

Each new head re-checks the open findings and closes the ones you've fixed. Push five times in a minute and you get one review of the latest commit, not five.

The parts that decide what not to say.

It has to show the code

A finding can't be submitted without the evidence it rests on, and the loop checks the agent actually fetched those lines. No citation, no comment.

A judge that isn't itself

The reviewer and the judge are deliberately different model families. A model marking its own homework isn't a check, so the judge re-reads your source and argues the other side.

Native to the pull request

Findings arrive as one GitHub review on the exact lines. Nothing to open, nothing to check, no dashboard pretending to be your workflow.

Argue back, and it learns

Disagree in a reply and it re-clones and re-investigates properly. Win the argument and that becomes a standing lesson for the repo, so it stops making the same mistake in your codebase.

Resolves on push

Every new commit re-checks the open findings against freshly read code and resolves the threads you've addressed. When it isn't sure, the finding stays open.

It knows what your language rules out

PHP, Rust, TypeScript, JavaScript, Vue and YAML each carry their own rules. It won't spend a comment on a null-deref Rust's type system already made impossible, and it will catch no quietly parsing as false in your YAML.

Not open to everyone yet.

FORJEDAI is in private testing on a small number of repositories while we tune what it's willing to say. If you want your pull requests in that group, put your name down.

Every repo, every member. Access follows your GitHub org, so there's nothing to seat-count.
The whole engine. Testers get the same review, disputes and resolve-on-push we ship to everyone. No feature gating.
Pricing lands when billing does. It'll be per organisation, never per seat. Testers hear the numbers first.

Request early access

The awkward questions first.

Three things, in order. The reviewer can't submit a finding without attaching the code it rests on, and we check it really did read those lines. A judge from a different model family then re-reads that code from your repo, ignores the reviewer's summary of it, and argues the finding down. Anything left under 80% confidence is dropped. When a check fails or a response comes back garbled, the finding is withheld rather than posted, so the failure mode is silence.

It clones the repo to review it, and nothing you write is used to train a model. The agent's tools are read-only and there's no shell in the loop: search is a native code path, not a spawned grep, and every path is checked before it's opened. Static analysers run network-isolated, and code from a fork is never executed. The one thing it does remember is a finding you successfully argued down, kept as a note against your repo.

PHP, Rust, TypeScript, JavaScript, Vue/HTML and YAML get language-specific judgment: it knows Rust's type system already rules out a null-deref, and that no in unquoted YAML is the boolean false. C# and anything else still gets reviewed and still gets static analysis, but without those per-language rules, so expect it to be more cautious there.

Reply to the comment and say so. It works out whether you're actually disputing the finding or just asking something, and a real dispute gets a fresh clone and a proper re-investigation rather than a polite apology. It'll uphold the finding or overturn it, and an overturned one becomes a standing note for that repo. You can also @-mention it anywhere in a thread to ask about the PR.

Each new head re-checks the open findings against the code as it now stands and resolves the threads you've fixed. If it can't tell, the finding stays open rather than quietly disappearing. Rapid pushes collapse into a single review of the newest commit, so a force-push storm doesn't produce a pile of stale reviews arguing with each other.

Most of them read the diff and post what they suspect. The interesting part of FORJEDAI is what it decides not to say: findings are argued down by a separate model before you ever see them, and every review keeps the deliberation, so we can tell you why something was dropped, not just that it was. It's a slower, more expensive way to run a review, and the point of it is that the comments are worth reading.