Long AI Chats Don’t Degrade — Unstructured Ones Do

The advice is everywhere: long-running chats degrade, so start a fresh one before the quality falls off. I mostly agreed with it. Then I spent eight weeks testing how far I could push a single chat instead.

The job was a refactor of a critical, high-throughput system — one that handles millions of asynchronous events a day. I’d have scoped it at roughly six months of human effort. It took eight weeks, and for the first six I deliberately stayed in one chat the whole way.

It didn’t degrade. It got better.

The reframe: it’s not length, it’s shape

Here’s the thing the “start fresh” advice misses. The chat compacted itself several times along the way — when a session gets long, it trims its own history to stay inside the model’s context window, keeping what’s live and dropping the rest. Picture clearing your desk mid-project: you bin the notes you’re finished with and keep the ones you’re still working from.

That trimming is where quality usually leaks. But the work here was linear. Each step built on the last, so the model only ever needed the recent context, never the start. Every compaction stayed clean. It held on to what mattered and let go of what didn’t, because what mattered was always close by.

Degradation isn’t a tax on length. It’s a tax on sprawl.

The part I didn’t expect

Early on I repeated the same instructions constantly. After a while, the model just did them — unprompted, across 35 to 40 pull requests.

Before you start:   open a ticket.
Before you commit:  run the acceptance checks.
On PR feedback:     summarise the comments and flag them to me — don’t action them.
After a rollout:    watch for the signals that mean it’s going wrong.
On a schedule:      run the prod checks on a timer, and report back.
To call it done:    use the metrics, not your optimism.

It felt less like a tool and more like a junior engineer I’d onboarded into my way of working. The escalation was the striking part. At first it asked me to confirm each PR had merged before it ran the post-release checks. Then it stopped asking — it just queried GitHub directly for the build status and carried on.

And the checks weren’t generic uptime pings. They were tied to what this system actually did: how many tasks it processed, how many events it consumed across our integration points, how many of those stalled on latency. The sharpest signal was a parity funnel. For every event, it compared the new architecture’s output against the old legacy path and tracked the match rate. Where the two disagreed was where the risk lived. Almost none of that transfers to another project.

Where explicit memory couldn’t follow

The obvious next move was to lift those habits into the memory feature — the thing that’s meant to carry context between separate chats — so every session would start with them. It didn’t take the same way. Fresh sessions were clunkier. They skipped steps and needed reminding.

Part of the reason is that not everything generalises. Some of the post-release steps were specific to this one system, which is exactly why the long session beat any generic skill I could have written down. The knowledge that made it effective wasn’t a reusable rule. It was a feel for this work, accumulated in place.

What I changed my mind about

So I’ve flipped my view. Long chats aren’t the problem. Unstructured ones are.

The numbers that hold it up: eight weeks against a six-month estimate, 35 to 40 PRs, six of those weeks inside a single chat that got sharper as it went. This was on Opus 4.6, then 4.7.

When the work is linear and you stay in one place, the model doesn’t just hold context — it adapts to how you work, in a way explicit memory can’t match yet.