InCoder and the Rise of Fill-in-the-Middle Code Editing
Meta AI's InCoder trained a generative model to fill missing regions using both left and right context, helping establish infilling as a core capability for code editing rather than simple end-of-file completion.
Most early generative code models assumed programmers wanted continuation
Autoregressive language models naturally predict what comes next. That works well for completing the end of a function, but real programming is rarely a single left-to-right pass. Developers insert methods, replace conditions, add imports and modify code between existing lines. InCoder, introduced by Daniel Fried and colleagues in 2022, targeted this mismatch directly.[1]
The model was designed to perform both ordinary left-to-right synthesis and code infilling, where a missing region is generated using context that appears before and after the gap.
Editing requires knowledge of the future context
If a missing function body must match a return type, later variables or surrounding class methods, text appearing after the insertion point may be as important as text before it. Standard causal completion cannot naturally see that right-hand context.
Causal masking taught the model to generate removed spans at the end
InCoder’s training procedure removed spans from code files, inserted special mask markers in their original locations and moved the missing content to a generation region. The decoder-only model therefore learned to predict the hidden span while conditioning on the visible code on both sides.[1]
This was a clever use of an autoregressive architecture. The model still generated tokens causally, but the training serialization let it read bidirectional file context before producing the infill.
The objective turned one decoder into both completer and editor
A separate encoder was not required. The same model could extend code from the end or fill one or more interior regions depending on how the prompt was constructed.
InCoder framed code generation around iterative development behavior
The project site emphasized tasks such as type prediction, docstring generation, variable renaming and code insertion without task-specific fine-tuning.[2] These are editing operations rather than greenfield program synthesis.
That framing was historically important. AI coding systems were moving from ‘write a function from a prompt’ toward ‘modify an existing artifact while preserving its surrounding constraints.’
Infilling fits the unit of work inside an editor
An IDE user often selects a region or positions a cursor in existing code. Fill-in-the-middle generation maps directly to that interaction, making the model easier to integrate into ordinary editing workflows.
The release included 1.3B and 6.7B parameter checkpoints
The public InCoder repository and Hugging Face model card exposed both smaller and larger checkpoints for experimentation.[3][4] The model was trained primarily on Python and JavaScript while including code from dozens of languages and Stack Overflow text.
The team also emphasized permissively licensed source repositories in the training mixture, an early example of code-model developers treating license selection and data provenance as explicit design considerations.
Data curation became part of the model’s public identity
Code is governed by software licenses, not merely copyright in an abstract corpus. InCoder’s documentation made the licensing of training repositories visible at a time when the field was beginning to debate what code models should learn from.
Bidirectional context improved tasks where local syntax was not enough
The paper reported that conditioning on both sides of the gap helped on infilling evaluations while retaining competitive standard synthesis ability.[1] The advantage is intuitive: surrounding identifiers, later calls and neighboring control flow constrain what can plausibly fit in the missing region.
This made infilling an appealing training objective for later code models, many of which adopted special prefix, suffix and middle tokens so a developer could ask for code that belongs inside an existing file.
The model still operated mainly within file-level context
InCoder did not solve repository navigation, dependency management or issue resolution. The context window contained code supplied to the model, and it did not autonomously decide which files elsewhere in a codebase were relevant.
That limitation separates code editing from later software-engineering agents. Infilling improves how a model modifies text, but repository-level work also requires search, tool use, execution and planning.
HumanEval and related benchmarks kept functional correctness in view
Generative code research around InCoder inherited benchmark traditions such as HumanEval, where generated functions are executed against tests rather than scored only by textual similarity.[5]
Infilling made the evaluation problem harder because the generated region must satisfy both local syntactic constraints and the behavioral expectations of the larger program. The benchmark culture helped reinforce the idea that source code should be judged by what it does.
Why InCoder belongs in the history of AI coding
InCoder helped make fill-in-the-middle generation a standard code-model capability. Its key insight was simple but consequential: programmers edit inside programs, so a useful model should condition on code that follows the insertion point as well as code that precedes it.[1][2]
Later open code models treated infilling as ordinary infrastructure. InCoder marks the period when generative coding moved from continuation toward context-aware modification, a prerequisite for increasingly capable AI editing tools.
Infilling also changed how model context could be selected by tooling. An editor can provide the prefix before the cursor and a suffix after it, allowing the model to condition on nearby declarations, closing braces or later uses without transmitting an entire repository. That made fill-in-the-middle a useful compromise between tiny left-to-right completion and expensive full-repository context. Many later coding assistants adopted the same interaction because it matches how developers actually insert code into partially written files.
This work also shows why AI-assisted coding cannot be understood only as a sequence-modeling problem. Programming provides syntax, execution, tests, repositories and tool feedback that can be incorporated into the system. The historical progression of code models is therefore also a progression in how much of the surrounding software-engineering environment the model is designed to use.
Works Cited
- 01
- 02InCoder — Project Site sites.google.com
- 03InCoder — Official Repository github.com
- 04Hugging Face — facebook/incoder-6B Model Card huggingface.co
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead