Autofix

An autofix is a pull request Polylane opens to resolve something it found. The agent investigates first, then writes the code change on a branch and opens the pull request on GitHub. You review and merge; Polylane never merges on its own.

Where autofixes come from

Every autofix has one of three origins:

• Automation: an automation action with autofix enabled finishes its review and drafts the fix. See Automations.
• Chat: you ask an agent in a thread directly. For example: "open a pull request that fixes this".
• Investigation: an investigation lands on a clear root cause, so you kick off the fix from the issue itself.

Lifecycle

1. Investigate: the agent gathers context from the topology, telemetry, and the affected repository.
2. Branch: it creates a branch against the repository's base branch.
3. Fix: the executor writes the change and pushes commits.
4. Pull request: it opens the pull request with a title, a description of what was wrong and what changed, and a link back to the thread or issue that produced it.
5. Your gate: your normal code review and continuous integration checks decide the merge. Rejecting or closing the pull request is a valid outcome; Polylane records it.

An autofix moves through these statuses: started, branch_pushed, pr_opened, then merged or closed. Two other terminal states exist: failed when the executor could not produce a fix, and no_fix_needed when the agent concludes the code is already correct. A run can also be skipped before any work starts: already_in_flight when an open pull request already covers the fix, and quota_exhausted when the workspace has used its merged-autofix quota for the billing period. A skipped run can be started again from its overview page with Run anyway, which bypasses those checks.

Executors

The executor is the coding agent that writes the diff. Polylane ships its own executor that works out of the box. You can also bring your own coding agent and route autofixes through it instead:

Supported executors: native (built in, the default), Devin, Cursor, and Factory.

Configuring executors

Open Autofixes in the console and choose Connect a coding agent to link Devin, Cursor, or Factory to your workspace. Each connection uses your own API key for that provider.

To make a connected agent the default for every autofix, open its integration page in Settings and turn on the Use Devin for all autofixes switch (or the equivalent for Cursor or Factory). Turning the switch off routes autofixes back through the Polylane executor.

Tracking autofixes

The Autofixes page in the console lists every autofix with its repository, branch, status, and executor. Filter by status to see open pull requests, or by executor to compare how each coding agent performs. Each autofix has a detail view with an overview, its properties, and a timeline of every step from investigation to merge.

Try it from your coding agent:

Use Polylane to list recent autofixes and tell me which pull requests are still open and waiting on review.

Related

• Automations to trigger autofixes automatically.
• Actions for enabling autofix on review-style actions.
• Investigations for fixes that start from an investigation.
• GitHub for the code host connection autofixes write through.