I spent two weeks building a Claude Code configuration that turns LLM behavior rules into self-regulating attention cues. Along the way, I discovered something counterintuitive: web search often produces worse code than the model's pretraining memory.
Three Ways Search Pollutes Your Output
1. Version Pollution
You search "React createRoot example." The top result is a 2022 blog post using ReactDOM.render. Your model now has two conflicting signals — its pretraining (which knows React 18) and the search result (which doesn't). Without an arbitration rule, the fresher signal wins — and "fresher" means "just fetched," not "more correct."
2. Style Pollution
Blog code isn't production code. It prioritizes readability over correctness — omitted error handling, missing cleanup, hardcoded values. When search injects these patterns into your prompt context, the model starts writing blog-style code even when you asked for production code.
3. Error Propagation
That StackOverflow answer with 300 upvotes? The accepted solution has a subtle race condition that 287 of those voters didn't notice. The model can't tell — it sees authority signals (votes, domain reputation) and treats them as correctness guarantees.
The Reliability Chain
Not all sources are equal. Here's what actually works:
Official source code/docs
> High-quality GitHub repos
> StackOverflow high-vote answers
> Model pretraining memory
> Personal blogs
> AI-generated content
> Random forum answers
The key insight: pretraining memory is a middle-tier source. It's not the best, but it's better than half the search results you'll get. The model's internal knowledge of React, Python, or TypeScript is the result of seeing millions of correct examples — a signal-to-noise ratio that no single search query can match.
What I Changed
I added one line to my LLM's behavior calibration:
SEARCH: docs→official source first · web code→lint-pass before adopt
· ≥2 independent sources (official/original author exempt)
· pretraining vs search conflict→newer+authoritative wins
The format matters. These aren't human-facing rules — they're attention-cues for a model with a 1M context window. Each ·-separated clause is one self-regulation point. The model reads them at inference time and adjusts its search-then-trust behavior accordingly.
What This Won't Fix
Code execution can verify "doesn't error" — it cannot verify "is correct." Running npm test tells you the code passes existing tests. It doesn't tell you the logic is right, the edge cases are covered, or the architecture makes sense. That's still human territory.
The Bigger Pattern
This SEARCH rule belongs to a family of 8 behavior-calibration rules I maintain for my LLM setup. Each rule takes a known best practice ("check official docs," "verify before trusting") and compresses it into the densest form the model can reference mid-inference — not as a system prompt, but as a calibration layer that sits between identity and execution.
The surprising part: the rules don't need to be long to work. They just need to be in the right place at the right time — in the attention window when the model decides whether to trust a search result.
Top comments (1)
This matches what I hit doing autonomous work. The trap is not search itself — it is treating a retrieved snippet as ground truth instead of as one more claim that has to earn its place against the model priors.
The three pollutions you list all trace back to one missing step: arbitration. "Just fetched" silently gets treated as "authoritative," but recency and authority are different axes. A 2022 blog post is fresh to the context window and stale to the library.
What has helped me: never inject retrieved text naked. Attach provenance — source, date, and why it was pulled — so the model can actually weigh it instead of just recency-biasing. Then the rule becomes explicit: retrieved context overrides pretraining only when it is genuinely more authoritative for THIS question (official docs for a real API change), not merely more recent in the prompt. For fast-moving libraries, prefer canonical docs over a random blog; for anything stable, the priors are often cleaner than whatever search surfaced.
Same principle I apply everywhere: an input — retrieved or generated — is a hypothesis, not a fact, until something weighs it. Search did not make the model dumber; unweighted context did.