PaperlayerView exact revision on arXiv

Source-linked AI summary

BatCoder: Self-Supervised Bidirectional Code-Documentation Learning via Back-Translation

Jingwen Xu, Yiyang Lu, Zisu Huang, Changze Lv, Xiaohua Wang, Shizheng Li, Zhibo Xu, Zhengkang Guo, Zhengyuan Wang, Muzhao Tian, Xuanjing Huang, Xiaoqing Zheng

arXiv:2602.02554v1cs.LGcs.AIcs.SE

TL;DR

Curated code-documentation pairs are scarce and uneven in quality, limiting scalable training. BatCoder learns both directions from unlabeled code through back-translation, consistently improving code generation, especially for low-resource languages.

  • Problem

    High-quality paired code-documentation data remains limited and uneven, constraining scalable training for code-documentation alignment and transformation tasks.

  • Method

    BatCoder jointly learns documentation generation and code reconstruction from unlabeled code, using reconstruction similarity as a reinforcement-learning reward.

  • Results

    BatCoder consistently improves code generation across benchmarks, outperforming comparable baselines and performing particularly well in low-resource languages.

  • Takeaways & Limitations

    Back-translation similarity provides a learning signal for meaningful improvements from unlabeled code alone, particularly when curated documentation pairs are scarce.

  • Takeaways & Limitations

    The robustness of similarity-based rewards and the scaling regimes where BatCoder is most effective remain subjects for future investigation.

Abstract

from arXiv · show

Training LLMs for code-related tasks typically depends on high-quality code-documentation pairs, which are costly to curate and often scarce for niche programming languages. We introduce BatCoder, a self-supervised reinforcement learning framework designed to jointly optimize code generation and documentation production. BatCoder employs a back-translation strategy: a documentation is first generated from code, and then the generated documentation is used to reconstruct the original code. The semantic similarity between the original and reconstructed code serves as an implicit reward, enabling reinforcement learning to improve the model's performance both in generating code from documentation and vice versa. This approach allows models to be trained using only code, substantially increasing the available training examples. Evaluated on HumanEval and MBPP with a 7B model, BatCoder achieved 83.5% and 81.0% pass@1, outperforming strong open-source baselines. Moreover, the framework demonstrates consistent scaling with respect to both training corpus size and model capacity.

1. Introduction

BatCoder addresses scarce and uneven code-documentation supervision with a self-supervised back-translation framework trained directly from unlabeled code. It jointly learns documentation generation and code reconstruction using reconstruction similarity as a unified training signal, while scaling with model capacity and training data size.

  • Motivation: High-quality code-documentation pairs are limited and uneven in quality despite abundant raw source code, constraining alignment and transformation-task training.Existing optimization commonly uses supervised fine-tuning or reinforcement learning while treating generated documentation as fixed supervision rather than explicitly evaluating it against the training objective.
  • Training signal: Reconstruction similarity provides a unified signal for assessing generated documentation and guiding code-generation learning.The motivation is that well-formed documentation should preserve enough information for faithful code reconstruction, while code generation should follow the documentation’s requirements.
  • BatCoder: BatCoder learns code description and code generation jointly from unlabeled code through a self-supervised back-translation process.The model generates a natural-language document from a code snippet and then uses that document to reconstruct the original code.
  • Contributions: BatCoder enables bidirectional generation learning without externally curated paired data, alleviating scarce code-documentation supervision.The framework is also reported to scale favorably with both model capacity and training data size.

2. Related Work

Prior work spans code-focused LLMs, code-task data augmentation, semantic alignment, and execution-feedback reinforcement learning. BatCoder instead uses self-contained bidirectional back-translation, with reconstruction similarity providing rewards without target code, rule-based heuristics, or stronger external models.

  • LLMs for Code: Modern code LLMs support code generation, code summarization, and program repair, with specialized models developed for coding tasks.Examples include CodeT5+ and CodeLlama.
  • Data Augmentation for Code-Related Tasks: High-quality code-text pairs remain scarce despite abundant raw code, motivating augmentation methods that construct task-specific supervision.WizardCoder evolves code-text pairs, while Magicoder synthesizes coding problems from unlabeled code snippets.
  • Related Alignment Methods: UniCoder aligns source code with semantic meaning through structured intermediate representations, whose quality depends primarily on hand-crafted rules or stronger external model judgments.These representations include rule-constrained pseudo-code and documentation as a latent bridge.
  • Related Alignment Methods: SelfCodeAlign uses unlabeled code to generate instruction-response pairs and validates them with self-generated tests and sandbox execution, then applies supervised fine-tuning.Its approach mainly serves as a data augmentation strategy.
  • BatCoder’s Distinction: BatCoder evaluates generated documentation by reconstructing original code through back-translation, using similarity as the learning signal for both directions without external supervision.The approach enables joint optimization without rule-based heuristics or stronger external models.
  • Reinforcement Learning in Code Generation: BatCoder derives reinforcement-learning rewards from reconstruction similarity, eliminating target code and propagating rewards to code-to-documentation while reducing conventional RL memory overhead.This extends execution-feedback approaches such as CodeRL and PPOCoder through an evaluation-train separation mechanism.

3. Methods

BatCoder jointly trains code-to-documentation and documentation-to-code transformations through self-supervised back-translation on unlabeled code. It uses reconstruction similarity, documentation validity, asymmetric sampling, and reinforcement learning to optimize both stages.

  • Two-stage formulation: Given code c, Stage 1 generates documentation d=fθ(c), while Stage 2 reconstructs code c′=gθ(d).Their composition gθ◦fθ defines a reconstruction objective that regularizes both transformations through structural faithfulness.
  • Training objective: BatCoder constructs complete code-to-documentation-to-code trajectories from unlabeled snippets and jointly optimizes both stages with reinforcement learning.Reconstruction similarity supplies learning signals without external supervision.
  • Sampling strategy: Stage 1 samples K documentation candidates per code snippet, whereas Stage 2 generates one reconstructed code sample for each selected documentation.This asymmetric rollout produces K complete trajectories while maintaining a balanced number of reconstructions.
  • Reward design: Stage 2 rewards reconstruction similarity between the original and reconstructed code, using an abstract code-level similarity function instantiated as CSSG in experiments.The reconstruction directly tests whether documentation preserves essential program semantics.
  • Reward design: Stage 1 combines reconstruction similarity with a documentation validity reward that encourages required formatting and stabilizes early training.Invalid documentation is filtered out before reconstruction and does not contribute to Stage 2 optimization.
  • Reinforcement learning optimization: Training uses Reinforce++ with on-policy updates, a fixed-size replay buffer, and buffer-based reward normalization for token-level advantage estimates.Minibatches sampled from the buffer update model parameters for both directions.

4. Experimental Setup

BatCoder is evaluated across model scales using code-only multilingual training data, established code-generation benchmarks, and comparable open-source baselines. Experiments also specify standardized evaluation and reinforcement-learning configurations.

  • Base models: Qwen2.5-3B-Instruct and Qwen2.5-7B-Instruct pretrained checkpoints serve as base models to assess robustness across model scales.Both experiments start from corresponding Hugging Face pretrained checkpoints.
  • Training data: Training uses only CodeXGLUE Code-Text code samples spanning Python, Ruby, and Go, with accompanying text fields discarded.The dataset’s function-level docstrings were considered mismatched with the structured documentation target.
  • Baselines: Comparisons include CodeT5+, CodeLlama, WizardCoder, Magicoder, StarCoder2, DeepSeek-Coder-Instruct, and Qwen2.5-Instruct at comparable parameter scales or performance levels.Baseline results are consistently drawn from the EvalPlus leaderboard.
  • Evaluation benchmarks: Performance is measured on HumanEval, MBPP, HumanEval+, MBPP+, and MultiPL-E, including Ruby and Go translations for cross-language evaluation.HumanEval+ and MBPP+ add 80× and 35× more test cases, respectively, while MultiPL-E extends the benchmarks across languages.
  • Training configuration: Training uses Reinforce++ with K = 8 documentation samples, batch size 64, actor learning rate 1 × 10−6, and dynamic zero-reward minibatch filtering.The 3B and 7B models use a modified verl framework on two NVIDIA A100 GPUs, with KL coefficient β = 0.

5. Results and Discussion

BatCoder improves code-generation performance across benchmarks, model scales, and low-resource languages, with especially large gains in Ruby. Ablations and training dynamics indicate that optimizing both documentation generation and code reconstruction is important to the framework’s effectiveness.

  • Main Results: 83.5% and 81.0% pass@1 are achieved by BatCoder-7B on HumanEval and MBPP, improving over Qwen2.5-Instruct baselines at both benchmarks.HumanEval rises from 81.7 to 83.5, while MBPP rises from 78.6 to 81.0.
  • Main Results: Improvements at both 3B and 7B scales show that BatCoder generalizes across model capacities rather than a single parameter regime.The reported gains extend across different model sizes.
  • Low-Resource Languages: 10.6 pass@1 on Ruby is reached by BatCoder-3B from a Qwen2.5-Instruct baseline of 0.0, demonstrating non-trivial performance in an extremely low-resource setting.BatCoder consistently outperforms corresponding baselines on Ruby and Go, with markedly larger gains on Ruby.
  • Ablation Studies: 1.9 pass@1 is obtained when Stage 1 updates are disabled, compared with 0.0 for the base model, remaining far below complete BatCoder.Without explicit reinforcement guidance for documentation generation, the self-supervised signal becomes weaker for faithful code reconstruction.
  • Training Dynamics: Both stage rewards increase steadily during training, while MultiPL-Ruby Pass@1 improves in a similar progression, indicating alignment between optimization signals and downstream performance.The observed dynamics support the stability and meaningfulness of the bidirectional reinforcement learning reward design.

6. Conclusion and Future Work

BatCoder jointly learns code generation and documentation synthesis through back-translation, optimizing directly from unlabeled code without paired supervision or external teacher models. It improves code generation across benchmarks, particularly in low-resource languages, while motivating future work on reward signals, scaling, and related tasks.

  • Core contribution: BatCoder jointly learns code generation and documentation synthesis through bidirectional back-translation consistency.The framework optimizes directly from unlabeled code without paired supervision or external teacher models.
  • Empirical findings: BatCoder consistently improves code generation across multiple benchmarks, outperforming supervised and synthetic-data-based baselines at comparable model scales.It is particularly effective for low-resource languages such as Ruby and Go, where curated code-documentation pairs are scarce.
  • Future work: Future work should incorporate more diverse reward signals and alternative reinforcement learning algorithms to assess similarity-based reward robustness.This direction is intended to test whether the learning signal remains robust beyond the current setup.
  • Future work: Future studies should examine scaling across larger corpora, increased model capacity, and alternative architectures.The goal is to better understand the regimes in which BatCoder is most effective.
  • Future work: BatCoder may also extend to related tasks such as code completion and code translation.The paper notes that its limitations are discussed in Appendix D.

Software and Data

The appendix contains all prompts, and the authors plan to release the approach’s core code on GitHub upon acceptance.

  • All prompts are provided in the Appendix.
  • The authors will release the approach’s core code on GitHub.
  • The code release is planned upon acceptance.

Impact Statement · A. Prompt Templates

The paper reports no anticipated negative ethical or societal impact and documents one-shot, format-constrained prompts for generating structured documentation across Python, Ruby, and Go. These templates support reliable code reconstruction by specifying language-specific imports, descriptions, examples, and function signatures.

  • Impact Statement: The authors report no expected negative ethical or future societal consequences from the work.
  • A. Prompt Templates: The appendix uses one-shot prompting with a format-aligned example to encourage consistently structured documentation for Stage 2 reconstruction.
  • A. Prompt Templates: The templates require documentation outputs to be wrapped in <doc> and </doc> tags and include language-appropriate code-generation information.
  • A.1. Python Documentation Generation Prompt: Python prompts specify imports, a typed function definition, an indented docstring describing behavior, and illustrative >>> input/output examples.
  • A.2. Ruby Documentation Generation Prompt: Ruby prompts specify require statements, a descriptive problem comment, >>> input/output comments, and a function definition matching the code logic.
  • A.3. Go Documentation Generation Prompt: Go prompts specify the package declaration, relevant imports, a descriptive problem comment, >>> examples, and a function definition matching the code logic.

B. Filtering and Rewriting · B.1. Documentation Structure Constraints · B.2. Filtering and Rewriting Procedure

The appendix filters and rewrites Stage 1 documentation before Stage 2, retaining structurally valid, semantically informative instances for reliable reconstruction-based rewards. It enforces language-agnostic format constraints, extracts tagged content, truncates valid matches, and records termination at the matched boundary.

  • B. Filtering and Rewriting: The procedure retains only structurally valid and semantically informative documentation generated in Stage 1 before Stage 2.This ensures reconstruction-based rewards are computed on reliable inputs under back-translation.
  • B.1. Documentation Structure Constraints: Regular-expression-based matching enforces documentation constraints aligned with the prompt specification and Appendix A’s one-shot example.The alignment maintains consistency between the expected format and filtering criteria.
  • B.1. Documentation Structure Constraints: A valid instance contains one or more description lines, at least one illustrative input-output example, and a corresponding function or procedure definition.These requirements are language-agnostic and capture common documentation patterns across programming languages.
  • B.2. Filtering and Rewriting Procedure: The first filtering step extracts only content enclosed within designated documentation tags, discarding generations without valid tags.Examples of designated tags include <doc> and </doc>.
  • B.2. Filtering and Rewriting Procedure: The second step matches extracted content against the structural constraints and truncates valid matches at the matched span’s end.Trailing or extraneous content beyond the required structure is removed.
  • B.2. Filtering and Rewriting Procedure: The process records whether documentation terminates exactly at the matched boundary as an auxiliary indicator of structural completeness.Only documentation passing the filtering and rewriting procedure is used as input to Stage 2.

C. Case Study: Documentation Quality Comparison

The case study finds that BatCoder produces more informative, functionally grounded documentation than the base model, despite imposing no direct reward on documentation content. Its detailed descriptions better support code reconstruction, providing indirect supervision through code-level similarity rewards.

  • Comparison: The comparison evaluates whether BatCoder improves documentation quality for the same code despite no explicit documentation-content reward.Both outputs satisfy the required documentation format and are considered valid under the filtering and rewriting mechanisms.
  • Quality Analysis: The base model gives a coarse, generic login description, whereas BatCoder explicitly captures navigation, form interaction, and submission.BatCoder’s documentation reflects the function’s procedural structure and control flow more closely.
  • Quality Analysis: BatCoder’s more precise documentation improves subsequent code-reconstruction fidelity and yields higher code-level similarity rewards.This indirect supervision encourages informative, semantically aligned documentation through more accurate back-translation.

D. Limitations

BatCoder’s evaluation has limitations in hyperparameter tuning and reward design. The study used shared hyperparameters across model sizes and relied on limited reward signals, leaving potential for further improvement.

  • Future work: The authors identify hyperparameter optimization and richer reward design as promising avenues for future work.The reported consistent benchmark gains indicate substantial headroom for improvement.
  • Hyperparameter tuning: The same hyperparameters were used for 3B and 7B training without extensive tuning.The setup was simplified, and the authors suggest tailored hyperparameter optimization could improve performance.
  • Reward design: Stage 1 and Stage 2 rewards relied solely on code similarity and documentation formatting.Alternative similarity metrics, weighting schemes, and additional reward sources were not explored.
Loading 2602.02554v1…