I didn’t notice the pattern all at once.
At first, it just looked like normal software work.
We’d fix something in PageSnip. Then we’d polish something near it. Then I’d notice another behavior that wasn’t quite right and say, in one form or another, “And one more thing.”
That seemed reasonable.
The AI was already in the project. It had already been reading code. It already knew the current problem. It was fast, responsive, and able to make changes faster than I could describe them.
So why start a new thread?
Why not keep going?
PageSnip is the kind of project where that question matters. It isn’t a hundred-line demo. It’s a large application with hundreds of active files, a lot of features, and a product layer built on top of a shared application shell. There are places where PageSnip-specific code belongs. There are places where the shared shell owns the pattern. There are places where a local change is safe, and places where a local change is exactly the wrong answer.
That last part is where “one more thing” started getting expensive.
The AI would usually solve the problem I gave it.
That wasn’t the issue.
The issue was that sometimes it solved the problem too locally.
A behavior would show up in one part of the program, and the AI would patch that spot. The visible symptom would improve. The immediate task would look done. But later we’d discover that the change had weakened something else, duplicated a pattern, bypassed a shared rule, or disturbed an area that had already been carefully balanced.
That’s not the AI being stupid.
It’s the AI doing what the conversation encouraged it to do.
When a thread has been working in one area for a while, it builds a kind of gravity. The next request gets pulled toward the same frame. If I add another issue that’s only loosely related, the AI may treat it as part of the current patch instead of stopping to ask whether it needs a fresh look.
That matters more as a project gets closer to release.
Early in a project, you can get away with more. You’re still discovering the shape of things. Code moves around. Patterns aren’t settled. A local fix may be good enough because the system itself is still forming.
But later, once the application has real structure, the cost changes.
PageSnip has had several areas that we tuned and retuned as it matured. Navigation behavior. Long column performance. Moving between collections and libraries. Tab behavior. Shared shell boundaries. The more balanced those areas became, the more dangerous it was to let a quick local fix sneak in from the side.
We weren’t breaking things because we were careless.
We were breaking things because the system had become mature enough that small changes needed more respect.
One of the habits I developed was asking the AI, “How are we doing on this thread?”
More and more, the answer came back with a useful warning:
We probably have room for something small, but we shouldn’t start anything big here.
That answer changed the way I thought about the work.
The issue wasn’t just whether the thread had room. It was whether the thread had the right kind of room.
There may be enough room for another prompt.
There may be enough room for another patch.
There may even be enough room for another explanation.
But enough room for words isn’t the same thing as enough room for judgment.
Some tasks need a clean start.
They need the AI to read the relevant documentation again. They need it to inspect the code instead of relying on the last mental map. They need it to decide whether the change belongs in PageSnip itself or in the shared application shell. They need it to understand that this is a balanced system, not a pile of isolated symptoms.
That’s why fresh threads started producing better results.
A fresh thread lets me set the rules before the AI starts working:
Read the documentation.
Look at the code.
Understand the architecture.
Respect the shared shell.
Don’t make a local fix if the correct fix belongs in a shared pattern.
Remember that PageSnip is near release, so the goal isn’t just to make the symptom go away. The goal is to solve the problem without damaging the system.
That kind of opening changes the work.
The AI is still fast. It’s still helpful. It’s still doing what AI is good at.
But now it’s doing the work from the right map.
That’s the lesson I took from it.
“And one more thing” isn’t always bad. Sometimes the extra thing is genuinely part of the same patch. If we’re already changing a label and the tooltip beside it is wrong too, fine. Fix both. If we’re already updating a setting and the help text beside it needs the same wording, that belongs together.
But when the next request crosses into another feature area, another architectural layer, or another kind of problem, it’s not one more thing.
It’s a new thing.
And new things deserve a clean start.
The temptation with AI is to keep loading the cart because the AI can carry it.
But the better question isn’t how much the AI can carry.
The better question is whether everything in the cart belongs on the same trip.
That is the lived-workflow story behind the companion guide, And One More Thing.
-- Charles