Why LLMs Seem to Get Wobblier Near Completion

The closer I get to finishing something with an LLM, the more carefully I find myself watching it.

You've seen the pattern too, I suspect. At twenty percent done, a clever suggestion is useful. At seventy percent, it might be useful. At ninety-five percent, a clever suggestion can wreck your afternoon. The last few miles of an AI-assisted project feel shakier than the first few, and I've started planning around that.

You know the symptoms. The model starts to drift and swirl. It reopens questions we settled two days ago. It chases whatever I said most recently. It wanders down a rabbit hole nobody asked about. It refactors code that no longer needs refactoring, and it improves parts of the system that should be frozen.

Why would a system that has accumulated more context and more knowledge about the task become harder to trust as it gets closer to completion?

I don't think this is a mystery about intelligence. My working theory is that it's a mismatch between what the tool naturally does and what the last stretch of a project actually needs. I'll state it plainly enough that you can prove me wrong.

The Easy Explanation, Which I Do Not Prefer

A colleague offered me the obvious hypothesis, and it's a good one. There's simply more written material in the world about starting and building things than about finishing them.

That is almost certainly true. Open source is full of half-finished repositories. Blog posts explain how to begin. Tutorials build toy versions. Stack Overflow captures the middle of problems. Conference talks describe architecture. Very little published material shows the disciplined, boring, high-restraint work of taking something from ninety percent to shipped, because nobody writes that down and nobody would read it if they did.

So I keep that one in my pocket as plausible. I just don't think it's the interesting one, and I doubt it's the main one.

Continuing and Finishing Are Different Jobs

So here's the version I actually work from.

LLMs are very good at continuing and not particularly good at being done.

Early and mid-project, continuing is exactly what I want. I want exploration, alternatives, refactoring, synthesis — the discovery of an approach better than the one I walked in with. When there are plenty of good moves left, a machine that produces the next plausible one is worth a lot.

Near the end, the job changes without anyone announcing it. The system doesn't need more possibility anymore. It needs less.

Completion increasingly requires a different set of behaviors:

• preserving constraints
• respecting decisions that are already settled
• resisting attractive alternatives
• avoiding regressions
• narrowing the solution space rather than widening it
• making surgical changes
• recognizing when something is already good enough
• and, most unnaturally for a generative system, stopping

Hold that list up next to what the tool is built to do. In the final phase we're asking a machine whose whole job is to produce the next plausible thing to please stop producing things. Nobody told it the rules changed. Nobody told it there were rules.

After I started talking about this, a colleague wrote back from a different field entirely. He doesn't write code with these tools; he works on language and meaning. His report matched mine almost line for line. His heavy lifting had turned into “hygiene, housecleaning, restraining and refocusing” — like trying to keep a bright kid on track when the kid would rather chase every idea in the room. The job had changed on him too, and nobody announced it there either.

The Work Shrinks While the Context Grows

Here's the part that matters in practice: as the solution space gets smaller, the context window gets bigger.

By late development, a long-running session may be carrying all of this at once: current requirements, old requirements, abandoned approaches, superseded architecture, debugging conversations, temporary workarounds, speculative ideas, rejected alternatives, old assumptions, corrections to earlier corrections, partial implementations, test failures, stylistic preferences, and a growing set of ad hoc exceptions.

Each of those mattered when it was written. Together they create more possible continuations, not fewer. The project is converging. The conversation isn't.

Call it context entropy, or scar tissue, whichever you like. I don't want to ride the metaphor too hard. The useful part is small and testable: the solution space should be shrinking while the model's narrative space keeps growing. If that's true, late-stage sessions should feel shakier than early ones even when nothing about the model changed. That's what I see.

My colleague told me the case that actually worries him, and it's not the model arguing with an instruction. It's the model quietly disregarding one — even instructions formally written into the project files. He catches himself repeating “please review your recommendation for over-fit against our test material,” even though the same rule sits in the repo in black and white. If you don't know you need to remind, and you don't know the reminding has to get more frequent as you approach the finish, nothing throws an error. The work just starts to spin.

The dangerous failures near completion are the quiet ones. The model doesn't refuse the instruction; it just stops following it, and it never tells you.

Preserve the State of the Work, Not the State of the Conversation

So I've started doing something deliberate about it.

Preserve the state of the work, not the state of the conversation.

For me that means keeping a good GitHub SpecKit as the canonical context for the system. The project's real memory lives in durable things: specs, architecture decisions, interfaces, constraints, acceptance criteria, tests, implementation notes, known exceptions, and the current code.

Chat history is not one of those things. It's a transcript of how we got here, which is a different thing from where we are. Treat it as project memory and you're treating every wrong turn as part of the record.

So when a harness starts to drift, swirl, or carry too much scar tissue, I tear it down. I start a fresh one with the latest SpecKit, the current code, the current tests, the known constraints, and only the relevant current state.

This feels wrong the first few times you do it. We assume more history should mean more intelligence, because the model knows more. But near the end, what matters probably isn't maximum historical context. It's minimum sufficient canonical context. Restarting the harness isn't an admission of failure. It may be the cheapest cleanup you can buy.

Canonical context may matter more than maximal context.

I want to be careful here. I don't know yet whether the win comes from dropping the noise or from forcing me to write a better spec before I restart. If it's the second one, that's mildly embarrassing, and still worth knowing.

Build Mode and Close Mode

The practical version of this theory is two modes for the same project, switched at the right time.

In Build Mode, earlier in the work, you want the model pushing: explore, challenge assumptions, propose alternatives, refactor, generalize, rethink the architecture, keep asking what else.

In Close Mode, near the end, the instructions flip. Preserve the architecture unless I explicitly authorize a change. Make the smallest change that works. No new abstractions. No opportunistic cleanup. Tell me what you intend to change before changing it, and tell me what you won't touch. Tests and acceptance criteria are hard boundaries. Run the regression checks after every meaningful change. Separate required fixes from nice-to-haves. Stop when the acceptance criteria are met.

The shift is easy to remember. Build Mode asks what could make this better. Close Mode asks what's the smallest thing that finishes it safely.

My suspicion is that most teams keep the same prompt posture from start to finish, even though the goal quietly changed somewhere around eighty percent. If that's right, this isn't a model problem at all. It's our mistake, and it's fixable.

Near the finish line, intelligence without restraint can look a lot like incompetence.

This is also why I keep insisting elsewhere that the discipline is test first, discover second, build third. Acceptance criteria written early are what make a stopping condition possible late. Without them, Close Mode has nothing to close against, and every suggestion looks equally reasonable.

Here's what I'd been taking for granted. In code, done has witnesses. Tests fail loudly. A compiler refuses. In his work there is no compiler for “what does this provision mean?” — nothing fails on its own, ever. Somebody has to notice, and the person doing the noticing gets tired. If your work has no compiler, your Close Mode discipline has to supply one.

Two More Brakes: Audits and a Second Model

Two of his practices are worth stealing.

The first is audits. Instructions decay, so stop trusting the model to remember and put the reminder on a schedule instead, the way you would backups. Re-check settled ground on purpose: does this recommendation still hold against the test material, the constraints, the decisions we froze last week?

The second is a second model as judge. He keeps a couple of plain Markdown files for passing work between several LLMs that review and critique each other's output, which also means he can swap models and vendors whenever he likes. Near completion, a fresh model with no stake in the conversation is often a better reviewer than the model that did the work. And notice what the judge gets handed: the canonical spec and the artifact, not the chat history. The state of the work, not the state of the conversation.

How Could This Theory Be Wrong?

A working theory that can't fail isn't worth working from. So here's what else could explain this, and what each explanation predicts.

Alternative 1: It is the training-data distribution

Maybe my colleague's original intuition is simply correct, and there is far more material showing code being written, revised, and discussed than material showing disciplined final-stage completion. The prediction: models specifically trained or fine-tuned on high-quality completion workflows should show much less late-stage wobble even with long conversational context. If that holds, the continuation-versus-completion framing is decoration on a data problem.

Alternative 2: It is context length alone

Maybe nothing special happens near completion, and quality simply degrades as sessions get longer and noisier. The prediction: a long session at thirty percent complete should drift about as much as a long session at ninety-five percent. If it does, this is context degradation rather than a lifecycle thing, and I can stop talking about finishing altogether.

Alternative 3: It is us

Maybe humans become far less tolerant of model mistakes near completion. Early errors feel cheap because everything is still fluid. Late errors feel catastrophic because the system is nearly done. The prediction: measured error rates stay roughly constant while perceived severity rises sharply. If that is what the data shows, the wobble is partly in the operator.

Alternative 4: It is bad task decomposition

Maybe late-stage instability is mostly a symptom of poorly specified boundaries. The prediction: explicit constraints, clean acceptance criteria, and close-mode prompts should eliminate the problem almost entirely. If they do, this is workflow discipline rather than fundamental model behavior, which would make it a much easier problem and a much less interesting theory.

Alternative 5: It is a transitional artifact

Maybe stronger reasoning models and better agentic harnesses recognize completion states on their own. The prediction: newer systems stop exhibiting the pattern without any change in how we prompt them. If so, everything here describes a temporary property of current architectures rather than a durable principle, and it should be allowed to expire.

I'd be fine being wrong about any of these. Four and five would be good news.

Experiments Worth Running This Month

None of this needs a lab. You can run all four inside normal delivery work.

Experiment 1: Same task, two contexts

Take a project at roughly ninety percent. Run the same final task twice: once in the long-running conversation, once in a fresh harness loaded only with the canonical spec, code, tests, and current state. Compare regressions, unnecessary file changes, architectural drift, irrelevant suggestions, test failures, completion time, and how much human correction each one needed. If canonical fresh context consistently wins, accumulated conversation is part of the problem.

Experiment 2: Build Mode against Close Mode

Run the same late-stage task with two system prompts. One encourages broad improvement. The other freezes the architecture, prohibits unrelated refactoring, demands minimal diffs, and defines a stopping condition. If Close Mode clearly cuts regressions and stray changes, lifecycle-aware prompting belongs in your engineering standards, not just in your personal habits.

Experiment 3: Completion percentage against context size

Test tasks at roughly thirty, sixty, ninety, and ninety-eight percent complete while holding context size relatively constant. If instability rises with completion percentage even under controlled context, there is something particular about finishing. If instability tracks context size instead, my theory needs revision and Alternative 2 is winning.

Experiment 4: Perceived against measured wobble

Measure actual regression and error rates at each stage. Separately, ask the developers to rate how disruptive each mistake felt. If technical error rates stay flat while perceived damage climbs, operator psychology is a real part of the story, and the fix is partly about how we schedule and stage late work rather than how we prompt.

What I Think Is Actually Going On

Maybe the lesson isn't that models get dumber near the end. Maybe we're asking a machine built to keep going to wrap things up, and nobody told it.

If that's right, the answer isn't another twenty percent of model intelligence. It's a better definition of done, a smaller canonical context, and the discipline to start fresh when the conversation stops serving the work.

The final ten percent may need a different operating system, not a smarter model.

And if that doesn't measurably help, the theory is wrong. Useful to know. I'd rather retire it early than defend it for a year.

So I'll end with the question I actually want answered. Are you seeing the same late-stage wobble? If you are, what experiment would you run to figure out whether it's the model, the context, the workflow, or us?