What Not to Do

Now that you know how to work with the agent, there are a few patterns you should avoid. They may feel natural, but they usually produce worse results.

Source: Augmented Coding Patterns Lada Kesseler et al. 2026-03-11

Distraction

You may be tempted to give many responsibilities to an agent in a single thread, because that is how you would talk to a co-developer. Once they finish one task, they move to the next, then eventually make sure they finished everything you asked for. With agents, though, packing too many responsibilities into one thread spreads attention thin. Specialisation matters: the same ground rules work better when an agent only needs to track one concern.

How to fix it:

1. Identify the single concern — before writing the prompt, name the one thing this thread is responsible for.
2. Open a new thread per concern — lateral problems get their own threads.
3. Prime the context for that concern only — only load the files, rules, and background that are relevant to the task at hand. Everything else is noise that competes for attention.

👏 +1

…

Taking recall for granted

We often expect the model’s recall to be imperfect for the data we provide, but we do not apply the same caution to the model’s training data. We should. Instead of relying on recall, confront the agent with the data.

How to fix it:

1. Point to the source — instead of asking the agent what a library does, tell it to read the documentation or the source code directly. Attach the relevant file or URL to the prompt.
2. Try it out — for less popular APIs, ask the agent to write a small test first and verify whether it works. You can give it a playground folder to experiment in.
3. Write findings into the repository — once the agent learns something worth keeping, be it a working pattern or factual knowledge, have it write it down in a Markdown file. Knowledge that lives in the codebase survives thread resets. Always remember that agents do not actually learn. They have to be presented with the information.

👏 +1

…

Stacking assumptions

Without validating each step, the agent may build on unstated assumptions, and when something goes wrong, the wrong turn is several layers deep. It is the same as a human writing long batches of code without running it.

How to fix it:

1. Set a short validation loop — after each meaningful step, check the output before moving forward. You can have the agent do it.
2. Make assumptions explicit — when planning, ask the agent to list its assumptions before it starts. This is the time to correct them.
3. Checkpoint before complexity — at any point where the plan branches or grows, commit what you have.

👏 +1

…

Accepting silent compliance

Agents still tend to be too compliant. They try to give an answer that satisfies the user immediately. If your instruction does not make sense, or is ambiguous, the agent may not tell you. Instead, it may comply and generate code that fails.

How to fix it:

1. Grant explicit permission to push back — include a line in your prompt or AGENTS.md (CLAUDE.md if you use Claude Code) that tells the agent to raise concerns, ask clarifying questions, and flag contradictions rather than resolve them silently.
2. Ask for a confidence check — before execution, prompt the agent to state what it understood and whether anything is unclear.
3. Look into the reasoning — if the agent never hesitates on a complex task, that is a red flag—it probably made some unstated assumptions.

Tip

Put the push-back permission in AGENTS.md once and it applies to every thread, not just the ones where you remember to ask.

Tip

In Claude Code, you can use the brainstorm mode that automatically asks you clarifying questions, but at the expense of heightened token usage.

👏 +1

…

Running a thread until it rots

Agents fare better with smaller context. When the conversation grows, so does the context. The agent does not learn anything; the entire conversation serves as its context each time. Most often, the information from the beginning of the conversation is no longer crucial, and it only makes it harder for the agent to concentrate on the task at hand. The reset is not expensive—continuing the current thread is.

How to fix it:

1. Watch for degradation signals — repeated mistakes the agent already fixed, ignored instructions, or outputs that feel slightly off are all signs the thread has run too long.
2. Reset proactively, not reactively — do not wait for something to break. When starting a new task, start a new thread.
3. Summarise before closing — before resetting, you can ask the agent to write a short summary of what was decided and what remains. Unless the rot is already significant, the summary should be a good starting point for the new thread.

Remember

Starting fresh is always cheaper than debugging a degraded thread.

👏 +1

…

Embedding your solution in the question

Framing a prompt around your assumed solution narrows the search space before the agent has a chance to explore it. Even if you later decide to continue with your solution, first ask the agent how it would solve the problem without your suggestions. Maybe there is a better alternative.

How to fix it:

1. Describe the problem, not the fix — strip your assumed solution out of the prompt. State what you are trying to achieve and what constraints apply, then stop.
2. Ask for options first — instruct the agent to propose several approaches before picking one. Review the list and choose, or ask it to evaluate the trade-offs.
3. Introduce your idea late, if at all — if you have a strong preference, share it after the agent has explored the space. That way, you can compare rather than just confirm. The agent can also provide feedback on your solution and point to potential problems, but you have to ask for it. Agents are too nice on their own.

👏 +1

…

Treating the first attempt as final

Remember that agents are not deterministic. Since the outputs on the same input differ, there is no guarantee that the first try yields the best answer.

How to fix it:

1. Do a human review — read the output critically before accepting it. If it is wrong in many places, it may be cheaper to ask for another attempt than to debug it.
2. Iterate on weak spots — when a separable part looks off, point it out and ask for another pass. A second attempt with targeted feedback is almost always better than the first without it.
3. For high-stakes tasks, sample more than once — run the same task in parallel branches and compare the results. The parallel implementations pattern is built exactly for this.

👏 +1

…