💻 computer science

SWE-Manager: Selecting and Synthesizing Golden Proposals Before Coding

This paper introduces SWE-Manager, an 8B reinforcement learning model that mimics technical managers by selecting the best candidate proposal and synthesizing a "golden" solution for software issues without executing code, achieving state-of-the-art performance on the SWE-Lancer Manager benchmark.

Original authors: Boyin Tan, Haoning Deng, Junyuan Zhang, Junjielong Xu, Pinjia He, Youcheng Sun

Published 2026-07-07

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Boyin Tan, Haoning Deng, Junyuan Zhang, Junjielong Xu, Pinjia He, Youcheng Sun

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a ship (a software project) and a storm has hit (a bug or a new feature request). Before you can steer the ship, you need to decide which path to take.

In the real world, your crew doesn't just guess. They might have three different sailors shouting out three different routes:

Sailor A says, "Take the shortcut through the reef! It's fast, but risky."
Sailor B says, "Go around the island. It's safe, but it takes three days."
Sailor C says, "Let's fix the engine first, then go. It's the most thorough, but it's expensive."

Usually, a human manager has to listen to all three, weigh the risks, check the weather (the specific context of the problem), and pick the best plan. This paper, SWE-Manager, asks: Can an AI learn to be that manager?

Here is the story of how they built it, explained simply:

1. The Problem: AI is Good at Writing, Bad at Choosing

Currently, AI models (like the ones that write code) are great at generating one solution. But in real software teams, people often write multiple solutions and then argue about which one is best.

The Gap: AI hasn't really been taught how to sit in the "manager's chair," listen to all the options, compare them, and say, "Okay, we are going with Sailor B, but let's tweak it to be faster."
The Question: Is this "picking the winner" skill just a random human preference, or is there a logical pattern that an AI can learn?

2. The Detective Work: What Do Real Managers Do?

The researchers acted like detectives. They looked at thousands of real discussions on GitHub (a place where programmers share code) where people argued over how to fix bugs. They found three big secrets about how human managers choose:

Secret #1: It's not random. Managers don't just pick their favorite. They always use a few "high-level rules," like: "Is this safe?" "Will it break other things?" "Is it easy to fix later?"
Secret #2: It's a comparison, not a test. You can't judge a proposal in isolation. You have to compare them against each other in the specific context of the problem. (e.g., "Sailor A is fast, but since we are in a storm, safety is more important than speed.")
Secret #3: The best plan is a mix. Often, the final plan isn't just one sailor's idea. It's a "Golden Proposal" that takes the best parts of Sailor A, the safety of Sailor B, and the thoroughness of Sailor C, and combines them into one perfect plan.

3. The Solution: SWE-Manager (The AI Manager)

Based on these secrets, the team built SWE-Manager. Think of it as a new kind of AI that doesn't just write code; it manages the conversation.

Instead of just saying "Here is the code," SWE-Manager does three things:

Reads the Issue: It understands the problem.
Reviews the Candidates: It looks at all the different proposals (like the sailors' routes).
The "Golden" Synthesis: It picks the best direction, explains why it picked it, and then writes a new, "Golden Proposal" that combines the best ideas from all the candidates into one clear instruction.

They trained a specific version called SWE-Manager-8B (an 8-billion-parameter model) using a special two-step process:

Step 1 (School): They taught it the format of how to compare and explain things (Supervised Fine-Tuning).
Step 2 (Practice): They let it practice making choices and rewarded it when it picked the right one, teaching it to "think" like a manager (Reinforcement Learning).

4. The Results: Does the AI Manager Work?

They put the AI to the test in two ways:

Test A: The "Who's the Boss?" Test (Selection)
They gave the AI a problem and three different solutions, asking it to pick the one a human manager would have picked.

The Result: SWE-Manager-8B got it right 53% of the time.
The Comparison: A very powerful, famous AI (GPT-5) only got it right 44% of the time. Even though SWE-Manager is a smaller, cheaper model, it was better at choosing the right path.

Test B: The "Does it Help Build?" Test (Implementation)
They set up a workflow (called P2A) where:

One AI writes the proposals.
SWE-Manager picks the best one and writes the "Golden Proposal."
A third AI tries to build the fix based on that Golden Proposal.

The Result: When SWE-Manager was the manager, the team successfully fixed 55.6% of the problems.
The Comparison: This was better than having no manager at all (which fixed 48.5%) and matched the performance of using the giant GPT-5 as the manager.

The Big Takeaway

The paper proves that choosing the right plan is a skill that AI can learn.

It's not just about being smart enough to write code; it's about being smart enough to compare options, understand the risks, and combine the best ideas into a single, clear instruction. By teaching an AI to act like a "Technical Manager," we can make software development more reliable and efficient, even with smaller, cheaper AI models.

In short: The paper shows that if you teach an AI to be a good judge and a good editor, it becomes much better at helping humans build software.

Technical Summary: SWE-Manager

Problem Statement

In real-world software engineering workflows, a critical step precedes code generation: proposal selection. Teams often draft multiple candidate proposals for a single issue (e.g., bug fixes, feature implementations), and a maintainer must select the most suitable one to guide implementation. This decision is rarely based solely on technical feasibility; it requires balancing correctness, regression risk, fix depth, maintainability, and organizational constraints.

While Large Language Models (LLMs) have advanced code generation and bug repair, the proposal-selection phase remains underexplored. It is unclear whether maintainer selection decisions rely on reusable, learnable reasoning patterns or are merely instance-specific preferences. Furthermore, existing benchmarks like SWE-Lancer formalize the "Manager" task but do not explore the underlying rationale or the potential for synthesizing a refined "golden proposal" from competing candidates.

Methodology

1. Manual Study of GitHub Discussions

The authors first conducted a manual study of 2,852 public GitHub issues with bounty-backed outcomes to characterize real-world proposal selection. They analyzed 339 sampled issues where multiple complete proposals existed. The study revealed three key properties:

Recurring High-Level Rationales: Maintainer choices are guided by consistent engineering concerns, primarily Risk and Safety (42.8%), Fix Depth (29.2%), and Maintainability (16.2%).
Context-Conditioned Comparison: Selection is not an isolated evaluation of a single proposal but a comparative judgment of candidates against specific issue constraints (e.g., preferring a minimal fix for high regression risk vs. a deep fix for systemic fragility).
Synthesis via Discussion: The final implementation direction is often refined through discussion, where assumptions are clarified, scope is narrowed, and useful observations from competing proposals are integrated.

2. SWE-Manager Framework

Based on these findings, the authors propose SWE-Manager, a joint selection-and-synthesis approach. The model is tasked with:

Joint Comparison: Analyzing the issue context and all candidate proposals simultaneously.
Selection: Identifying the best proposal.
Explanation: Justifying the choice based on the issue constraints.
Synthesis: Generating a "golden proposal" that consolidates the strengths of the selected direction and useful cross-proposal observations into a refined implementation plan.

3. Model Training (SWE-Manager-8B)

The authors instantiated this approach as SWE-Manager-8B, an 8B parameter model derived from Qwen3-8B.

Data Preparation: A corpus of 2,852 issues was constructed. GPT-5 was used to reconstruct structured training targets (comparative reasoning traces and golden proposals) from fragmented GitHub threads, while the ground-truth selection labels remained anchored to the actual bounty recipients.
Training Strategy: A two-stage process was employed:
1. Supervised Fine-Tuning (SFT): To teach the model the structured output format (reasoning trace, selection ID, justification, golden proposal).
2. Reinforcement Learning (RL): Using DAPO (Decoupled Clip and Dynamic sAmpling Policy Optimization) with a weighted reward function ( $r = 0.4r_{sel} + 0.2r_{think} + 0.2r_{justi} + 0.2r_{gold}$ ) to optimize decision-making policies rather than just imitating rationales.

4. Evaluation Framework (P2A)

To evaluate the downstream utility of the synthesized golden proposal, the authors introduced P2A (Proposal-to-Action), a workflow mimicking real development:

Proposal Agent: Generates multiple candidate proposals.
Technical Manager (SWE-Manager): Selects and synthesizes the golden proposal.
Implementation Agent: Uses the golden proposal to generate a code patch.
This workflow was tested on the SWE-Lancer IC benchmark to measure issue-resolution rates.

Key Results

Proposal Selection Performance (SWE-Lancer Manager Benchmark)

SWE-Manager-8B achieved 53.21% selection accuracy and a 57.75% earned rate ($152,750).
This outperformed GPT-5 (44.15% accuracy, $99,875 earned) and the base Qwen3-8B (34.72% accuracy).
SWE-Manager-8B surpassed GPT-5 even when GPT-5 was given code access (Agent setting) for most proposal counts, though GPT-5 with code access performed slightly better on the highest-value ($2K+) and most complex (6+ proposals) instances.

Downstream Implementation Performance (SWE-Lancer IC Benchmark)

Using the P2A workflow, SWE-Manager-8B achieved a 55.6% issue-resolution rate.
This matched the performance of P2A using GPT-5 as the manager and improved upon the baseline mini-SWE-agent (direct implementation without proposal selection) by 7.1%.
Ablation on Synthesis: Replacing the synthesized "golden proposal" with the raw "selected proposal" significantly degraded performance for SWE-Manager-8B (dropping from 55.6% to 46.5% pass rate), demonstrating that the synthesis capability provides tangible value beyond simple selection.

Training Ablations

Synthesis Objective: Training the model to only predict the proposal ID (without synthesizing a golden proposal) resulted in lower accuracy, suggesting that the synthesis task forces the model to engage in deeper comparative reasoning.
Training Staging: A two-stage approach (SFT followed by RL) yielded better stability and performance than applying RL directly to the base model.

Significance and Claims

The paper claims that proposal selection is a learnable capability for LLMs, driven by recurring high-level engineering rationales rather than arbitrary preferences.

Learnability: A small 8B model, when trained on large-scale selection data with a synthesis objective, can outperform much larger models (GPT-5) in selecting the best technical proposal.
Practical Utility: The ability to synthesize a "golden proposal" is not merely an auxiliary output; it provides actionable guidance that significantly improves downstream code generation and issue resolution.
Workflow Integration: The P2A framework demonstrates that integrating a "Technical Manager" role before coding improves end-to-end software engineering outcomes compared to direct implementation agents.

The authors conclude that while current models show robustness limits with very large proposal pools (due to training data distribution shifts), the core capability of context-conditioned comparison and synthesis is a viable and effective strategy for LLM-based software engineering systems.