Autopilot proposes. A human decides. The default autonomy is propose: the agent diagnoses, writes a fix, and opens a Pull Request. It does not merge, it does not deploy, and it does not decide which version ships. That boundary is a design decision, not a missing feature.
The problem it solves
A critical error reaches your issue tracker at 02:00. By the time someone reads it, the context is cold: which build, which customer, which change caused it. The first hour of every incident is spent rebuilding what the machine already knew.
Autopilot closes that gap. The moment a critical bug lands, it starts the work a developer would start — read the report, find the suspect code, propose a fix — and hands you a reviewable Pull Request instead of a blank page.
The full chain, end to end
This is the real path, taken from how we run IndoHRM against its hrm repository on GitLab.
| Step | Who | What happens |
|---|---|---|
| 1 | Your app | A critical error is reported into the Oprex issue tracker — from your error handler, your CI, a support ticket promoted to a bug, or a person. |
| 2 | Oprex | The bug is created with severity, environment, and product version. If it matches the configured severity and project filters, Autopilot is triggered automatically. Nothing matching? Nothing happens — and the manual button always works anyway. |
| 3 | Autopilot (Aidan) | Resolves where the code lives — the GitLab connection configured for that project, e.g. hrm — then reads the suspected source files, diagnoses the root cause, and drafts a fix. |
| 4 | Autopilot | Commits to a fresh branch (autopilot/bug-1284-a91f3c) and opens a Pull Request describing the diagnosis and what it changed. The run is recorded against the bug — including failures. |
| 5 | You | Review the PR. Accept, amend, or reject. A rejected run is recorded as rejected — the reasoning is not thrown away. |
| 6 | You | Run the tests. A test run in Oprex records what passed against which build. The bug does not close because a machine felt confident. |
| 7 | You | Decide the version. Add the fix to a release plan, pick the version, ship it. The release record links the bug, the fix, and the version. |
| 8 | Oprex | The published release appears in the changelog and — for products wired to it — as an in-app popup for users who have not seen it. How that works → |
Where the human stays in the loop, on purpose
No auto-merge
Default autonomy is propose. Higher autonomy exists as configuration, but it is off, and we would rather you turn it on deliberately than discover it.
Tests are a human gate
A passing PR is not a shipped fix. The test run is a separate, recorded act — that record is what an auditor reads later.
You choose the version
Which release a fix belongs to is a product decision. Autopilot has no opinion about your versioning.
Failure is recorded, never silent
Every attempt becomes a run record attached to the bug: queued, running, proposed, rejected, or failed — with the stored error when it failed. Autopilot never throws into the request path that created the bug, so a broken agent can never stop a bug from being filed.
That matters more than it sounds. An auto-repair system that quietly does nothing is worse than none at all, because you stop checking.
What you need to switch it on
- A connected repository. GitLab or GitHub, linked to the Oprex project the bugs belong to.
- AI enabled for your workspace. Settings → Integration. You nominate the provider and the key, so inference runs against a provider you chose.
- A filter you are comfortable with. Severity and project filters decide what triggers automatically. Start with
criticalon one project.
You can also trigger a run by hand from any bug, or from a coding agent over MCP with oprex_trigger_autopilot.
Honest limits
- It is best at defects with a clear reproduction and a small blast radius — not at architectural problems.
- It reads the files it suspects. A bug whose cause is three services away will produce a wrong guess, and the PR will show you that.
- Auto-merge and auto-deploy are configuration-gated and not part of the current foundation. When they land, they will be off by default too.
Try it on one project
Connect a repository, enable AI, set the filter to critical bugs, and watch the first Pull Request arrive.
Get started free Ask us about your setup