add the "what not to do" section

astro.config.ts

@@ -55,6 +55,7 @@ export default defineConfig({
             { slug: "becoming-productive/security" },
             { slug: "becoming-productive/legal-compliance" },
             { slug: "becoming-productive/going-10x" },
+            { slug: "becoming-productive/what-not-to-do" },
           ],
         },
         {

src/content/docs/becoming-productive/what-not-to-do.mdx

@@ -0,0 +1,146 @@
+---
+title: What Not to Do
+description: Common anti-patterns when working with coding agents and how to avoid them.
+---
+
+import { Steps } from "@astrojs/starlight/components";
+import ExternalLink from "../../../components/ExternalLink.astro";
+
+Now that you know how to work with the agent, there are some negative patterns you want to make sure you do not follow. They may feel natural, but they naturally produce worse results.
+
+Source: <ExternalLink href="https://lexler.github.io/augmented-coding-patterns/talk/" />
+
+## Distraction
+
+You may be tempted to give many responsibilities to an agent in a single thread, as that is how you would talk to a co-developer. 
+Once they finish one task, they would move to the next, then eventually make sure they finished all that was asked of them.
+However, giving an agent too many responsibilities in a single threat is spreading its attention thin.
+Specialisation matters: the same ground rules yield better results when an agent only needs to track one concern.
+
+**How to fix it:**
+
+<Steps>
+
+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.
+
+</Steps>
+
+## Taking recall for granted
+
+We often expect the model's recall not to be perfect when it comes to the data we provide, but we do not have the same concerns for recall on the model's training data, and you should.
+Instead, try to confront the agent with the data.
+
+**How to fix it:**
+
+<Steps>
+
+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 if it works. You can give it a playground folder to experiment.
+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.
+
+</Steps>
+
+## 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:**
+
+<Steps>
+
+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.
+
+</Steps>
+
+## Accepting silent compliance
+
+The agents still have a problem with being too compliant. 
+They want to give an answer that satisfies the user immediately. 
+If your instruction does not make sense, or is ambiguous, the agent likely will not tell you this. 
+Instead, it will comply and generate code that likely fails.
+
+**How to fix it:**
+
+<Steps>
+
+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.
+
+</Steps>
+
+:::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.
+:::
+
+## 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 info from the beginning of the conversation is not crucial, and 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:**
+
+<Steps>
+
+1. **Watch for degradation signals** — repeated mistakes the agent already fixed, instructions being ignored,
+   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.
+
+</Steps>
+
+:::note[Remember]
+Starting fresh is always cheaper than debugging a degraded thread.
+:::
+
+## 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 go on with your solution, try asking the agent how it would solve the problem itself without your suggestions.
+Maybe there is a better alternative.
+
+**How to fix it:**
+
+<Steps>
+
+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, they are too nice on their own).
+
+</Steps>
+
+## 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 an optimal answer.
+
+**How to fix it:**
+
+<Steps>
+
+1. **Do a human review** — read the output critically before accepting it. If it is wrong in many places, it may be cheaper to try asking it to do the same thing again, rather than trying 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](/becoming-productive/prompting-techniques/#parallel-implementations) pattern is built exactly for this.
+
+</Steps>