There’s a dangerous little phrase in AI-assisted programming.
“And one more thing.”
It sounds harmless.
You’re already in the thread. The AI already knows the project. It’s seen the last bug, the current files, the latest design decision, and the thing you just fixed. It’s fast. It’s available. It doesn’t complain about being interrupted.
So why not add one more request?
Fix this while you’re there.
Clean up that wording too.
Look at this other behavior.
Check this related problem.
And one more thing.
That habit feels efficient because it matches the way humans stack errands. If you’re already going to the store, you might as well pick up everything on the list.
But code isn’t a store.
A large application is a connected system. The fact that two problems appear near each other doesn’t mean they share the same cause, the same layer, or the same fix.
When One More Thing Is Fine
In a small program, task stacking may not matter much.
If the whole project is one file or a few short files, the AI can usually keep the system in view. The symptom, cause, and fix may all live close together. In that setting, asking for three small changes in one pass may be perfectly reasonable.
For example:
- Rename a variable.
- Clean up a message.
- Fix a typo.
- Add a small guard clause.
- Adjust a nearby test.
Those changes may all belong to the same patch.
There’s nothing magic about one task per thread. The real question is whether the tasks belong to the same mental map.
When One More Thing Becomes Risky
The danger starts when the next request isn’t really part of the same job.
That happens often in large projects.
A large project may have hundreds of files, several feature areas, shared components, old decisions, performance constraints, release requirements, and patterns that exist for reasons that aren’t obvious from the local symptom.
In that kind of system, the place where a problem appears isn’t always the place where the problem belongs.
A visual issue may show up in one component, but the real rule may live in a shared layout system.
A navigation problem may appear on one screen, but the behavior may depend on a common shell pattern.
A performance complaint may be visible in one view, but the fix may require understanding the data flow, caching, rendering, and background work around it.
This is where “and one more thing” becomes a trap.
The AI may solve the immediate problem too locally.
The Local Fix Problem
AI is very good at finding a nearby answer.
That’s useful when the nearby answer is the correct answer.
It’s dangerous when the nearby answer only fixes the symptom.
In a long thread, the AI is already oriented around the work you were just doing. That orientation can help. It can also become a bias. When you add a new request, the AI may keep working from the old frame instead of stepping back to rebuild the map.
It may think:
This looks like a local component problem.
This can be patched right here.
This solves the visible behavior.
And technically, it may be right.
The immediate problem may go away.
But the system may be worse.
The fix may bypass a shared rule. It may duplicate logic that already exists elsewhere. It may bend a pattern that other features depend on. It may make the current screen better while making the application less consistent.
That isn’t the AI being bad.
It’s the conversation pushing the AI toward the nearest solution instead of the best-grounded solution.
Thread Room Is Not the Same as Thinking Room
One useful habit is to occasionally ask:
How are we doing on this thread?
The answer can be revealing.
Sometimes the answer isn’t, “We’re out of room.” It’s more like:
We probably have room for something small, but we shouldn’t start anything big here.
That distinction matters.
A thread may still have room for more words. It may still have room for another prompt. It may still have room for another patch.
But enough room for words isn’t the same thing as enough room for judgment.
A new architectural task needs clean attention. It needs the AI to read the relevant documentation, inspect the right files, understand the layer boundaries, and decide where the fix belongs.
A crowded thread can make that harder.
Not impossible.
Harder.
And in software development, harder usually means riskier.
The Real Question
Before adding “one more thing,” ask a better question:
Does this new request belong to the same patch?
Not the same project.
Not the same product.
Not the same afternoon.
The same patch.
That means:
- same feature area,
- same files or nearby files,
- same behavior,
- same cause,
- same test path,
- same architectural layer.
If the answer is yes, it may be fine to continue.
If the answer is no, start a new thread.
Good Bundles
Some tasks naturally belong together.
For example:
- Fix the save button label and the tooltip beside it.
- Adjust a form validation message and the test that covers it.
- Repair an image paste bug and update the nearby user-facing error message.
- Change a setting name and update the matching help text.
- Refactor a helper function and update the call sites involved in that exact behavior.
Those are coherent bundles.
The AI can work inside one clear frame.
Bad Bundles
Other task stacks only look related because they’re in the same application.
For example:
- Fix navigation performance, then adjust image paste handling.
- Update the share dialog, then change editor save behavior.
- Polish dashboard rendering, then modify the shared shell layout.
- Repair a file watcher issue, then clean up licensing text.
- Fix one local visual glitch, then change a cross-application component.
Those may all be valid tasks.
They just don’t belong in the same thread.
They need different maps.
Why Fresh Threads Work Better
A fresh thread gives the AI a better starting point.
You can begin with the right instruction:
Read the relevant documentation.
Inspect the actual code.
Identify whether the problem belongs in the product layer, shared shell, data layer, UI component, or user-facing copy.
Don’t guess from the symptom.
Don’t make a local patch if the correct fix belongs somewhere else.
Respect the existing balance of the system.
That kind of instruction changes the work.
The AI is no longer continuing yesterday’s path. It’s orienting itself for today’s task.
That’s especially important near release, when the application is no longer a rough prototype. At that stage, every change should be smaller, more deliberate, and more respectful of the system that already works.
A Practical Rule
Here’s the rule I use now:
Bundle tasks when they belong to the same patch.
Split tasks when they require different maps.
“And one more thing” isn’t automatically wrong. It’s wrong when the extra thing deserves fresh orientation and you try to sneak it into an old conversation.
The AI may still solve it.
That’s the problem.
It may solve it locally, quickly, and confidently, while quietly making the larger system worse.
Better Prompt
Instead of this:
While you’re in there, also fix this other thing.
Try this:
This may be a separate task. Before changing anything, decide whether it belongs to the same patch as the current work. If it crosses into a different subsystem, layer, or architectural pattern, stop and recommend a fresh thread.
That one sentence can save hours.
It gives the AI permission not to continue.
Sometimes that’s exactly what you need.
Where This Goes Next
In Real Programmers Use AI, this becomes part of a larger workflow rule: don’t confuse AI speed with task safety. AI can move fast, but large systems still require boundaries, orientation, and judgment.
The point isn’t to slow the work down.
The point is to keep fast work from becoming careless work.
Real programmers don’t avoid AI.
They learn when to say:
That’s not one more thing.
That’s the next thing.
Related field note: The Day One More Thing Became the Real Bug.
-- Charles