Training an LLM to use a Debugger

I post-trained Qwen3-Coder-30B to fix bugs using an interactive debugger (breakpoints, stack inspection, live expression evaluation) instead of the usual loop of file edits, test runs, and print statements. The trained model solves 89% of heldout tasks (up from 70% base) and reaches the fix in 59% fewer turns.

This series covers the full project in three posts.

Part 1: Evals, Harness, Data

Starts with a negative result: giving four models (Claude Sonnet 4.6, GPT-5.4, Kimi K2.6, Qwen3-Coder-30B) access to debugger tools does not improve their solve rate or turn efficiency. The models either ignore the tools or use them without conditioning their edits on the runtime evidence.

Also covers the debugger harness (sandboxed pdb sessions, observation filtering, independent verification) and the data pipeline: 182 validated multi-file bug tasks with paired implementations, plus 285 filtered SFT examples.

Part 2: SFT (WIP)

Supervised fine-tuning on the synthetic trajectories from Part 1. Adapter choice (DoRA over LoRA), the training recipe, and the SFT checkpoint that becomes the initialization for RL.

Part 3: RL, Evals (WIP)

Reinforcement learning with GRPO to optimize when and how the model uses the debugger. Reward shaping (correctness + process quality), async rollout infrastructure, NCCL weight transfers, and the final heldout evaluation.