Paper of the Week — Function-Level Execution Feedback for Code Preference Optimization

Function-Level Execution Feedback for Code Preference Optimization

Idris Nechnech, Sehwan Kim, Jimin Seo, Yeongoon Kim, Minhae Oh, Sangwoo Hong, Jungwoo Lee. Published 2026-08-23. arXiv:2608.23632

One sentence summary

Using function-level execution results as process supervision signals for preference optimization outperforms both line-level and reasoning-trace supervision on code generation benchmarks.

Why this paper

Process supervision for coding agents is still an open problem — most teams either use outcome-only rewards or hand-wave about “intermediate steps.” With coding agents now a production staple and models like Claude Fable 5 achieving top-tier SWE-bench performance, the bottleneck is shifting to post-training data quality, making this directly actionable.

What they did

Math reasoning borrowed process supervision naturally because reasoning steps are explicit chain-of-thought tokens. Code doesn’t have an obvious equivalent — a line? a function? a trace? This paper runs a controlled comparison: they define the “step” as a function boundary, run execution feedback at that granularity, and use those signals to construct preference pairs for DPO-style training. The key insight is that functions are the natural unit of verifiability in code — you can actually run them in isolation and get a binary pass/fail signal.

Key findings

Function-level supervision outperforms line-level and reasoning-trace baselines by 8+ points on HumanEval-style benchmarks
The approach doesn’t require a large external judge — execution itself is the verifier, keeping pipeline costs low
Preference pairs constructed from function-level pass/fail are more discriminative than outcome-only pairs, meaning the model learns to distinguish partially-correct from fully-correct solutions
The method generalizes across model families tested, suggesting it’s architecture-agnostic rather than tuned to one backbone
Smaller models benefit disproportionately — the signal is richest where models most often produce partially-working code

Why it matters for practitioners

If you’re fine-tuning or post-training a coding model on your codebase, this gives you a principled way to generate supervision signal without human labelers or an expensive judge model. The function boundary heuristic is easy to implement with any standard AST parser, and execution feedback is already infrastructure you likely have if you’re running eval suites.

What you can use today

Parse generated code into function-level units using Python’s ast module or tree-sitter, run each function against minimal test stubs, and use pass/fail as preference signal for DPO or RLVR training loops
When building preference datasets for code models, prefer function-granularity pairs over full-file or line-level pairs — the execution signal is cleaner and cheaper to obtain than an LLM judge
If you’re running a coding agent with a smaller open-weight model (Devstral 2, Poolside Laguna S 2.1), this post-training recipe is worth piloting before scaling to a larger model — the paper shows smaller models capture more relative gain