The endless thread is a smell
A lot of new AI coding tools seem to be built around the same idea: start a thread, keep feeding it work, and let it run forever. I don't understand the appeal.
You can see the assumption hardening into product features. Claude Code lets you name sessions, find and resume them by name, branch them, and export their transcripts. Why would a coding conversation need a name? Cursor has editable chat titles, stored history, Markdown exports, and a way to pull old chats into the current one. They sound intuitive features to add at first, but they're based on the premise that a conversation is a durable unit of work rather than a temporary interface for completing a specific task.
Some tasks take a long time. A large feature needs a proper spec, implementation, testing, and several rounds of correction. Handing that work to an agent doesn't make the complexity disappear, but complexity isn't the same as continuity. Most large tasks should still become a series of small, discrete deliverables: define the interface, add the data model, implement one path, test it, review it, commit it, and then move on.
That was already better engineering before AI. It produces changes that are easier to understand, test, review, revert, and ship, and AI makes the case stronger.
Agents have limited context, so their assumptions drift and their mistakes compound. The products compensate by summarizing old conversation as the window fills; GitHub even describes automatic compaction as enabling "virtually infinite sessions". The longer a thread runs, the harder it becomes to know which decisions still matter, which constraints have fallen out of view, and whether the latest change quietly broke something from 40 messages ago.
Validation gets worse too. Reviewing one small change is a tractable job, while reviewing a sprawling branch produced across hours of prompts is archaeology. The endless thread often looks like an agent capability problem, which leads us to ask how we can give it more memory, let it work for longer, or recover when it wanders off course. Sometimes the problem is simpler: the user hasn't broken the work down.
That doesn't mean every task needs micromanagement, or that an agent can't own a meaningful chunk of work. It means the chunk should have a clear boundary and an outcome you can verify, because a long implementation can still be a sequence of short contracts.
The goal isn't to keep the agent busy, but to keep the work legible. Work quickly and in small increments, check the result, bank the progress, and start the next piece with a clean understanding of what exists. If a coding tool needs one immortal conversation to build useful software, it may be solving the wrong problem.