Context Engineering: Four Antipatterns Breaking Coding Agents
In this article
Coding agents fail in ways that look mysterious until you understand what's actually traveling across the wire. At QCon, Baruch Sadogursky (DevRel and Context Engineering Management at Tessl AI) and Patrick Debois — who coined the term DevOps — walked through four concrete antipatterns that break agentic coding workflows, using live Claude Code demos where a bloated CLAUDE.md caused an endpoint to return HTTP 500 instead of 404. The root cause wasn't a weak model; it was conflicting, redundant instructions consuming context that could have held signal. Their prescription is architectural: structure the context layer the way you structure software.
This is directly relevant to anyone operating agents in production workflows, where context mismanagement is fast becoming the dominant failure mode rather than raw model capability.
Antipattern 1: The Stuffed Prompt
The demo scenario was precise: a single CLAUDE.md containing code samples, documentation, best practices, and conventions — 700 lines, with four conflicting references to error handling alone. Asking the agent to add error handling to one endpoint produced a try/catch block that caused test failures because the agent reconciled contradictory instructions unpredictably.
The fix is lazy-loaded skills. A skill is a markdown file with two components: a human-readable name and a description that the agent evaluates at runtime to decide whether to load the file at all. Sadogursky was explicit that developers will default to copying the title into the description field — which defeats the mechanism entirely. The description is the activation predicate. When the demo replaced the monolithic CLAUDE.md with a properly described skill scoped to error handling, the identical prompt produced passing tests.
Skills partition context along functional lines so that frontend conventions don't pollute backend tasks. Debois noted that Claude delegates to sub-agents precisely to exploit this — sub-agents start with zero context, execute, and return results, sidestepping accumulation. One caveat: no current system unloads skills once triggered within a session, so session hygiene still matters.
Sadogursky then pushed the analogy further: skills stored as raw GitHub files are not properly managed artifacts. The relevant properties — versioning, access control (public, private, team, org-scoped), distribution, dependency on bundled code and documentation — map to artifact registries, not source trees. Drawing on his time at JFrog arguing against storing jar files in Git: treat skills as versioned, distributable artifacts with their own lifecycle.
Antipattern 2: Wrong Retrieval for the Job
The second demo used a RAG server over MCP to fetch documentation for a notification library called pidge. Vector search returned a result with relevance score 0.76 — high by semantic similarity standards — but it surfaced version 2 docs when the project required version 3. Tests failed.
Debois articulated why RAG's limitation is structural: semantic similarity is not relevance. A document answering the same question is a strong match by embedding distance but may be factually wrong for the version in use. Chunking compounds this — splitting large documents at arbitrary offsets can sever exactly the context needed. He also noted empirically that early coding agents moved from RAG-based code indexing toward grep and structured search because results were measurably better.
The four retrieval channels the presenters mapped out each have distinct tradeoffs:
| Channel | Mechanism | Strength | Key Failure Mode |
|---|---|---|---|
| RAG / semantic search | Embedding similarity via MCP | Good for broad, unstructured corpora | Similarity ≠ relevance; wrong version retrieval |
| Web search | Keyword or semantic query to live web | Current, dynamic information | Niche topics return outdated or low-quality results |
| Rules | Always-loaded system prompt snippets | Strict, unconditional constraints | Adds to context window on every invocation |
| Versioned doc artifacts | Packaged docs + rules + skills in a registry | Exact version pinning, bundled best practices | Requires artifact authoring and distribution infrastructure |
The fix for the pidge demo was a versioned context artifact — a "tile" bundling version 3 docs, rules mandating async API usage and prohibiting obsolete versions, and skills describing integration patterns. Three independent version-3 signals (docs, rules, skill description) meant the agent could not drift to the wrong version. Tests passed. Debois noted that library vendors are beginning to ship these artifacts alongside code releases, giving LLMs accurate, version-matched context without relying on training data cutoffs.
Antipattern 3: The Goldfish Agent
Clearing context to reduce bloat destroys decisions made during the session. The demo showed this directly: after deciding to use version 3 of pidge in one session, clearing context and asking what version to use returned a blank slate. Built-in agent memory (Claude's MEMORY.md writes and /compact summarisation) exists but is opaque — the user cannot inspect what was retained, what was discarded, or what the compaction heuristic prioritised.
The architectural response is externalized, schema-governed memory. Sadogursky referenced Memento as the design pattern: the agent writes decisions to .memory/decisions/ in a defined format specified in the project's skill rules. A second rule instructs the agent to read from that path when entering a new context with no prior state. No custom code is required — the behaviour is expressed entirely as skill descriptions and rules, and the demo showed the agent locating and reading the correct decision file after a full context clear.
This externalises the memory feedback loop in a way that is auditable and version-controllable, unlike the current black-box compaction mechanism — analogous to what direct corpus interaction approaches attempt at a larger scale.
Antipattern 4: Vibes as Evaluation
The fourth antipattern is validating agent improvements through intuition — what the presenters called a "vibe check." The alternative is LLM-as-a-judge evals: a defined project state, a prompt, agent execution, and then a second LLM evaluating the output against rules that specify both how to produce code and how to assess it. The eval harness itself is expressible as skills and rules, making it part of the same versioned artifact system. Context artifacts can carry their own test specifications, and improvements to skills or docs can be validated before distribution rather than discovered at runtime.
The structural argument across all four antipatterns is consistent: context is a data layer with the same engineering requirements as any other — versioning, access control, schema, testing, and distribution. Teams that treat CLAUDE.md as a junk drawer and memory as a black box accumulate the same hidden technical debt that eventually manifests as unreliable agent behaviour at scale. The shift from prompt engineering to context engineering demands artifact management thinking — not just better writing skills.