Agent Config Decay

The tendency of coding-agent configuration (CLAUDE.md/AGENTS.md, skills, hooks, memory) to accumulate stale, over-specific rules as models and harnesses improve past what those rules were written for — driven by a self-reinforcing cycle where an agent's error prompts a new rule, the rule dilutes what matters, and adherence drops, producing more errors — so configuration needs periodic audit and test-by-removal rather than one-way growth.

Also known as: config decay, context file bloat, config half-life, rule accumulation cycle, config smell, agent config audit

Part of: Agent Context Files (CLAUDE.md / AGENTS.md)

Documents (4)

• Agent-First Engineering: 9 Playbook Tips for a Zero-Human-Code Future Avi Pilcer · 2026-10-08 Reader 🖥️
  A codebase and its surrounding processes must be deliberately re-engineered — minimal, pointer-style instruction files, plans and architecture decisions checked in as versioned markdown, boring/predictable tooling, and scheduled background agents for cleanup and doc-sync — to remain legible and non-degrading as the volume of agent-written code grows toward (the author claims) zero human-written code; the engineer's job shifts from writing code to designing this environment.
• Audit your Agent files AddyOsmani.com · 2026-08-27 source ↗ Reader 🖥️
  Coding-agent configuration (CLAUDE.md/AGENTS.md, skills, hooks, MCP servers, memory) has a half-life because models and harnesses keep improving past what the rules were written for, so instead of accumulating it indefinitely or purging it wholesale, developers should audit it on a recurring cadence — using tools like /doctor, questioning whether each item's original reason still holds, and testing removal before committing to it.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• Just Talk To It - the no-bs Way of Agentic Engineering Peter Steinberger · 2025-10-14 source ↗ Reader 🖥️
  As coding-agent models (specifically GPT-5-Codex) get good enough to read a codebase and follow short, direct instructions on their own, most agentic-engineering 'harness ceremony' — subagents, RAG, elaborate plan files, custom hooks, MCP servers — becomes charade that works around older model limitations rather than exploiting current model capability, so the highest-leverage practice for a solo developer is to talk to the model directly and let judgment (about blast radius, context budget, and when real structure is needed) develop through intuition rather than process.

Open gaps (4)

• uninformedThe headline claim ('OpenAI... 3 engineers. 1 million lines of code. Zero human-written code') is asserted without a source link, named team, project, or any verifiable detail, and the post offers no way to check whether the 'playbook' it summarizes is an official OpenAI publication or a secondhand paraphrase (the author credits a commenter for 'dropping' the article, but never names or links it).
  Agent-First Engineering: 9 Playbook Tips for a Zero-Human-Code Future — read next: Before treating this as evidence, locate and read the actual source article/playbook it claims to summarize to check whether the tips and the headline figures are accurately represented.
• incompleteHis own admission that his AGENTS.md file is 'organizational scar tissue' he 'should clean up at some point' sits in direct tension with the post's anti-ceremony thesis — the file itself is accumulated harness complexity he hasn't resolved, and the post never reconciles this with its 'just talk to it' framing.
  Just Talk To It - the no-bs Way of Agentic Engineering — read next: Compare against a formal agent-configuration-audit methodology to see whether his ad hoc 'the agent writes its own notes' approach actually prevents the bloat cycle or merely delays recognizing it.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteThe article never resolves how the documentation stays synchronized with a changing codebase over time (beyond floating, without choosing or testing, 'destroy and regenerate quarterly' or CI checks or verification swarms) — it is a one-day snapshot with no reported re-validation after initial creation.
  Reverse Engineering your Software Architecture with Claude Code to Help Claude Code — read next: extract-pilcer-agent-first-engineering-playbook's 'doc-gardening agent' (scheduled background agent that detects doc/code drift and opens fix-up PRs) proposes a concrete mechanism for exactly this gap.