Concept

The #1 way local AI models break code: indentation drift

Last updated 2026-07-06 · Outlier v1.11.642

What indentation drift looks like

The model gets the logic right and then misplaces the leading spaces on one or two lines. A real example from a build of an arithmetic-expression evaluator — the tokenizer was correct except for a single over-indented line:

        num_str = s[i:j]
            if has_dot:            # ← 12 spaces where 8 belong
                tokens.append(Token('FLOAT', float(num_str)))

Python rejects the whole file with an IndentationError: unexpected indent. The algorithm the model wrote was fine; four stray spaces made it un-runnable. The same class shows up as a statement dedented one space too far, a try: that lost its indentation, or a function body that drifts a level. One slip anywhere in a file breaks the entire file.

Why it hits local models specifically

A frontier cloud model has enough raw capacity to keep indentation perfectly consistent across a long file. A compact, quantized model running on your laptop generates leading whitespace as ordinary tokens, one at a time, and occasionally emits one space too many or too few — the coding equivalent of a typo. It is not a reasoning failure; it is a precision failure at the token level, and it is the most frequent single reason a first-attempt local build doesn’t compile.

Why you can’t just “re-indent it”

This is the subtle part, and it is where a naive assistant quietly goes wrong. Indentation in Python is not cosmetic — it decides which block a statement belongs to. A misplaced line can frequently be moved to more than one indentation level that all compile but mean different things:

for x in items:
    total += x
    return total     # returns on the first item

for x in items:
    total += x
return total          # returns after the whole loop

Both versions compile. Only one is what the author meant. An automatic tool that re-chooses the whitespace has to guess — and a wrong guess produces a file that compiles but behaves incorrectly. That is worse than an honest error, because it can slip past a weak test and be reported as success. So Outlier deliberately does not blindly re-indent broken code. We tested that shortcut, proved it could manufacture a false “green,” and removed it.

How Outlier handles it — honestly

Step	What happens
Detect	Every file written during a build is compile-checked. A file that doesn’t compile fails the verdict — even if no test imports it.
Repair from intent	Rather than re-shuffle whitespace, Outlier regenerates the whole file from its purpose and the surrounding code, then keeps the result only if it compiles.
Verify	The full test suite is re-run through the same sandbox. The verdict flips to green only on a real pass.
Or fail honestly	If the file still won’t compile, the build reports failed — never a success it can’t prove. You always know the true state.

And because a stubborn file can send the repair loop into a long grind, every repair and verification step is interruptible: pressing Stop halts the build in a fraction of a second, and no timer ever aborts a build that is genuinely making progress.

Where this is heading

The most durable fix is to make an invalid indent impossible to produce in the first place. Because Outlier controls its own on-device decoder, it can constrain generation so that at the start of every line the model may only choose an indentation level that is structurally valid — the model still decides which block a statement belongs to (its intent), but a level that would not compile is simply never emitted. In offline validation this constraint rejects exactly the real drift bugs above while allowing every correct choice. It is an engineering answer to a small-model precision problem — the kind of system-level work that lets an on-device assistant close the gap with a cloud model it can’t out-muscle.

Download Outlier for macOS

Requires Apple Silicon (M1, M2, M3, or M4) — Intel Macs are not supported.