# Constrained code generation for software engineering

Canonical HTML: https://aogavrilov.com/research-notes/constrained-code-generation-software-engineering/
Document language: en
Source publication: https://aogavrilov.com/publications/inspectable-control/
Source full-text HTML: https://aogavrilov.com/publications/inspectable-control/full-text/
DOI: https://doi.org/10.1145/3803437.3807386

A practical distinction between grammar constraints, type constraints, preservation boundaries, and behavior-level acceptance checks for generated code.

## Direct answer

### What does constrained code generation guarantee in a software-engineering workflow?

Only the property explicitly enforced by the constraint. Grammar-constrained decoding can guarantee membership in a grammar; type-aware methods can target type validity; neither alone proves task correctness, semantic equivalence, behavior preservation, or edit locality.

## Why the distinction matters

The word constrained is incomplete until the constrained property is named. A decoder may enforce syntax, a type checker may restrict valid continuations, an editor may protect selected regions, and a repair workflow may accept only candidates that pass tests. These mechanisms solve different problems.

A useful evaluation must therefore align the control mechanism with the claimed guarantee. Passing a parser is relevant evidence for syntax; it is not evidence that the program meets the request or preserves behavior outside the edit.

## Practical procedure

1. **Name the required property.** Decide whether the requirement concerns grammar, types, APIs, source locality, structural invariants, tests, or another observable contract.
2. **Choose an enforcement point.** Apply constraints during decoding when possible, or use proposal-plus-validation when the property can only be checked after generation.
3. **Keep separate acceptance checks.** Test task success and protected properties even when the decoder already guarantees syntax or types.
4. **Report rejection and failure behavior.** A constrained method should disclose how often candidates are rejected, whether valid solutions remain reachable, and what is still unchecked.

## Evidence to require

- The constrained property is stated in observable terms.
- The enforcement mechanism and post-generation checks are distinguished.
- Syntax or type validity is not presented as functional correctness.
- Locality is measured directly when unchanged code is part of the claim.
- Constraint failures, rejection rates, and task-success rates are reported.

## What the linked study reports

- The linked hierarchical-latent study locks selected learned codes and measures decoded parse rate, edit freedom, and diversity.
- This is an inspectable partial-control experiment, not a formal grammar, type, semantic, or behavior guarantee.
- Its value for constrained workflows is the explicit control surface and measurement discipline, not a claim that latent locking replaces formal validation.

## Scope boundary

- Different constraints can conflict; stronger restriction can remove valid solutions or reduce generation diversity.
- Post-generation tests provide evidence only for the behaviors they cover.
- The linked paper does not evaluate formal constrained decoding or repository-scale software repair.

Complete research guide: https://aogavrilov.com/projects/discrete-latent-generation/#comparison

## Primary and nearby sources

- [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/publications/inspectable-control/): Primary site paper on inspectable partial control in hierarchical latents.
- [Constrained Decoding of Diffusion LLMs with Context-Free Grammars](https://arxiv.org/abs/2508.10111): Formal grammar constraints during diffusion decoding.
- [Type-Constrained Code Generation with Language Models](https://doi.org/10.1145/3729274): Type-aware constraints for language-model code generation.

This maintained note summarizes existing evidence and adds no experimental result beyond the cited sources.