How agentic practices evolve

Every chapter in this book is a bet that some part of what it says will still be true in three years. Most bets will land; some will not. The difference between a book that ages well and one that becomes embarrassing fast is not the quality of the original writing — it is the methodology applied continuously after publication. This chapter is that methodology, named explicitly.

Representation

Agentic coding is a fast-moving field embedded in an even faster-moving ML infrastructure. Tool releases ship monthly, conventions crystallize and dissolve quarterly, specific commands rename without warning. A book that tries to pin down “best practices” in such a field has two failure modes: either it stays vague (no concrete advice; safe but useless) or it gets specific and dates fast (useful for six months, embarrassing after).

The resolution is not to choose — it is to stratify. Not every claim ages at the same rate. A claim about transformer attention dynamics is decades-durable. A claim about a specific --flag is quarterly-volatile. Treating them identically is the mistake. The methodology in this chapter is how to treat them differently.

Three levers, working together, make stratified practice possible.

Lever 1: source tiering

Every claim you make rests on some source. The tier of that source determines how much weight the claim should carry and how often it needs re-verification.

The tiering this book uses:

• T1-official — vendor documentation, release notes, engineering team posts. Highest trust for factual claims about a tool’s behavior. Verify on major releases.
• T2-release-notes — product-announcement blog posts, conference talks, Changelog feeds. Trustworthy for intent and feature-availability claims; less reliable for edge-case behavior. Verify quarterly.
• T3-practitioner — respected community writing (e.g. Gwern on sidenote UX, Kleppmann on data systems). Trustworthy for pattern and principle claims that the authors have tested. Verify annually.
• T4-conjecture — tweets, speculation, claims without citations. Use as pointers to investigate, not as support. Verify before relying on.

The tier is not a comment on the source’s intelligence or honesty. A brilliant Twitter thread is still T4 until someone does the work to elevate it. A bland vendor doc is still T1 because the vendor is the definitive source for their own tool’s behavior.

Lever 2: volatility classification

Every claim has a half-life. Classify it explicitly:

• stable-principle — rooted in properties of the substrate (transformer attention, information theory, software engineering fundamentals). Rarely changes. Example: “context degrades non-linearly.”
• architectural-pattern — the shape of a convention that one or more tools have crystallized. Changes on major versions. Example: “top-level briefing doc re-injected on every turn.”
• feature-surface — specific commands, flags, file paths, integration points. Changes on minor versions or even patch releases. Example: “Claude Code uses /compact with optional focus argument.”

Each class needs a different review cadence. stable-principle chapters can be left alone for years; feature-surface claims need quarterly audit. Mixing classes within a chapter without distinguishing them is how otherwise-good books rot.

Lever 3: convergence / divergence tracking

Specific tool claims date unpredictably. Patterns across tools date much more slowly. When three CLI-agents converge on a pattern (e.g. briefing doc at project root), the pattern is signaling that it’s close to an architectural minimum — practitioners can safely bet on it. When they diverge (e.g. hook system depth), the divergence is signaling an open design space — practitioners should assume continued movement.

Convergence/divergence tracking turns a disorganized shelf of tool releases into a signal-extraction problem. The signal: which primitives have settled? Which are still contested? The book’s own changelog data is a concrete instance of this methodology — per-tool release timelines joined against a shared pattern registry to surface when multiple tools land the same primitive.

Operation

The methodology is cheap to apply once internalized. Four concrete routines.

Routine 1: tier a claim when you cite it

Every external claim that goes into your writing earns a tier tag — at authoring time, not during a later audit. This forces the evaluation while the source is fresh in your mind and enables downstream filters (the book’s <Citation> component renders the tier as a badge so readers can calibrate trust at the point of use).

# sources/manifest.yaml — one entry per cited source
- id: anthropic-context-engineering-2026
  url: https://docs.anthropic.com/en/docs/context-engineering
  tier: T1-official
  captured_at: 2026-02-10T14:32:00Z
  title: "Context Engineering Best Practices"
  author: "Anthropic"
  perma_cc: https://perma.cc/XXXX-YYYY

- id: gwern-sidenote
  url: https://gwern.net/sidenote
  tier: T3-practitioner
  captured_at: 2026-04-17T13:00:00Z
  title: "Sidenotes In Web Design"
  author: "Gwern Branwen"

Routine 2: volatility-classify every chapter / section

Every major section of your writing earns a volatility flag. In this book, the flag lives in frontmatter (volatility: stable-principle | architectural-pattern | feature-surface). Downstream effects:

• Freshness stamps are required on volatile content; optional on stable content.
• Quarterly audit queues draw from the volatile buckets first.
• Readers can see the volatility class at the top of every chapter and calibrate confidence accordingly.

The mixed-class chapter is the dangerous case — a chapter that’s mostly stable-principle but with a few feature-surface claims sprinkled in. The fix: isolate the volatile claims into their own sections (or callouts), flag them explicitly, and review them on the volatile cadence while leaving the stable material alone.

Routine 3: track tool-pattern adoption

Every tool’s releases feed a per-tool changelog. Every pattern feeds a shared registry. Joined, they produce the convergence timeline.

# changelog/tools/claude-code.yaml — per tool
tool: claude-code
versions:
  - version: "2.9"
    date: 2026-03-27
    changes:
      - pattern: briefing-docs
        kind: changed
        note: "CLAUDE.md hub-and-spoke documented as default architecture"

# changelog/patterns.yaml — shared across tools
- id: plan-mode
  name: "Plan mode"
  category: safety
  convergence_date: 2026-03-05   # date all three tools landed it

- id: subagents
  name: "Subagent delegation"
  category: scale
  convergence_date: null         # not yet converged

A dashboard — rendered programmatically from these YAML files — surfaces the current state: which patterns have converged, which are in flight, which are divergent. The dashboard is the meta-artifact of the entire methodology: it makes the evolution of the field visible rather than implicit.

Routine 4: scheduled drift audits

Three cadences, each catching a different class of drift:

Quarterly audit — highest volatility content. Walk every chapter flagged feature-surface; verify command names, flag syntax, file paths against current tool docs. This is the most expensive cadence, ~half a day per 16-chapter book.

On-release audit — when a tool ships a significant update, search for chapters that reference that tool’s specific behavior and re-verify those. Triggered by watching the tool’s release feed, not by calendar.

Annual audit — stable-principle content. Check that the principles themselves haven’t been superseded by new understanding (rare but happens). Walk the book’s claim taxonomy at a high level.

Evolution

The methodology in this chapter is itself young — less than two years old as a named discipline, with its constituent parts (source tiers, volatility classification, convergence tracking) drawn from older practices in academic citation, long-form journalism, and domain-driven software engineering. What’s new is the application to AI-assisted development specifically.

Convergence: the manifest + audit pattern. Academic research, legal scholarship, serious technical writing — all three traditions have independently landed on “structured source manifest + scheduled reverification” as the pattern for durability in citation-dependent work. Web archives (Perma.cc, Wayback) are the infrastructural layer that makes the pattern tractable for web sources. The agentic-coding application is new; the pattern is not.

Emerging: automated drift detection. A handful of practitioners are experimenting with automated drift checks — a script that periodically re-fetches every T1 source in the manifest, compares against the captured version, and flags changes. The tooling is hand-rolled in 2026; expect first-class product support within 18 months. The hardest part is not detection — it’s significance: most detected changes are cosmetic (typo fix, reorganization), and distinguishing those from substantive changes that invalidate a claim requires judgment the automation doesn’t have.

Emerging: cross-team pattern registries. If pattern tracking is valuable within one team’s book, it’s more valuable across teams. A shared registry — “plan-mode adopted by Claude 2025-06, Gemini 2026-03, Codex 2026-01” — would save every team the tool-watching work. No mature shared registry exists in 2026; various community efforts are early. Watch for consolidation here in the next 18–24 months.

How this chapter is itself aging

The meta-methodology ages differently than content claims. The three-lever structure (source tiers, volatility classes, convergence tracking) is likely to outlast many specific tool names — it’s a structural pattern that applies to any fast-moving field with citable sources. The specific tier names (T1–T4) and volatility class names are terminological choices that might evolve. The infrastructure (YAML manifests, scheduled audits) will be augmented by tooling — automated drift detection, shared pattern registries — over the next couple of years, at which point the hand-rolled version documented here will feel quaint. But the underlying discipline will hold.

Quick reference

• Agentic coding is a fast-moving field. Every claim has a half-life. Treating all claims as equivalent is the mistake.
• Three levers: source tiering (trust axis), volatility classification (decay axis), convergence/divergence tracking (field-level signal).
• Source tiers: T1-official, T2-release-notes, T3-practitioner, T4-conjecture. Tag at citation time, not during audit.
• Volatility classes: stable-principle, architectural-pattern, feature-surface. Tag in frontmatter. Audit cadence scales with volatility.
• Convergence across tools signals durability; divergence signals open design space. Track both with structured changelog data.
• Four routines: tier claims when citing, volatility-classify every chapter, track tool-pattern adoption, run scheduled drift audits.
• When rot is discovered, fix in four layers: correct the claim, refresh the freshness stamp, diagnose the audit failure, reclassify.
• The methodology is young — named as a discipline only in the last year or two. Tooling will improve substantially. The structural discipline is stable.
• Durability in a volatile field comes from knowing what to trust at what depth, not from trying to make everything equally authoritative.