QA Web Agent

A confirmed bug becomes a reviewed pull request.

Give the code agent an issue the platform already reproduced, or a plain brief. It edits in a writable checkout, pushes to a git host the platform owns, boots your app from its branch and looks at it, then runs the test that proved the bug against a fresh environment. What comes back is a diff with evidence for a person to graduate into a real pull request, or an honest "unable".

In the dashboard
Code changes · Issues
Feature specs
64, 66

The first time it ran end to end.

Times are from the run on 12 September 2026 against Jade's production copy of the platform. The change itself was trivial on purpose; the point was every hand-off in between working without a person touching anything until the review.

A code change's review: branch, commit, status validated, the brief, the outcome text, and the Graduate to PR and Dismiss actions beside the conversation.
  1. A Jade user files feedback"Make the admin header band pink throughout the dashboard" in Jade's Help Improve Jade wizard. Reference FTR-B346-HY75.
  2. Jade opens issue #1789Jade's own sweep mirrors the feedback to GitHub and hands the issue number to the platform's assign-agent endpoint.
  3. Code agent startsClones Jade, finds the shared admin-shell stylesheet, changes one line, pushes agent/issue-1789-dbd1e2de to the internal git host.
  4. Jade's poll picks up the changeThe feedback record now shows a proposed change with a link.
  5. Validation passesA fresh Jade boots from the branch; the named validation test opens the dashboard and confirms the band colour. session.webm is attached.
  6. A Jade engineer reviewsDiff, run and video on the Code changes screen. Graduate opens a real PR on mcievents/jade that closes #1789; the reporter's feedback page shows the validation recording.
Code changes → New code change (the seeded demo brief)
Brief:
  Fix the sale price shown on pricing.html to 25% off the $120.00
  list price ($90.00).

Test to self-validate against:
  seeded-code-challenge-pricing
  (passes when #sale-price reads exactly $90.00)

Outcome (one of):
  proposed          the change is pushed and the named test passed
  no change needed  the agent found the behaviour already correct
  unable            it could not make the test pass honestly

Three outcomes, no fourth.

A change that looked right in the agent's own browser but failed the named test is reported as unable, never as proposed. The agent can iterate: edit, push, restart the app from the branch, look, edit again. But the verdict that counts is the independent test on a fresh environment built from the pushed branch.

Every change carries its validation history. A reviewer reads the brief, the diff, the runs and the recording, then dismisses or graduates. Graduation creates a real branch on your repository, opens a PR against your configured base describing the change and how it was validated, attaches the evidence, references the issue it closes, and registers the PR as tracked so verdicts continue there. The platform never merges.

Internal git only

The agent's remote is a host the platform runs. A push to any other remote is refused. Your repository is touched only by graduation, by a person.

Per-job credentials

Each code task gets credentials minted with only its scopes, revoked when the job ends. External systems drive the same loop with an API key scoped to code changes and a callback URL.

Watch it work

Opt into a live activity feed and a frame-based view of the agent's browser while it edits, boots and checks. Ask it for a correction in the change's conversation; it continues the same branch.

Custom agents are data

A headless agent task is a definition: instructions, tool groups, scopes, budgets. The first one repairs a drifted environment patch, proves a box boots with it, and resubmits the blocked job.

Where it stops today

  • Validation runs the named test, not your whole suite. Nothing yet proves the change did not break something else; the graduated PR's own watched suite is where that happens.
  • The agent needs a clonable repository and a bootable environment definition. A project that only tests a fixed URL cannot use code changes.
  • Automatic retry of a code change after an infrastructure block is off by default (a change is a proposal, not a job to force through).
  • The internal git host keeps every agent branch; nothing prunes graduated or dismissed branches yet.

Questions people ask

Three gates. The agent can only push to a git host the platform owns. A change that failed its validation test is reported as unable, never as proposed. A person reviews the diff and evidence and chooses to graduate it, which opens a pull request that your normal review still has to merge.