Mistral Codestral: how to review code when a fill-in-the-middle model completes from both sides of your cursor

2026-04-29 · 5 min read · ZenCode

Codestral is Mistral AI’s code-specialized model, built around fill-in-the-middle (FIM) architecture. Unlike a chat-based tool where you describe what you want and the model responds, Codestral works by reading both sides of your cursor simultaneously — the code above (prefix) and the code below (suffix) — and generating whatever belongs in between. Most developers encounter it via Continue.dev, Cline with a custom model endpoint, or a local Ollama deployment.

FIM completion handles a genuinely different task than prompt-driven generation. The input already contains structural constraints from both sides, which makes Codestral highly effective at completing function bodies that match an established signature, filling gaps in partially-written logic, and continuing repetitive patterns. It also creates a set of review traps that do not appear in chat-based tools, because the mechanism by which suggestions are generated is invisible to the person evaluating them.

The three Codestral review traps

1. FIM-pattern reflection

Codestral’s FIM model learns the statistical regularities in code by processing billions of examples in the prefix–suffix–infill format. When it generates a completion for your cursor position, it is drawing on patterns from your prefix, your suffix, and all the training data that resembles what it sees. In a file with consistent patterns — a certain error-handling approach, a certain way of constructing objects, a certain naming convention — Codestral produces suggestions that match those patterns faithfully.

The trap is that style-match is not correctness. If your codebase has been handling a class of inputs incorrectly for six months, Codestral will generate completions that handle that class incorrectly in exactly the same way. If your convention is to log errors without rethrowing them, Codestral will suggest the same silent swallow in a new function. If there is a subtle off-by-one error in similar loops throughout the file, Codestral will complete the new loop with the same off-by-one. The suggestion looks right because it looks like everything else. The review instinct fires not because the code was evaluated, but because it matched the surrounding context.

The fix is to name one correctness criterion before accepting a completion, independent of whether it matches the surrounding code. Not “does this look consistent with the rest of the file?” but “does this handle the boundary case at the edge of the input range correctly?” Style-match should be the last check, not the first.

2. Invisible context span

When you use GitHub Copilot Chat or Claude Code, you can see the conversation — the prompt you sent, the files you attached, the context that was included. When Codestral generates a FIM completion, none of that is visible. You see the suggestion and the cursor position. You do not see which lines of prefix the model weighted, how far back in the file the suffix sampling reached, or whether the most contextually relevant function — the one that defines the interface you are implementing against — even fit inside the context window.

This matters because Codestral’s completions vary in quality depending on whether the relevant context was available. A completion that fills in a function body which calls another function defined 40 lines above is almost certainly using good context. A completion in a 1,200-line file that generates a method at the bottom is drawing on whatever fit in the context window from the top of the file, which may not include the class definition, the type constraints, or the error contract that govern the method being completed.

You cannot inspect the context span after the fact. The practical response is to inspect it before accepting: before evaluating any Codestral completion, identify the one nearby artifact that should most constrain what the model generates (the interface being implemented, the type being constructed, the invariant being maintained), then verify that the completion is consistent with that artifact by reading it directly rather than assuming the model had access to it.

3. Self-hosted correctness halo

A significant portion of Codestral usage is via local deployment: Ollama running on a developer’s machine, a private API endpoint inside a corporate network, or a local model server proxied through Refact.ai’s self-hosted stack. The privacy advantage of local deployment is real and well-understood: code never leaves the machine, the model cannot be queried by a third party, and there is no vendor data retention to reason about.

The correctness halo is what happens when that privacy property transfers to a correctness property it does not support. Self-hosted means the model is yours. Yours means you control it. Controlled means it can be trusted. This chain of associations happens quickly and mostly below awareness. Developers who would carefully review a suggestion from a cloud-hosted tool accept local Codestral suggestions with less friction, not because the model is more accurate, but because it feels more like their own tool than a third-party service.

A self-hosted Codestral model has no information about your application’s business rules, the security properties your team has agreed to enforce, or the behaviors your users actually depend on. It knows code patterns. The same evaluation that applies to any AI suggestion applies here: does this suggestion correctly implement the intended behavior, including the cases where incorrect behavior would be silent or delayed? Provenance is not a substitute for that check.

This trap also appears in Tabnine’s on-device model, which markets the same privacy-first positioning. The review discipline is the same: the data-handling guarantee and the correctness guarantee are separate properties that neither model conflates — only the reviewer does.

What Codestral does well

FIM-based completion is genuinely better than chat-based generation for a specific category of tasks: completing code where the structural constraints are already present in the file and the task is to fill a well-defined gap. Completing a function body that already has a signature, a return type, and adjacent callers is a task where Codestral’s architecture gives it an advantage over a model that only reads up to the cursor. The suffix provides hard constraints the completion must satisfy, which reduces the space of plausible but wrong completions.

The traps above emerge when Codestral is applied to tasks at the edge of its strength: complex logic where the constraints are not visible in the immediate file context, security-sensitive operations where pattern-match is a particularly dangerous evaluation shortcut, and long files where the relevant context for the completion lives outside the model’s effective window. Knowing which task is which is the primary skill in using Codestral without accumulating review debt.

If you want the full agentic version of Mistral's coding model, see Devstral — Mistral's open-weights coding agent that reads files, runs terminal commands, and writes diffs rather than completing inline suggestions.

Codestral sits in the same category as Codeium and Supermaven as a fast, lightweight inline completion model. The review traps for all three share a common ancestor: suggestions that arrive quickly and look consistent with surrounding code create strong acceptance pressure before any evaluation occurs. What is specific to Codestral is the FIM architecture, which means the suffix is part of the input — making the structural coherence of completions unusually good while making the context span unusually opaque. That combination is what produces the three traps above.