Introducing Fix PRs in Early Release Guard

Finding a bug should lead somewhere more useful than another item waiting for engineering.

Today, we are introducing Fix PRs in Early Release Guard. Early takes an eligible bug finding, implements a fix, adds tests for the affected behavior, and opens a draft pull request after authorized initiation. Engineers review the changes, amend them where needed, and decide what to merge.

This is the Fix part of Find. Fix. Know. The goal is Automate repair. Scale engineering. Release with confidence. Early carries more of the repair work forward, so engineering can focus on evaluating the change rather than preparing every fix from the beginning.

A Finding Is the Start of the Work

A useful bug report explains the failure. It does not implement the correction.

Someone still has to investigate the relevant code, decide how the behavior should change, prepare the patch, add tests, and bring the work into review. Engineers may already use coding agents throughout that process. The work of assembling context and driving the repair still needs an owner.

Fix PRs connect those pieces. The finding supplies the issue and supporting context. Early uses that context to implement the repair and deliver the changes in a pull request that engineering can inspect.

For a QA leader, this creates a path beyond reporting the problem. For an engineering leader, it brings the fix and tests into the review workflow without requiring an engineer to start each repair from an empty branch. The intended benefit is more engineering capacity for building, while preserving responsibility for what changes and what ships.

From Finding to Fix PR

The workflow has four parts:

• Find the issue. Review the finding and the behavior that needs attention. Eligible findings can include general bugs and regressions.
• Authorize the repair. Confirm the finding and the destination for its Fix PR through the authorized workflow.
• Let Early implement the fix. Early prepares the code change, adds tests for the affected behavior, and opens a draft PR linked to the finding.
• Review and merge. Engineering reviews the implementation and available check results, makes any necessary changes, and decides whether to merge.

Actual product capture from the Pydantic AI example. The finding remains the starting point for the repair.

The confirmation makes the destination explicit before the repair begins. In the example shown here, that includes the repository and target branch. Nothing is merged automatically.

Actual product screenshot excerpts, arranged for display. Authorized initiation comes before automated repair. Engineering controls the merge.

The current workflow handles one eligible finding at a time through authorized access. It does not mean every finding automatically creates a PR or that every team member has the same repair permissions.

Code and Tests, Together for Review

The output is a code change, not only advice about what someone could fix.

The Fix PR brings the implementation and tests together with context about the finding. That gives an engineer a concrete change to evaluate: does it address the issue, preserve the intended behavior, and fit the surrounding code?

Keeping that connection matters during handoff. The reviewer needs to understand why the patch exists, not just what lines changed. The finding explains the failure, the code shows the correction, and the tests express the behavior the repair is intended to preserve.

Adding tests matters because a repair should also help the team catch the same failure if it returns. Their value depends on what they assert and whether the team runs and maintains them. Test creation and passing test results are different things.

Engineers can inspect the diff, extend the tests, request changes, or reject the repair.

The Pydantic example produced draft PR #3 on Early's copy of the project. Draft status and the captured check state are preserved, not presented as a completed review.

See It in a Real Finding

Our recent Pydantic AI example follows a saved-state bug through this workflow. A failed read could leave a fresh session able to overwrite previously valid saved state. Early identified the issue, then created a draft Fix PR containing the implementation change and a regression test.

The example makes the handoff concrete: a finding becomes code and tests that engineers can review together. It also shows why creating a PR is not the same as finishing verification. The recorded compilation check passed, while the behavioral test still needed to be run and the repair remained subject to review.

See the finding, repair initiation, and generated Fix PR.

The existing AI Bug Fixing: From Finding to Fix Pull Request article explains that case in detail. This announcement introduces the product workflow behind it, rather than retelling the investigation.

More Capacity to Build

Fix PRs give QA a way to carry findings toward repair through the authorized workflow, without requiring QA to write the patch or tests. Engineering receives an implementation to assess, not a handoff that ends with a problem description.

The measure of value is not simply how many PRs Early opens. It is whether those fixes are useful, what review or rework they require, and how much engineering effort the full repair takes. A generated fix still deserves the same scrutiny as any other code change.

Use the dashboard and release reports to understand what needs attention. Follow the finding into its Fix PR. Use the verification guide to distinguish the code change from the evidence that it works.

Early fixes bugs. You control the merge. Explore Early Release Guard to see the finding-to-fix workflow.