Context window collapse: why AI starts breaking working code

The failure mode

Context window collapse is what happens when the tool looks smart for the first hour, then slowly forgets what it already built.

At first, the assistant feels sharp. It knows the files, follows the feature request, and makes confident edits. Then the drift starts:

it rewrites code that already worked

it reintroduces old bugs

it contradicts earlier architecture choices

it fixes one thing by breaking something that was stable

This is one of the main reasons builders say a project felt easy at the start and impossible a few days later.

How this problem usually shows up

You ask for one small change and the tool edits three unrelated files.

It starts inventing functions or props that do not exist.

It stops respecting the current database shape or auth flow.

It rewrites styling or layout when you only asked for backend logic.

The same bug keeps coming back after it was "fixed."

The dangerous part is that the model often stays confident while it is drifting.

Why it happens

AI coding tools do not remember your project the way a careful developer does. They work from a moving snapshot of context: recent prompts, selected files, inferred patterns, and whatever the model can fit into the active window.

Once the project gets longer, noisier, or less structured, that context gets worse.

Common triggers:

too many prompts without a reset

no stable app brief or architecture note

multiple half-finished features in flight

vague prompts like "clean this up" or "make it better"

letting the tool touch too much code at once

This is why Cursor, Windsurf, and Cline feel amazing in a clean repo and much less amazing in a chaotic one.

What builders get wrong

The usual mistake is blaming a single bad answer instead of the workflow that produced it.

Builders often:

keep prompting deeper into a broken branch

ask for "one more fix" instead of resetting the task

treat the tool like a persistent teammate when the context has already drifted

skip checkpoints, commit boundaries, and working snapshots

If the model has already lost the plot, more prompting usually makes the state worse.

What to do instead

1. Shrink the task

Do not ask for "improve the dashboard" or "fix the auth flow."

Ask for one bounded move:

rename this field everywhere

fix this one component state bug

add this one API handler

update this one table query

Smaller tasks survive longer than abstract rewrites.

2. Re-ground the model before major edits

Before the next prompt, restate the current truth:

which files matter

what must not change

what success looks like

Example:

Do not touch billing, auth, or styling. Only update the onboarding form submit handler in app/onboarding/page.tsx to send data to the existing POST /api/profile route.

3. Add a working checkpoint every time something becomes stable

If you are using Cursor or Windsurf, commit or snapshot the branch once a piece works.

The rule is simple:

if it works, save it

if the next prompt breaks it, revert fast

Without checkpoints, the recovery cost becomes brutal.

4. Keep a short architecture note

You do not need a giant spec. You need one short file that says:

stack

database tables

auth model

naming rules

what is already working

That note gives the tool something stable to anchor to.

5. Reset when drift starts

If the tool has started rewriting working code, stop using the current thread as the source of truth.

Open a fresh session and provide:

the bug

the relevant files

the current intended behavior

what must not change

That reset is often faster than trying to rescue a poisoned conversation.

Good-enough fix

If you need a practical reset today:

Revert to the last working state.

Write down the exact change you still want.

Limit the next prompt to one file or one function.

Explicitly list what must stay untouched.

Test immediately after the change.

This is not glamorous. It works.

Best tools for this problem

Cursor: strongest when you can inspect diffs and control scope

Windsurf: useful for larger codebase awareness

GitHub Copilot: safer when you want smaller suggestions instead of big rewrites

If you are repeatedly hitting collapse because the project is not clearly scoped, also read Why weak prompts create weak apps and Why vibe coding projects die from scope creep.

Builder takeaway

Context collapse is not a sign that AI coding is fake. It is a sign that the workflow needs tighter boundaries.

The better rule is:

use AI for bounded moves

keep human control over architecture

save every stable milestone

That is how you keep the tool useful after the first hour instead of letting it slowly eat the project.